By Nolan Sullivan, Founding Growth Engineeragent inventory
An agent inventory is a continuously updated record of every AI agent in an organization: the identity it runs as, the human who owns it, the tools and data it can reach, and whether it is sanctioned. It records principals, the agents themselves, where a CMDB records devices and an MCP inventory records tools.
An AI agent inventory exists because the systems that track everything else in the company cannot see agents. The device register says an engineer has a company MacBook. It does not say that her Cursor talks to a local GitHub Model Context Protocol (MCP) server authenticated with a personal access token, or that the payments team runs an internal agent that can call create_refund against production. Both of those are actors with credentials and reach, and neither appears in any register the security team owns.
The Cloud Security Alliance made this the starting point of its April 2026 research note, The AI Agent Governance Gap: What CISOs Need Now. Its first immediate action for CISOs is to establish an AI agent inventory, on the reasoning that organizations cannot govern what they cannot see. The same note cites the Cybersecurity Insiders 2026 CISO AI Risk Report, a survey of 235 large-enterprise CISOs and CIOs, in which 92% said they lack full visibility into their AI agent identities and 95% doubted they could detect or contain a compromised agent.
Why is a CMDB the wrong place to track AI agents?
A CMDB and a software asset inventory record what is installed. Agents do not arrive as installations. The agent harness itself might, since Cursor or Claude Code shows up as an application on an endpoint scan, but everything that gives the agent reach lives in configuration. An MCP server is a few lines of JSON in a dotfile such as ~/.cursor/mcp.json. A skill is a markdown file in a project directory. None of it registers as software, so the scan records the editor and misses the credentials and connections behind it. That detection problem is covered in depth in what is shadow AI.
The deeper mismatch is the kind of object being recorded. A CMDB row describes a thing the organization possesses. An agent inventory record describes a principal: an actor that authenticates, holds delegated permissions, and takes actions someone must answer for. That makes the inventory closer in character to the identity directory than to the asset database, which is why the CSA note frames agent governance as an identity and authorization gap rather than an asset-tracking gap.
What belongs in an agent inventory record?
The CSA note specifies the baseline. Each record should capture the agent’s identity, its delegated permissions, the tools and data sources it connects to, its human owner of record, and the business process it supports. The note adds that this register is the prerequisite for every subsequent governance measure and an asset the organization will need to produce in any future regulatory examination.
In practice, each of those fields has a sharper form, and two more keep the register honest:
- Identity. The directory identity the agent acts as. For an agent a person drives, that is the person’s own account, which keeps a human in the loop for everything the agent does. For an autonomous agent, it is a dedicated identity with a named human sponsor. What qualifies as an agent identity, and why a shared API key does not, is covered in what is NHI and in governing agent actions with enterprise identity.
- Delegated permissions. Which tools the agent may call, and with what disposition: read-only tools are a different grant from destructive ones like
create_refund. - Connected tools and data sources. The MCP servers, APIs, and data stores the agent can reach. This field points into the tools register described in the next section.
- Human owner of record. The person who answers for the agent. This is the field that makes offboarding work, because an agent whose owner has left is an agent with no one accountable for it.
- Business process. What the agent does for the organization, which is what connects the record to the risk assessment and tells you what breaks if you revoke it.
- Sanctioned status. Whether the organization has approved the agent. The register holds both: the ChatGPT Enterprise tenant, the Cursor deployment managed through MDM, and the internal orchestrator alongside whatever discovery has surfaced that nobody approved.
- Last seen. When the agent last acted. A record with no recent activity is either a candidate for revocation or a sign the agent has moved somewhere the inventory cannot see.
Agent inventory vs MCP inventory vs shadow AI: what’s the difference?
These three terms circle the same governance program and get conflated. They are three different objects.
| Object | What it is | Example question it answers |
|---|---|---|
| Agent inventory | A register of principals: every AI agent, its identity, owner, reach, and sanctioned status | Which agents can touch billing, and who owns each one? |
| MCP inventory | A register of tools: the MCP servers in use, the tools each exposes, and the credentials behind them | Which servers expose a destructive tool, and what do they authenticate with? |
| Shadow AI | Unsanctioned AI use, surfaced by discovery | What is running here that nobody approved? |
The agent inventory and the MCP inventory are two halves of one map, principals on one side and tools on the other, and each record points at the other: an agent record lists the servers it connects to, and a server record lists the agents allowed to call it. The tools half is typically maintained by an MCP gateway, which has to know every server and credential it fronts to do its job.
Shadow AI is different in kind. It is a condition, the AI in use that no one with a security mandate has seen, and discovery produces findings, one at a time. The agent inventory is the register those findings land in, where each becomes a record with an owner and a disposition. An organization with excellent shadow AI detection and no inventory has a stream of alerts; an organization with both has a governed population.
How does an agent inventory stay current?
The failure mode is the spreadsheet compiled for an audit. It is accurate on the day it is finished, and it describes what the organization believed last quarter by the time anyone reads it. Agents are created by editing a config file, so a register maintained by asking around decays in weeks. The CSA note’s field list only has value if the records update themselves, which requires the inventory to sit on top of two live feeds:
- Discovery on the endpoint. Agent hooks fire inside coding agents on every prompt and tool call, which makes them a sensor as well as a control: they observe the MCP servers and skills an agent is actually wired to, including the ones that never passed through procurement. The shadow AI reference describes this architecture end to end, and agent discovery covers the full process that turns what the sensors see into inventory records.
- The path agents take to tools. When sanctioned agents reach tools through a gateway, every session and tool call passes a point that can record it. Agents and servers register as a side effect of being used, and the last-seen field maintains itself from traffic instead of from a survey.
Between the two feeds, the inventory stops being a document someone owns and becomes a view over what is actually running.
What does a live agent inventory unlock?
The inventory is the prerequisite, and the controls that follow are the payoff. Three follow directly. Least privilege becomes possible, because you can only scope an agent’s permissions down once you know the agent exists and what it currently reaches. Offboarding becomes complete, because when a person leaves, the owner-of-record field is what finds their agents and revokes them on the same directory event that disables their account. And incident response becomes reconstruction rather than archaeology, because the record ties an agent to an identity, an owner, and a set of reachable tools before anyone has to ask what it could have touched.
Each of those is its own discipline, and the compliance side, what an assessor will ask for and where the evidence lives, is mapped in ISO 27001 for agentic AI and agent compliance.
How does the Speakeasy AI Control Plane keep the inventory live?
Everything above is architecture an organization could assemble itself. The Speakeasy AI Control Plane ships it as one system, and it maintains the agent inventory as a side effect of how agents reach tools rather than as a database someone fills in:
- The gateway is the registry. Agents reach tools through the platform’s MCP gateway, so every sanctioned agent, the servers it connects to, and every tool call it makes are recorded in the moment they happen.
- Identity comes from the directory. Sessions authenticate through the identity provider the organization already runs, whether Okta, Microsoft Entra ID, Auth0, WorkOS, Google Workspace, Ping Identity, or any SAML or OIDC provider, so each inventory record binds to a person or a sponsored identity, and deprovisioning in the IdP revokes the agent’s access with it.
- Discovery fills in the unsanctioned half. Hooks on coding agents detect the MCP servers and skills employees have wired up outside the sanctioned path and surface them for disposition, so the register covers what exists, and not only what was approved.
- Last seen comes from observability. Audit logs give every record a live activity trail, exportable to the SIEM the security team already watches.
The CSA note calls the agent inventory the artifact an organization will present when agent-specific regulatory examination arrives. Kept this way, it is a view over live traffic rather than a document that was true once. To see the inventory the platform maintains for your own agents, talk to us.