Agent sprawl is the accumulation of AI agents across an enterprise faster than any central record of them, and an AI agent inventory is the governed register that fixes it — one row per agent, recording what it does, what it can reach and who owns it. The inventory is cheap to start and expensive to retrofit, which is the whole argument for doing it early.
Key takeaways
- Sprawl is not a discipline problem. It is the predictable result of agent-building capability arriving inside tools people already have — a CRM, a spreadsheet platform, a developer IDE, a chat client.
- The inventory’s purpose is not a count. It is the ability to answer, in an incident or an audit, what this agent can reach and who is accountable for it.
- Discovery is a data problem with known sources: identity systems, API gateways, model-provider billing, and the platforms that ship agent builders. Start there, not with a survey.
- Classify by blast radius rather than by sophistication. An unimpressive agent with write access to a system of record outranks a clever read-only one.
- An inventory that depends on people remembering to register things decays within a quarter. It stays current when registration is the path of least resistance to getting credentials.
The reason this becomes urgent faster than previous governance problems is that the build step has collapsed. Shadow IT required someone to procure something. An agent can be assembled by one person in an afternoon inside a tool their employer already pays for, using a model subscription on a corporate card, with access inherited from that person’s own account.
What is agent sprawl, and what is an AI agent inventory?
Sprawl is uncounted agents. The inventory is the register that makes them countable, and more importantly, assessable.
An inventory is not a spreadsheet of names. It is the artifact that lets someone answer four questions without a project:
- What does this agent do, and to which business process?
- What can it reach — which systems, which data, which write permissions?
- Who owns it, by name, including after the person who built it changes role?
- What evidence exists that it works — an evaluation set, a baseline, a last review date?
Both NIST and ISO treat this as foundational rather than advanced. The NIST AI Risk Management Framework’s MAP function is about establishing context and categorizing systems before risk can be meaningfully assessed, and ISO/IEC 42001 requires an organization to know what AI systems it operates as a precondition for managing them. Neither is a checklist you can pass without a register.
The practical distinction worth holding is between an inventory and a catalog. A catalog advertises what is available. An inventory records what exists, including the things nobody wants to advertise.
Control AI Agent Sprawl Before It Becomes a Risk
Identify unmanaged agents, duplicated capabilities, excessive permissions, and gaps in accountability across your enterprise environment.
How do agents get built without anyone recording them?
Through four routes, three of which involve no procurement and therefore no gate.
Inside a platform people already use. Agent builders now ship inside CRM, ITSM, collaboration and spreadsheet platforms. Building one is a configuration action by someone with ordinary admin rights, and it produces no purchase order and no ticket.
By a development team, as a feature. An agent embedded in an internal application is, from the engineering side, a feature of that application. It passes through code review and deployment and is never separately identified as an AI system, so it appears in no AI register because nobody thought of it as one.
By an individual with an API key. A script, a scheduled job, a notebook. Access is whatever that person’s credentials carry, which is usually considerably more than the task needs.
Through a connected tool server. An agent that was reviewed and approved gains new capability because a tool server it connects to added tools. The agent in the register is no longer the agent in production, and nothing changed on your side — the case Microsoft’s AI Red Team names as plugin and MCP abuse in its 4 June 2026 taxonomy update.
Only the fourth route is exotic. The other three are ordinary people doing their jobs with the tools they were given, which is why a policy prohibiting unregistered agents produces compliance theater rather than a register.
What has to be in the inventory record?
Twelve fields, grouped by the question each answers. Fewer than this and the register cannot support a decision.
| Group | Fields | The question it answers |
|---|---|---|
| Identity | Agent name, unique identifier, business owner (named person), technical owner | Who is accountable, today |
| Purpose | Business process supported, task scope, in-use or retired | Whether it should exist at all |
| Reach | Systems accessed, read or write per system, service identity used, tool or server list | What a failure or compromise can touch |
| Control | Approval gates in place, human review points, data classes handled | What stands between it and an irreversible action |
| Evidence | Evaluation set reference, last baseline score, last review date, model and version | Whether anyone can show it still works |
| Lineage | Where it was built, when, by whom, change history | How to reconstruct a decision after the fact |
Two fields carry most of the value and are the ones most often omitted.
The service identity. Recording which identity the agent runs under is what connects the register to the access review, and it is the join key between AI governance and the identity governance that already exists. An agent whose row says “runs on a named person’s credentials” is a finding on sight — the reasoning behind that is set out in agent identity and permissions.
The last review date. Without it, an inventory ages into a list of things that were true once. A row that has not been reviewed in a year is not evidence of a governed agent; it is evidence of a governed agent a year ago.
How do you discover agents that nobody registered?
From systems that already hold the evidence, in a defined order, before you send anyone a survey.
Order matters because the sources differ in cost and in honesty. Logs and billing data are cheap and do not depend on anyone volunteering. The survey is useful last, as a reconciliation against what discovery already found, rather than first, where it becomes the whole exercise.
Two blind spots to state rather than paper over. Agents built inside a SaaS platform that calls the provider on your behalf may generate no egress from your network and no line on your model bill — the platform admin console is the only source. And an agent using a personal account on a personal device is outside all six sources; that is a policy and access problem rather than a discovery one, and pretending the inventory covers it is how a register becomes misleading.
How do you classify what you find?
By blast radius, in four tiers, each attached to a required control rather than to a label.
The reason to tier by reach rather than by capability is that it produces a work list instead of a taxonomy. An agent classified tier 1 with no approval gate and no evaluation set is a specific, assignable gap. An agent classified “advanced” is a description.
It also sets expectations proportionally. Most of what discovery finds will be tier 3 and 4, and loading those with the full governance apparatus is the fastest way to make the register something people route around. Registration alone is the correct control for a read-only agent over public data, and saying so protects the credibility of the tiers that matter.
What makes the inventory stay current rather than decay?
Making registration the easiest route to the things an agent builder needs, rather than an obligation enforced after the fact.
Three mechanisms do nearly all the work:
- Credentials come from the register. An agent needs a service identity; the identity is issued against a registered agent. This converts registration from a compliance step into the first step of building, and it is the only mechanism on this list that is self-enforcing.
- The register is the deployment path. Where agents are deployed through a platform your team controls, registration is a field in that pipeline rather than a separate system.
- Review is scheduled, with the tier setting the interval. Review of what the agent can reach, alongside the access review that already runs. An agent whose review lapses loses its credential rather than acquiring a ticket.
What does not work, and is worth naming because it is always proposed first: an annual attestation campaign, a policy stating that agents must be registered, and a central team that discovers agents manually. Each of these produces a register that is accurate on one day a year.
A related control that pays for itself is a change trigger. The agents most likely to be misrecorded are the ones that were correct when registered and have changed since — new tools, a widened scope, a new connected server. Treating a change in an agent’s tool set as a re-registration event, enforced by the orchestration layer, keeps the reach fields honest. That is the same interception point used for approval gates in agentic workflows.
Control AI Agent Sprawl Before It Becomes a Risk
Identify unmanaged agents, duplicated capabilities, excessive permissions, and gaps in accountability across your enterprise environment.
Who owns the inventory, and where does it live?
Whoever owns the access review, in the system that already holds non-human identities.
The common failure is to create a new system of record for AI agents, maintained by a new team, disconnected from identity governance. It duplicates the hardest part — the reach and permission data — and it immediately diverges from the identity system that holds the truth.
The better arrangement treats an agent as a non-human identity with AI-specific attributes, recorded where service accounts already are, and extends the existing access review to include it. An AI governance function then owns the AI-specific fields — evaluation evidence, model version, data classes, tier — and reads the rest.
This has a second benefit worth more than the first: it means the inventory is reviewed by a process that already exists and already has teeth, rather than by one that must be invented and funded. The full risk picture the inventory feeds is laid out in the enterprise generative AI risk register.
The decision
Start the inventory from logs and billing rather than from a survey, and get the first version wrong quickly rather than complete slowly. The six discovery sources will find most of what exists in days, the survey reconciles the remainder, and the gaps you can name are worth more than the ones you have not looked for.
Then make the register structural rather than procedural. Tier by blast radius so the record becomes a work list, issue agent credentials only against a registered agent so registration is the path of least resistance, treat a change in an agent’s tool set as a re-registration event, and keep the rows next to the non-human identities you already review — not in a new system owned by a new team. An inventory that depends on people remembering will be accurate on the day it is built and misleading by the next quarter, which is worse than not having one.
GrowExx helps establish this through AI consulting and builds the governed path through AI agent development.
FAQs
What is agent sprawl?
Agent sprawl is the accumulation of AI agents across an organization faster than any central record of them, so that nobody can say how many exist, what they can access or who is accountable for each. It differs from earlier shadow IT in that building an agent requires no procurement — the capability ships inside platforms people already use, and access is inherited from the builder's own account.
What should an AI agent inventory contain?
One row per agent covering identity (name, unique ID, named business and technical owners), purpose (the business process and task scope), reach (systems accessed, read or write per system, the service identity it runs under, and its tool list), control (approval gates, human review points, data classes), evidence (evaluation set, last baseline score, last review date, model and version), and lineage (where and when it was built, and its change history).
How do you find AI agents nobody registered?
Start with systems that already hold the evidence rather than with a survey: service accounts and non-human identities created recently in the identity provider; API gateway and egress logs showing calls to model-provider endpoints; model-provider billing broken down by key or project; admin consoles of CRM, ITSM and collaboration platforms that ship agent builders; source control searches for provider SDKs and base URLs; and expense data for AI subscriptions. Use a survey last, to reconcile against what discovery found.
How should AI agents be classified for governance?
By blast radius rather than by sophistication. Tier 1 is write access to a system of record or external communication, and requires a named owner, an approval gate on irreversible actions, a dedicated service identity, an evaluation set and a quarterly review. Tier 2 is write access to internal non-critical systems. Tier 3 is read-only over sensitive data. Tier 4 is read-only over public data and requires registration alone. Tiering this way turns the register into a work list.
Who should own the AI agent inventory?
Whoever owns the access review, with the agent recorded as a non-human identity in the system that already holds service accounts. An AI governance function owns the AI-specific attributes — tier, evaluation evidence, model version, data classes. Creating a separate AI register maintained by a separate team duplicates the permission data, which is the expensive part, and the two copies diverge within a quarter.
Build a Scalable Framework for Enterprise AI Agents
Book an AI Strategy Call
