What is an agent inventory?

By Nolan Sullivan, Founding Growth Engineer

·Published August 20, 2026·Updated September 9, 2026

Device registers, identity providers, and asset management systems are typically built to track endpoints, applications, and human user accounts, and may have no record type for an AI agent. An agent operates with its own credentials and its own access to tools, data, and production systems, for example a Model Context Protocol (MCP) server or an internal function it can call directly. That access can exist outside the systems a security team relies on for visibility.

The Cloud Security Alliance lists building an AI agent inventory as one of the first actions it recommends CISOs take. A survey of 235 large-enterprise CISOs and CIOs backs that up: 92% reported incomplete visibility into their AI agent identities, and 95% doubted they could detect or contain a compromised agent.

Not building that visibility has a measurable cost. In the same survey, 71% of respondents said AI already has access to core business systems, only 16% said that access is governed effectively, and 75% had already discovered unsanctioned AI tools in their environment.

Why is agent sprawl invisible to the systems you already have?

CMDBs, identity providers, and CASBs each watch for one specific signal: an installation on a managed endpoint, or a person logging into an application. An agent typically produces neither. It authenticates machine to machine with an API key, an OAuth grant, or a service account, traffic that does not resemble a new user signing in.

An endpoint scan can register the application an agent runs in, such as Cursor or Claude Code, but not what gives that agent its reach. An MCP server can be a few lines of JSON in a dotfile such as ~/.cursor/mcp.json, and a skill can be a markdown file in a project directory. Neither registers as software, so a scan can record the editor and miss the credentials and connections behind it. This detection problem is covered in depth in what is shadow AI.

Each system is also built to record a different type of object:

• A CMDB row describes a possession: a device or asset the organization owns.
• An agent inventory record describes a principal: an entity that authenticates, holds delegated permissions, and takes actions someone is accountable for.

An agent inventory has more in common with an identity directory than with an asset database. This is why the CSA note frames agent governance as an identity and authorization problem rather than an asset-tracking one.

What belongs in an agent inventory record?

The CSA note specifies a 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 fields below give that baseline a more specific form for implementation.

What the agent is and does:

• Working arrangements. Which of the four agent types the agent supports: attended individual, unattended individual, attended organization, or unattended organization. Classify each run because the same software can support more than one arrangement.
• Identity. The directory identity the agent uses for each action. Delegated-user authority resolves to a person, while service or workload authority resolves to a dedicated identity with a named human sponsor. Hybrid runs record the applicable principal at each step. 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 such as 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 accountable for the agent. When that person leaves the organization, this field identifies which agents need a new owner or revocation.
• Business process. The function the agent performs for the organization, and the reference point for assessing what is affected if the agent is revoked.

Fields that keep the record accurate over time:

• Sanctioned status. Whether the organization approved the agent, for example the ChatGPT Enterprise tenant or a Cursor deployment managed through MDM, versus an agent discovery has surfaced that was not approved.
• Last seen. The timestamp of the agent’s last action. A record with no recent activity is a candidate for review, either for revocation or because the agent may have moved somewhere the inventory does not cover.
• Next review. The date the record is due for its next check, set on approval and reset each time the record passes review.

Agent inventory vs MCP inventory vs shadow AI: how do these fit together?

These three terms describe different objects, but get used interchangeably in governance discussions:

The agent inventory and the MCP inventory work as two linked halves of one map: principals on one side, tools on the other. An agent record can list the servers it connects to, and a server record can list the agents allowed to call it. The tools half is typically maintained by an MCP gateway, which needs to track every server and credential it fronts.

Merging agents and tools into a single record type can work for day-to-day tracking, but it can break down during an incident, when the question becomes “which agents were affected when this server was compromised.” That question requires a join across two record types, not a lookup in one, which is why keeping the two records separate and linked matters.

Shadow AI is a different kind of object: a condition, not a register. It describes AI use that has not yet been seen by anyone with a security mandate, and discovery surfaces it as individual findings. The agent inventory is where those findings can land, turning each one into a record with an owner and a disposition. Shadow AI detection without an inventory produces a stream of unresolved alerts. Detection paired with an inventory produces a population that can actually be governed.

Not every platform draws these lines the same way. Microsoft’s Agent 365, for example, manages agent tools and MCP servers inside one “Agent Tools” registry rather than treating them as separate objects. Speakeasy keeps agent and MCP inventories separate for the reason above.

How do you tier risk once you have an inventory?

A register with hundreds of untiered records shows what exists but not what to review first. Three fields already in the record can support that ranking:

• Sanctioned status. Groups records by governance lane: approved and reviewed, known but not yet reviewed, or discovered with no owner and no approval. The last group typically warrants review first.
• Business process. Groups records by consequence. An agent that drafts internal meeting notes and an agent that can call create_refund carry different weight even when both are sanctioned.
• Blast radius. Combines what an agent can reach with how much it acts on its own, which is a sharper measure than either field alone. Blast radius describes what an agent could touch if something went wrong, not just what it has touched so far. An agent with read-only access to public data typically needs less scrutiny than an autonomous agent that can write to production and touch customer records, regardless of which one was provisioned more recently.

One specific combination of these factors is worth flagging on sight. Security researcher Simon Willison has described an agent with access to private data, exposure to untrusted content, and the ability to communicate externally as carrying the three ingredients needed to turn a prompt injection into data exfiltration. A record with all three should be reviewed early.

How does an agent inventory stay current?

A register compiled manually, such as a spreadsheet built for an audit, is accurate as of the date it was compiled and can go stale quickly after that. Agents can be created by editing a config file, so a register maintained by manual survey can fall out of date within weeks. Keeping the record current typically requires the inventory to draw from two live feeds:

• Discovery on the endpoint. Agent hooks can fire inside coding agents on every prompt and tool call, functioning as both a sensor and a control. They can observe the MCP servers and skills an agent is actually wired to, including ones that never went through procurement. The shadow AI reference describes this architecture in more detail, 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, each session and tool call can pass through a point that records it. Agents and servers can register as a side effect of being used, which lets the last-seen field update from traffic rather than from a survey.

With both feeds in place, the inventory can reflect what is currently running rather than a snapshot maintained by hand.

What does a live agent inventory unlock?

A live inventory is a prerequisite for several other controls:

• Least privilege. Scoping down an agent’s permissions requires first knowing the agent exists and what it currently reaches.
• Complete offboarding. When a person leaves, the owner-of-record field can identify their agents so they are revoked on the same directory event that disables the person’s account.
• Faster incident response. Because the record links an agent to an identity, an owner, and a set of reachable tools, responders do not have to reconstruct that information after the fact.

How does an agent inventory map to compliance frameworks?

Most major AI governance frameworks predate agentic systems, but each still requires an organization to know what AI it runs, an expectation the inventory is well positioned to satisfy:

• NIST AI RMF. The framework’s Map function asks an organization to characterize and understand the AI systems it has in context before it can manage or measure the risk those systems pose. An agent inventory can serve as the artifact that answers the Map function for agents specifically.
• ISO/IEC 42001. The standard’s AI management system requires organizations to identify and maintain a record of the AI systems in scope. An agent inventory can serve as that record for the agent population.
• EU AI Act. The Act carries registry and record-keeping obligations for AI systems, with enforcement arriving in stages rather than on a single date. An inventory that already tracks identity, owner, and business process covers much of what a registry entry needs.

An inventory alone is not a complete compliance program. It is typically the first evidence an assessor requests, and a starting record that ISO 27001 for agentic AI and agent compliance build on for the rest of the audit.

How does the Speakeasy AI Control Plane keep the inventory live?

The architecture above can be assembled by an organization on its own. The Speakeasy AI Control Plane ships it as one system, maintaining the agent inventory as a byproduct of how agents reach tools rather than as a database someone fills in manually:

• 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 is recorded at the time it happens.
• Identity comes from the directory. Sessions authenticate through the identity provider the organization already runs, such as Okta, Microsoft Entra ID, Auth0, WorkOS, Google Workspace, Ping Identity, or any SAML or OIDC provider. 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 can detect the MCP servers and skills employees have wired up outside the sanctioned path and surface them for disposition, so the register can cover what exists, not only what was approved.
• Last seen comes from observability. Audit logs give each record a live activity trail, exportable to the SIEM the security team already uses.

The CSA note identifies the agent inventory as an artifact organizations will need when agent-specific regulatory examination arrives. To see the inventory the platform maintains for your own agents, talk to us.