I’ll be honest, I couldn’t 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.

I don’t think I’m 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’s actually running in the environment, and that visibility gap is what matters for both efficiency and security.

The Number Is Bigger than You Think

I’ve found agents get into the organization several ways, and there’s probably more than I’ve listed here.

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.

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’s a black box.

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’t go through procurement, because procurement happened long before the agent did. It shows up as a release note that never reaches the application leaders’ desk.

There’s a fourth path worth naming separately: the attacker level. This level isn’t about sprawl, it’s about intent. Every one of the paths above is also a potential attack surface. An attacker doesn’t 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.

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’t require breaching the network at all. It just requires the agent to read something malicious and act on it. That’s the uncomfortable overlap: the same conditions that make agents hard to count are the conditions that make them hard to secure.

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’re doing and what they can access—before anyone can even ask whether one has been compromised.

Why Discovery Must Come First

Before you can govern agents, set access policy or retire them, you first have to know they exist. That’s “discovery.” Discovery can’t just mean asking teams to fill out a form listing their agents, because people forget or don’t 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’t usually the problem. Those registered agents, owned by a named team, with documented access, are already inside your governance process.

The risk sits entirely with the agents you haven’t 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.

Discovery also can’t 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.

That’s 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.

Next Steps for IT Leaders

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’t 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. This velocity is mirrored inside modern businesses, and it’s not something a spreadsheet can keep up with.

Right now, I’m asking my teams to pull four signals and reconcile them:

• Identity. Non-human identities created in the last ~18 months: service accounts, OAuth apps, machine credentials. A growing share of these are agents, even if nobody called them that at provisioning.
• Egress. Outbound traffic to model providers and known agent endpoints. If something’s calling those endpoints, I need to know what and why.
• Procurement. Records won’t catch most of this, but cross-referencing recent renewals against what those vendors ship today flags the embedded-agent cases nothing else catches.
• DNS. Every agent has to resolve a name to act. I’m biased given where I work, but I’ll say it anyway: DNS is one of the only places you can see across all three of the other signals at once.

No single signal answers the question on its own. Together, they get you a real answer, including for the agents nobody told you about.

What I Still Don’t Know

I want full visibility, and I’m not going to pretend that’s not the goal. What I don’t believe is that I’ll ever get to declare victory. New agents are being created faster than any inventory can keep up, so this isn’t a project with an end date. It’s a capability I must keep running, permanently.

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.

That’s what actually keeps things secure.