How to Build an AI Agent Inventory: A Step-by-Step Guide for Security Teams

Your organization is running more AI agents than your security team can name. Endpoint-based AI agents grew 509% in 2025 according to Cyberhaven Labs, and most of that growth happened without a ticket, a review, or an owner. The agents are real, they hold credentials, they touch sensitive data, and they act autonomously - but they are absent from every inventory you maintain. That gap is not a configuration mistake. It is architectural.

This guide lays out a vendor-neutral methodology for building an AI agent inventory: a living registry of every agent and MCP server in your environment, captured with the metadata you need to govern it. It is the direct operationalization of a simple principle - you can't govern what you can't see. Discovery is the first job. Everything downstream (least privilege, monitoring, audit) depends on getting it right.

What an AI agent inventory is

An AI agent inventory is a continuously maintained registry that answers, for every agent and MCP server in your org: who owns it, what identity it runs as, what data and systems it can reach, what tools it is wired to, where it came from, when it was last reviewed, and how risky it is. It is not a static asset list. Agents appear daily and credentials outlive the people who created them, so the inventory has to be a living system fed by ongoing discovery - not a quarterly spreadsheet that is stale before you finish it.

The reason this deserves a dedicated effort, rather than a column bolted onto your existing CMDB, is that AI agents are a new class of asset: a non-human identity with judgment-free autonomy, broad tool access, and the ability to be steered by untrusted input. That combination does not map cleanly onto any inventory you already keep. We covered the broader framing in AI agents are the new shadow IT; this guide is the operational how-to.

Why your existing tools miss agents

Most discovery tooling is built around human identity. CASBs, identity providers, and SSO-based SaaS discovery work by watching people log into applications. That model is structurally blind to agents, because agents do not log in like people do. They authenticate machine-to-machine - with API keys, OAuth grants, service accounts, and direct MCP server connections (agent-to-server, not user-to-app).

The scale of the blind spot is in the identity ratios. Non-human identities now outnumber humans roughly 45:1 in the modern enterprise (Rubrik Zero Labs) and as much as 144:1 in cloud-native and DevOps environments (Entro Labs, H1 2025). And a 2025 Cloud Security Alliance / Oasis Security survey found that 51% of organizations cited no clear ownership or accountability for AI and non-human identities as a top pain point. An agent running on a developer's GitHub token is, for all practical purposes, that developer - but with no real-time judgment, and it keeps running after they leave. Identity teams routinely miss this persistence risk because the credential looks legitimate; only the behavior is new.

The takeaway: discovery has to look at the signals agents actually emit - credential issuance, OAuth scopes, API traffic, MCP connections, code imports - not the human-login signal that never fires. This is the foundation of non-human identity governance.

The five discovery domains

Agents and MCP servers surface in five distinct environments. A complete inventory requires scanning all five and correlating the results - any single-domain view (one SaaS platform's native registry, say) gives you a slice, not the picture.

1. SaaS platforms

• Pull each platform's native agent registry - Salesforce Agentforce, Microsoft Copilot Studio, ServiceNow, and others now expose lists of agents built on them. (Microsoft reported customers created more than 1 million custom agents across SharePoint and Copilot Studio in a single quarter, announced at Build in May 2025.)
• Enumerate OAuth grants, especially apps with write scopes to email, calendar, files, and CRM. An agent's reach is defined by the scopes it was granted.
• Flag connectors and integrations that act on a user's behalf without that user actively present.

2. Code repositories

• Scan for LLM/SDK API calls and agent-framework imports: LangChain, CrewAI, AutoGen, and similar.
• Hunt hardcoded API keys and embedded model credentials - a frequent source of orphaned, unowned agents.
• Catch coding agents and CLIs running in dev workflows; see securing AI coding agents and CLIs for the threat model.

3. Endpoints

• Use process, CLI, and browser-extension telemetry to spot locally running agents and local models.
• Watch for desktop MCP clients and agent CLIs launched by developers outside any sanctioned platform.
• Endpoint telemetry is where the 509% growth is most visible - and least governed.

4. CI/CD pipelines

• Inventory service accounts and pipeline-embedded agents and keys.
• Treat any automation that calls an LLM during a build or deploy as an agent with production reach.
• Pipeline credentials are high-value and frequently over-scoped.

5. Cloud

• Mine AI platform logs - OpenAI, Anthropic, Azure OpenAI - for who is calling models and from where.
• Inspect API gateway traffic, IAM/service-account inventories, and secrets managers. LLM gateways are a natural choke point; see securing LLM gateways and proxies.
• Correlate cloud findings back to owners via the secrets and credentials that grant access.

Correlate with the identity layer

Discovery signals are only useful when tied to an identity and an owner. Pull OAuth grant logs, API key issuance records, secrets-manager entries, and service-account inventories, then correlate them against the agents you found. This is how you surface orphaned credentials: keys with no named owner, grants tied to departed employees, service accounts whose original purpose no one remembers.

For MCP specifically, the November 2025 MCP authorization spec (revision 2025-11-25) builds on an OAuth 2.1 resource-server model and requires PKCE with SHA-256. Capture each MCP server's authorization posture as registry metadata - whether it enforces the spec, what scopes it grants, and which agents connect to it. Our OAuth for MCP servers explained guide covers the mechanics.

The registry metadata schema

Every inventory entry - agent or MCP server - should carry the same core fields. Synthesizing the schemas published by discovery practitioners, here is a practical minimum:

Treat this as a living registry: continuously updated from your discovery pipeline, with the last-review date and activity status refreshed automatically rather than by hand.

Two ways to tier risk

Use two complementary lenses. They answer different questions and you want both.

Governance-status tiers

• Sanctioned - approved, owned, reviewed.
• Tolerated - known and allowed for now, pending review.
• Unsanctioned - discovered, no approval, no owner. Investigate.
• Restricted - explicitly disallowed; quarantine or kill.

Risk-first prioritization

You cannot review everything at once, so start where the impact is largest: agents with write access to production plus a broad data scope, then expand outward. The clean mental model is blast radius = data sensitivity x action authority x autonomy. A read-only agent over public data with a human in the loop is low tier; an autonomous agent that can write to production and reach customer data is top tier regardless of how new it is. This feeds directly into least privilege for AI agents.

Flag the lethal trifecta

The single most useful risk filter your inventory enables is the lethal trifecta, described by Simon Willison in June 2025. An agent is exploitable by design when it simultaneously has: (1) access to private data, (2) exposure to untrusted content, and (3) the ability to communicate externally. Combine all three and an attacker can use prompt injection to turn the agent into a data-exfiltration channel.

Your registry already records the inputs - data touched, tools, external comms - so trifecta detection becomes a query, not a manual audit. Any agent matching all three properties should be flagged as highest tier automatically. We go deeper in the lethal trifecta and AI agent data exfiltration and indirect prompt injection explained.

Threats the inventory helps you surface

A good inventory is also a threat-mapping surface. The agent-specific risks it helps you reason about include:

• OWASP Top 10 for LLM Apps 2025 - prompt injection ranks #1, alongside excessive agency, sensitive information disclosure, and supply-chain risk. See the OWASP Top 10 for LLM Applications guide.
• OWASP Top 10 for Agentic Applications - delegated identity abuse, uncontrolled autonomy, cross-agent prompt injection, and memory corruption. See the OWASP Top 10 for Agentic Applications guide.
• Memory-injection (MINJA) attacks (arXiv 2503.03704), where an agent's persistent memory is corrupted through ordinary query-only interaction - see AI agent memory poisoning explained.
• Exposed MCP servers - security research has found MCP servers openly reachable on the internet, each a potential foothold; see the MCP server security complete guide.

Map the inventory to compliance

For GRC stakeholders, the inventory is the evidence layer auditors keep asking for. It maps directly to the major frameworks:

• NIST AI RMF - Map function: characterize and understand the AI systems in use. An inventory is literally the Map output. See the NIST AI RMF guide for AI agents.
• ISO/IEC 42001: requires organizations to identify and maintain an inventory of their AI systems as part of the AI management system. See the ISO 42001 AI agent governance guide.
• EU AI Act: registry and record-keeping obligations, with the prohibited-practices ban applying from 2 February 2025 and GPAI-model obligations from 2 August 2025. See the EU AI Act guide for AI agents.

In all three cases, the inventory is the first and hardest step - and the one auditors check first.

Step-by-step: standing up the inventory

1. Wire up the five domains. Connect discovery to SaaS, code repos, endpoints, CI/CD, and cloud. Start with whichever domain has the most agents you suspect are ungoverned.
2. Correlate to identity. Join discovery findings to OAuth grants, API keys, secrets managers, and service accounts to attribute and de-orphan.
3. Populate the schema. Create a registry entry per agent and per MCP server with the eight core fields. Reject entries with no owner.
4. Tier every entry. Apply both the governance-status tier and the blast-radius score; auto-flag lethal-trifecta matches.
5. Assign owners and review SLAs. Every entry gets a named human and a review cadence proportional to its tier.
6. Quarantine high-risk unsanctioned agents. Restrict or kill anything top-tier with no owner or approval.
7. Make it continuous. Re-run discovery on a schedule, not on a project plan - new agents appear daily.

Operating cadence

An inventory decays the moment you stop feeding it. Bake in an operating rhythm: discovery runs continuously; every new entry triggers owner assignment; review SLAs are tied to risk tier (top-tier weekly, low-tier quarterly, for example); unsanctioned high-risk agents are quarantined on detection; and the registry serves as the single source of truth that downstream enforcement, monitoring, and audit all read from. That last point is what turns a list into a control plane - see runtime monitoring and anomaly detection for AI agents and the AI agent audit trail and logging guide for what sits on top of a good inventory.

The tooling landscape

Two broad approaches exist. Native cloud and SaaS registries (Microsoft Agent 365, plus platform-specific agent lists) give you a clean view of agents built on that one platform. Purpose-built discovery platforms - from the non-human-identity and AI-security space - aim to span environments. The gap the native registries leave is the cross-domain one: an agent built on a developer's laptop, holding a cloud API key, calling an MCP server, never appears in any single platform's view.

Where continuous visibility fits

This methodology is the foundation of what Anomity does: continuous, vendor-neutral discovery across all five domains, feeding a living registry with exactly the schema described here, then layering risk tiering and lethal-trifecta flagging on top so the inventory becomes an early-warning system rather than a static list. The point of the registry is not the list itself - it is that everything downstream (monitoring, enforcement, audit) finally has a complete, current source of truth to act on. If you want to see what cross-domain scanning actually turns up, what we found scanning AI configs is a concrete look.

Build the inventory first. It is the one investment that makes every other agent-security control possible - because you genuinely cannot govern what you cannot see.