The question got asked in a leadership meeting and took forty minutes to not get answered: how many AI agents do we have running right now. IT says four, the ones that went through architecture review. Operations says seven, because it counts the ones their team built in the automation tool. Marketing does not know, but the assistant that summarizes meetings and emails them out has been there since March. Nobody is lying and nobody is right, because nobody has the list.
The thesis in one line: the census comes before governance. You cannot apply a policy to a fleet nobody has counted, and almost every AI governance initiative starts with the policy — the document, the committee, the framework — over a set nobody can enumerate. An AI agent inventory is not the boring part of the governance project: it is its precondition.
AI agent inventory in the enterprise: why the census comes before governance
An agent policy states what each agent is allowed to do, who approves it and who answers when it gets things wrong. All of that applies to a list. If the list does not exist, the policy governs the agents that went through the process — which are precisely the lowest-risk ones, because somebody reviewed them — and leaves out the rest. The result is a governance framework with one hundred percent compliance over half the fleet, and a committee that feels calm for the wrong reasons.
The gap is measured. On April 21, 2026 the Cloud Security Alliance published Autonomous but Not Controlled, with an uncomfortable headline: 82% of organizations have found AI agents running in their infrastructure that they did not know about, and 65% have had at least one agent-related incident in the past twelve months. Of those incidents, 61% ended in data exposure, 43% in operational disruption and 35% in direct financial cost.
The detail that turns the number into an argument comes next: 68% of respondents report strong visibility into their agents. Both figures come from the same sample. Confidence in visibility is not visibility; it is what you feel when there is no list to check it against. And it was not a one-off scare: 41% had discovered unknown agents more than once in the same year.
Scope of those numbers, stated plainly: an online survey of 418 IT and security professionals at organizations of varying size and location, run in January 2026, commissioned and financed by an agent identity security vendor — Token Security — with the questionnaire co-developed with CSA research analysts. It sizes a problem the sponsor sells a fix for, and it should be read with that in front of you. Useful for the order of magnitude, not as our own measurement and not as a promised outcome.
The slope points the same way from a different angle. Gartner, in its April 28, 2026 release on managing AI agent sprawl, predicts that by 2028 the average global Fortune 500 enterprise will have over 150,000 agents in use, up from fewer than 15 in 2025, and adds that only 13% of organizations think they have the right agent governance in place. The second of the six steps it recommends is, literally, building a centralized agent inventory. Scope: an analyst prediction about large global corporations, not a figure for any specific national market and not a measurement of anything. What matters here is not the number, it is the slope. A fleet growing like that does not get counted after the fact.
Where the agents you never registered come from
The wrong mental image is the rogue employee building an agent in secret. It happens, but it is not the volume. The volume comes from every tool you already pay for having switched its own on, and from nobody treating that switch as a decision that needed authorizing.
| Where it comes from | How it shows up | Why nobody registered it |
|---|---|---|
| Internal automation and scripting | A flow somebody built to stop doing a weekly task by hand that now, incidentally, calls a model | It was born as a script, not as an agent, and no AI policy ever applied to scripts |
| LLM platforms: assistants and custom tools | An assistant configured with internal documents and access to a tool or two | It gets created in minutes from a UI, with no onboarding step and no purchase order |
| SaaS with automation built in | The CRM, the ERP or the ticketing system shipping its agentic feature in an update | You did not buy it: it was switched on for you. The vendor made that call on its roadmap |
| Developer workflows | An agent that reviews code, opens issues or deploys, built by the team itself | It lives in the engineering toolchain, which almost never falls inside the scope of the AI inventory |
Those four routes are, in that order, the ones that show up most in the CSA survey: internal automation or scripting (51%), LLM platforms including custom tools and assistants (47%), SaaS tools with built-in automation (40%) and developer-created workflows (40%). None of the four requires anybody to decide to deploy an agent. Which is why the census does not get built by asking who has deployed one: you have to ask what tools you own and what each already does on its own.
And there is a second half of the problem that surfaces later: the agents that stopped being used and nobody turned off. In the same survey, only 21% of organizations have a formal decommissioning process. An abandoned agent does not disappear: it keeps its credential, its permissions and its access, and stays a valid identity against your systems long after its use case died. CSA calls it retirement debt, and it is the reason each record needs a start date and a shutdown procedure from day one. What credentials and what scope to grant each one is laid out in what permissions to give an AI agent; the inventory is what keeps that decision queryable two years later.
The five fields every agent record needs
An inventory is worth something or nothing depending on what you can decide with it. Five fields per agent are enough to prioritize; twenty and it never gets filled in. These are the five, with the operating question each one answers:
| Field | The question it answers | What happens without it |
|---|---|---|
| Owner | Who do I call when this agent does something odd | The incident tours three teams before it finds somebody who can stop it |
| What it touches | Which systems it reads and which it writes to | You cannot size the damage of a failure, so every failure gets treated as either critical or trivial, and both are expensive |
| Which credential | What identity it acts under and what that identity can reach | Revoking one access breaks things nobody knew depended on it |
| Since when | How long it has been running and who authorized it back then | You cannot tell what somebody approved from what has simply been there a long time |
| How to switch it off | The exact procedure to stop it without breaking the process it holds up | The kill switch gets improvised on incident day, which is the worst day to design one |
The five are deliberately few. The temptation is to add the model it uses, monthly cost, prompt version, technical owner and business owner. All of that is useful and all of that is what turns the inventory into a form nobody fills in. Five fields, and the owner is done in three minutes. Twenty fields, and a consultancy fills them in once and they go stale in six weeks.
The inventory is a boring list, not a product
The most common failure mode is not never starting: it is starting too well. The ask for visibility into our agents turns into a project with a discovery tool, a dashboard, integrations and a steering committee. Six months later there is a demo and there is still no list.
A spreadsheet that is current beats a dashboard that is stale. Not because the spreadsheet is better — it is not — but because the entire value of the inventory sits in it reflecting today, and that depends on a habit, not on a tool. Discovery tools genuinely help once you already have the list and want to find what slipped past you: they do not replace the census, they audit it.
What becomes possible once they are counted, and not before
With the list on the table, what used to be conversations turns into tasks. You can classify by risk and require human approval only where it matters, instead of slowing everything down equally. You can review which agents still justify their access and retire the ones that do not. You can know, when a model changes or an integration breaks, what is going to break and who needs telling. That continuous function — policies, a trail of every action, incident management and compliance — is what we build and operate in governing your company’s AI agents, and the inventory is its first deliverable, not a preliminary step you can skip.
Sequence matters less when the risk is already on top of you. If today’s question is not how many do we have but which one is going to cause trouble this week, containment comes first: least privilege, human approval on anything that costs money or touches people, and a kill switch that actually works. That is keeping your AI agents from going off the rails. The census still gets built, just after the temperature comes down.
And there is one decision the inventory exposes the moment it exists: how much each agent gets to decide on its own. The ladder of permissions and evidence that settles it is in the levels of agent autonomy, and the wider control framework over what you have already automated is in governance and control of AI automation. Both questions get answered against the list. Without it they are well-argued opinions.
How to build the census in a week
You do not need a project. You need a week and somebody with the standing to ask.
- Start with the list of tools, not the list of agents. Take the SaaS inventory procurement or IT already keeps and flag which ones have shipped agentic or assistant features. That is where most of what you did not know you had is sitting.
- Ask about process, not technology. «What part of your weekly work is already done by something automatic» returns agents that «have you deployed any AI agents» never returns.
- Review active credentials and API keys and look for the ones with no person behind them. A non-human identity with no owner is either an agent with no record, or a dead agent still holding the keys.
- Fill in the five fields and stop there. No fine-grained classification on the first pass: owner, scope, credential, age and shutdown are already enough to prioritize.
- Make registration a requirement. From the following week, no new agent gets a credential without being on the list. It is the only rule in the process and it is the one that keeps it alive.
None of this is sophisticated, which is exactly why it gets skipped: it does not look good in a committee and it does not resemble an AI strategy. But the first control over a fleet is knowing how many there are. Everything else — policies, approvals, audit, retirement — gets applied to a list somebody had to write by hand.