7 min read Shadow AI

The inventory nobody ran: how many AI agents are actually running in your organization

The inventory nobody ran: how many AI agents are actually running in your organization

Gartner published a note on 28 April 2026 on agent proliferation, whose headline projection has travelled widely: by 2028, the average global Fortune 500 enterprise would be using more than 150,000 AI agents, up from fewer than fifteen in 2025. The firm adds that only 13% of organisations believe they have the right governance in place. A separate forecast, published in November 2025, holds that by 2030 more than 40% of enterprises will experience a security or compliance incident linked to unauthorised AI use.

A four-year projection carrying a factor of ten thousand should be handled as what it is, an analyst extrapolation rather than a measurement. The available survey data is more modest and more useful. A study published on 4 February 2026, covering more than 900 executives and technical practitioners in the United States and the United Kingdom, reports that 80.9% of technical teams have moved past the planning phase, while only 14.4% say all of their agents went live with full sign-off from security teams. On average, 47.1% of an organisation's agents are actively monitored or secured. Put plainly, more than half run with no oversight and no logging.

The usual reading of those numbers is a monitoring gap, calling for a monitoring tool. The same data says something else, and the detail is decisive: 45.6% of teams still use shared API keys for agent-to-agent authentication, and only 21.9% treat their agents as entities carrying an identity of their own. An agent without a distinct identity is not a poorly monitored agent, it is an agent no monitoring can name. You cannot take a census of a population whose members do not exist as individuals in your systems.

The 23 July article on governing agentic risk offered a grid for assessing an agent before deployment. It assumes the problem tackled here is already solved, because it comes first: having the list. What follows covers why that list does not exist, why it expires, and how to build it.

A frame containing six aligned items, surrounded by dozens of scattered items outside it.
What appears in a registry and what actually runs almost never coincide.

The inventory is an identity problem, not a discovery problem

The order of causes matters, because it determines where to intervene. An organisation does not lose track of its agents because it neglected to write them down somewhere. It loses track because the technical decision that made a census possible was taken months earlier, by a developer who reused an existing key rather than creating one, for an entirely mundane reason of deadline.

From there the chain is mechanical. Several agents speak with the same credential, so the downstream provider's logs show a single caller. An incident occurs, the security team follows the trail to a shared service account, and stops there. The question of which agent acted has no technical answer, whatever tool is deployed afterwards. It is the direct extension of the least-privilege principle discussed in the 13 July article on access control for agents: a privilege can only be restricted if it was granted to somebody.

One figure from the same survey adds a difficulty of a different order. Roughly a quarter of deployed agents can create and task another agent. The population is therefore not merely undercounted, it is self-generating. An inventory taken today has a shelf life, and that shelf life is set not by the pace of your projects but by the pace of the agents themselves. A registry maintained by hand, on request, will be wrong before it is finished.

The usual caveat applies to this data: the survey comes from a vendor that sells precisely agent identity management and governance. That does not invalidate declarative percentages collected from 900 respondents, but it means they should not be treated as an independent measurement. What is solid in these figures is the gap between perception and practice reported by the same people: 82% of executives surveyed say they are confident their existing policies prevent unauthorised agent actions, while 88% of organisations report a confirmed or suspected incident over the past year. Both answers come from the same sample, which makes them comparable with each other regardless of who commissioned the study.

Where the agents you are not counting hide

A census fails when it starts from the registry rather than from the ground. Four reservoirs hold most of what is missing, and none of them sits in an application catalogue.

API integrations and service accounts. Review the active tokens on your model providers and internal systems, looking at last-use date rather than creation date. An active token whose owner nobody can name points either to a forgotten agent or to one somebody prefers not to declare.

Browser extensions and agents, which escape architecture reviews because they install on the endpoint and appear in no contract. Your managed browser telemetry produces the list in minutes, provided somebody thinks to ask for it.

Automations built inside business platforms, where a flow containing a model call is an agent in risk terms even if the tool does not call it one. This is the widest and least explored reservoir, because it belongs to teams who do not consider themselves technical teams.

Agents created by other agents, finally, which can only be found by observing traffic. It is the only one of the four that demands continuous detection rather than a one-off scan.

Diagram of the four reservoirs to sweep, then the three-way triage based on irreversibility and sensitivity.
Four reservoirs to sweep, and the criticality threshold that decides what happens to each agent found.

Regularise, constrain, or cut

An inventory with no decision rule produces a list nobody acts on. The simplest triage that works rests on two questions asked of every agent discovered, and yields three outcomes.

The first question is about irreversibility: can this agent write, send, pay or delete, or does it only read and propose? The second is about exposure: does it touch personal, financial or regulated data?

A read-only agent on non-sensitive data gets regularised, meaning it is given its own identity, a named owner and a registry entry, without interrupting its operation. An agent ticking one of the two boxes gets constrained: own identity, restricted scope, separate logging, and review on a fixed date. An agent ticking both that was never approved gets cut immediately, before discussion. That last rule draws the most resistance and is the only one that changes behaviour, because it makes the cost of going around the process higher than the cost of declaring.

The pattern recurring in organisations that regain control is exactly this. They do not try to forbid, which mechanically produces more undeclared agents, but to make the declared route faster than the unofficial one. When obtaining an agent identity takes an hour and a shared key takes zero, the outcome is known in advance. When it takes five minutes self-service, the problem disappears without any policy having to be enforced.

What to put in motion this week

Count what you think you have, then count what you have. Ask each team lead how many agents are running in their scope, then extract the list of active tokens on your model providers. The gap between the two numbers is your starting point, and it says more than any analyst statistic.

Measure the share of your agents that share a credential with another. That is the measurement determining whether an inventory is even technically possible at your company, and it comes before buying any tool.

Create the registry with four columns only: agent identifier, named owner, scope of action, date of last review. A twenty-column registry will not be filled in; a four-column one will.

Make obtaining an agent identity faster than reusing an existing key. That is a platform decision, not a security decision, and it is the only lever acting on the cause rather than the symptoms.

Finally, set the immediate-cutoff rule, written and approved in committee: which kind of undeclared agent is stopped without prior discussion. A rule never once enforced will never be believed.

Conclusion

The 150,000-agent forecast will be borne out or it will not, and that matters little to the decision at hand. What matters is that the order of operations is currently inverted in most organisations: they debate governance frameworks meant to apply to a population nobody can enumerate, using monitoring tools that will observe actors with no name. The first deliverable is not a policy, it is a list, and the condition for obtaining one is that every agent stops borrowing somebody else's identity.

Sources: As of July 2026

Godwin AVODAGBE