I\u2019ll be honest, I couldn\u2019t give you a definitive answer if you ask me how many AI agents are running at Infoblox. I have a rough sense of magnitude and a handful of registries, but no comprehensive count or understanding.<\/p>\n
I don\u2019t think I\u2019m an anomaly. If anything, the pace of agent creation reflects something good. Teams are finding real value in this technology, fast enough to just go build. But that same speed and distribution makes it difficult for any IT leader to maintain a full view of what\u2019s actually running in the environment, and that visibility gap is what matters for both efficiency and security.<\/p>\n
I\u2019ve found agents get into the organization several ways, and there\u2019s probably more than I\u2019ve listed here.<\/p>\n
First, the team level. Development and engineering teams adopt code assistants and build agents into their own workflows, often on budget they already control. The head of development or engineering has a decent line of sight here, so partnering closely with department heads is the obvious first move.<\/p>\n
Second, the individual level. Anyone with a cloud account and a free afternoon can stand up an agent. The spend is too small to trip expense thresholds, so it rarely surfaces. That\u2019s a black box.<\/p>\n
Third, the vendor level. Vendors are quietly turning on agent behavior inside software we bought years ago. Nothing new arrives, so nothing shows up in any inventory. It doesn\u2019t go through procurement, because procurement happened long before the agent did. It shows up as a release note that never reaches the application leaders\u2019 desk.<\/p>\n
There\u2019s a fourth path worth naming separately: the attacker level. This level isn\u2019t about sprawl, it\u2019s about intent. Every one of the paths above is also a potential attack surface. An attacker doesn\u2019t need to build an agent from scratch. They can phish or reuse the credentials of one that already has standing access, since non-human identities are often monitored far less closely than human accounts. An unreviewed personal agent with broad permissions is a foothold, not just a blind spot.<\/p>\n
Increasingly, agents that read external content (emails, web pages, tickets, documents) can be manipulated by instructions hidden in that content, causing them to take unintended actions using their own legitimate credentials. That last one doesn\u2019t require breaching the network at all. It just requires the agent to read something malicious and act on it. That\u2019s the uncomfortable overlap: the same conditions that make agents hard to count are the conditions that make them hard to secure.<\/p>\n
None of this means people are doing something wrong. Agentic AI is making teams more effective across businesses. But every new deployment adds up fast, and IT leaders are left scrambling to figure out how many agents are running, what they\u2019re doing and what they can access\u2014before anyone can even ask whether one has been compromised.<\/p>\n
Before you can govern agents, set access policy or retire them, you first have to know they exist. That\u2019s \u201cdiscovery.\u201d Discovery can\u2019t just mean asking teams to fill out a form listing their agents, because people forget or don\u2019t bother. It must be an active, ongoing process that finds agents on its own, including ones nobody reported. This matters because the agents you know about aren\u2019t usually the problem. Those registered agents, owned by a named team, with documented access, are already inside your governance process.<\/p>\n
The risk sits entirely with the agents you haven\u2019t found yet: the ones an individual spun up without telling anyone, the ones a vendor quietly activated, the ones an attacker introduced through a compromised credential or a manipulated workflow. Every decision you make about agents, including which to trust, what data they can touch and which ones to shut down, is downstream of first knowing they exist.<\/p>\n
Discovery also can\u2019t be a one-time project. A point-in-time inventory is out of date the day after you finish it, given how fast new agents get stood up. It must be a continuous capability, something closer to monitoring than to a census, running in the background and surfacing new agents as they appear rather than waiting for the next audit cycle to find them.<\/p>\n
That\u2019s why I keep coming back to signals instead of self-reporting. Self-reporting only ever finds the agents people remember to mention. Signals find the ones nobody thought to report, including the ones nobody yet knows are there.<\/p>\n
Many might read this and think that an agent registry solves this problem. When I began this process, I was right there with you. But agent registries don\u2019t account for the speed and scale of agent creation. IDC estimates that the number of actively deployed AI agents will exceed 1 billion worldwide by 2029, 40 times greater than in 2025<\/strong><\/a>. This velocity is mirrored inside modern businesses, and it\u2019s not something a spreadsheet can keep up with.<\/p>\n Right now, I\u2019m asking my teams to pull four signals and reconcile them:<\/p>\n No single signal answers the question on its own. Together, they get you a real answer, including for the agents nobody told you about.<\/p>\n I want full visibility, and I\u2019m not going to pretend that\u2019s not the goal. What I don\u2019t believe is that I\u2019ll ever get to declare victory. New agents are being created faster than any inventory can keep up, so this isn\u2019t a project with an end date. It\u2019s a capability I must keep running, permanently.<\/p>\n We, as IT leaders, own this. Not just the count, but the decisions that follow. Which agents to trust, what data can be accessed, what gets retired and how quickly newly discovered agents get triaged.<\/p>\n That\u2019s what actually keeps things secure.<\/p>\n\n
What I Still Don\u2019t Know<\/h3>\n