The installed base problem: you can count China's robots. Can you count your agents?
Start with an accounting question, not a technology one.
In a single year, China installed 276,300 industrial robots, about six times Japan's total and roughly 7.3 times the United States' (Stanford HAI, AI Index Report 2025, drawing on IFR World Robotics data). That number is knowable because physical automation arrives on a loading dock. It gets a serial number, a depreciation schedule, an owner of record, and eventually a decommission date. It appears on a balance sheet. Somebody signs for it.
Now run the same query against digital labor. IDC projects 1.3 billion AI agents in operation by 2028 (IDC, cited in Microsoft's CIO Playbook for AI, 2025). Notice the word: projects. It is a forecast, not a census, because no one, at any level of the economy, can produce a count of the agents already running.
Hold those two facts together. We have precise, auditable records on the automation that occupies floor space, and essentially none on the automation that holds credentials. The category with far greater reach into our systems is the one we cannot enumerate.
That is the installed base problem. Not a technology problem. An asset-management problem that arrived without an asset register.
The liability nobody has booked
Two figures turn this from a governance abstraction into a line item.
First, the supply side: 78% of people who use AI at work bring their own AI tools (Microsoft and LinkedIn, Work Trend Index 2024). Read that precisely: 78% of AI users, not of all employees. But the mechanism is what matters for an owner. Digital labor enters the company the way nothing physical ever could: no forklift, no dock, no purchase order, nobody signing for it.
Second, the cost side: breaches involving unmanaged "shadow" AI cost on average $670,000 more than breaches where AI was governed (IBM, Cost of a Data Breach Report 2025). That is not the cost of the breach. That is the premium for not knowing what you had.
Meanwhile, 81% of enterprises expect to integrate agents within 12 to 18 months (Microsoft, CIO Playbook for AI, 2025). The installed base is about to get much larger, much faster, on top of a register that does not exist.
The CFO perspective. Every other autonomous asset class in your company has a register: vehicles, machines, licensed software, badge credentials. You can produce a count, an owner, and a retirement date for each. Agents are the first class of asset that takes consequential action on your behalf while appearing on no schedule anywhere. When your auditor asks what changed in the control environment this year, "we deployed a workforce we did not inventory" is a hard sentence to write down.
Position A: they are software. Govern them like software.
The case against a registry is strong, and worth stating at full strength.
Agents are software. Companies have spent twenty years building software governance: single sign-on, identity systems, access controls, software inventories, change control. That stack already sees service accounts and system calls. A separate "agent registry" duplicates those controls, creates a second source of truth that will drift from the first, and imposes a checkpoint on exactly the lightweight experimentation that makes agents economically interesting.
There is a harder version: registries decay. A registry that is only partly accurate is worse than no registry, because it manufactures false confidence. Anyone who has watched an IT asset inventory rot knows the failure mode.
That argument is right about the risk and right about the decay. It is wrong about the category.
Position B: they hold authority. Govern them like an installed base.
An application waits to be told. An agent decides, then acts, with a credential, inside a system of record, at machine speed, often without a person in the loop on any individual action.
That is not an app. Functionally, it is closer to a contractor with badge access. And we know how to govern those: not by watching them, but by registering the authority they hold. A badge with a scope and an expiration date.
The "it's just software" position quietly assumes your existing controls can already answer four questions about any given agent: who owns it, what it may do, when its authority expires, and how fast you can revoke it. For most companies that assumption does not survive ten minutes of testing.
Both positions are partly right. The skeptics are right that a census of everything decays into fiction. The advocates are right that unregistered autonomous actors are the actual exposure. The resolution is to stop arguing about scope of existence and start arguing about scope of authority.
Register by authority, not by existence.
You do not need to inventory every agent in your company. Only every agent that holds a credential or can take an action with consequence. That set is far smaller than "all agents," far more governable, and it happens to be the exact set an auditor, an insurer, or an incident responder will ask about.
What this means for leaders
1. The authority line. Write down the test that determines what enters your register. Mine is two questions: does it hold a credential, and can it take an action a person would need approval to take? If either is yes, it is registered. If both are no, it is a tool, and your existing software governance covers it. A register without a scoping test becomes an asset inventory: comprehensive, stale, ignored.
2. The four-field record. Resist the hundred-column schema. Four fields carry nearly all the value: a named human owner; scope of authority, stated in the negative (what it may not do); an expiration date, because renewal forces review; and a revocation path, meaning the mechanism and who can execute it at 2 a.m. Four fields get maintained. Forty do not.
3. The decommission drill. Pick one agent at random this quarter. Revoke its authority. Time it. Then find every downstream process that broke. Companies that discover their agent dependencies during a drill are in a categorically different position from those that discover them during an incident. Cheapest exercise here, and the one almost nobody runs.
Where this already works, and the objection
In the production environments I have led, nothing autonomous ran without a scoped identity, a named owner, and a revocation path. Not because the teams were more cautious, but because the alternative was not survivable.
I know the objection, because it is the right one: you do not want a process that treats every deployment like a crisis. Fair. The transferable part is not the ceremony. It is the four questions. The controls that govern autonomous identity in high-assurance environments map, nearly field for field, onto what your own auditors already test: who can access what, how identity is proven, what was logged, and what changed. Same four questions, different vocabulary, and any company can run that mapping against its existing controls without adopting a single new process.
Not the same rigidity. The same honesty about what production requires.
And for anyone who owns a budget: none of this is expensive when it is built in. Identity, scope, expiry, and revocation designed into the deployment are configuration. Reconstructed afterward, across agents already embedded in live workflows, they become stalled projects waiting on a security review nobody scoped, manual audit hours spent reconstructing who authorized what, and brittle compliance scripts maintained by whoever wrote them. That is the retrofit cost, and it is real whether or not anyone assigns it a multiplier.
Born in production, or retrofitted under deadline. The installed base is being built right now, either way.
The companies that come out of this with a defensible agent estate will not be the ones that deployed fastest, or wrote the longest policy. They will be the ones that could produce the list.
