AI Agent Inventory and Discovery at Scale

The numbers are not ambiguous. An OutSystems survey of roughly 1,900 IT leaders across financial services, healthcare, retail, and manufacturing found that 96% of enterprises have agents in production, 94% report sprawl concerns, and only 12% operate centralized governance. An SAP LeanIX survey found that 98% of companies have deployed or plan to deploy agents, while fewer than half have visibility into an inventory of them. McKinsey puts 62% of organizations already experimenting with agentic systems, with 80% reporting risky behavior from agents already live, and only 13% believing they have adequate governance in place.

The organizations flying blind are not outliers. They are the majority, and they are heading toward six-figure agent counts without having solved the governance problem at any agent count.

The inventory gap precedes the governance gap, not the other way around. You cannot govern an agent you do not know exists. Governance frameworks, policy enforcement, access controls, audit logs: all of these presuppose a registry of agents to apply them to. Discovery is not a subset of the governance problem. It is the prerequisite, and most organizations have yet to do it.

Gartner forecasts that 40% of enterprise applications will embed task-specific AI agents by end of 2026, up from less than 5% in 2025. Agents are not just standalone tools being deployed alongside existing software; they are becoming load-bearing components inside it, which means the inventory problem compounds silently as agent counts climb inside systems whose governance structures were never designed for agents.

Why Agents Are Harder to Track Than the Software Assets IT Already Manages

Classic IT asset discovery was built for a world of stable, provisioned, registered assets. An agent violates every one of those assumptions, and not gracefully.

Software assets used to arrive through a procurement gate. Someone approved the purchase, IT provisioned the license, and a record was created. Agents do not work that way. Low-code platforms like Microsoft Copilot Studio, Salesforce Agentforce, and ServiceNow have made it possible for product teams, finance teams, sales operations, and customer success managers to spin up agents without filing a ticket with engineering. The marginal cost of creating an agent is effectively zero. The operational cost of governing it is substantial. That imbalance is structural, not a discipline problem, and no policy memo will close it without architectural intervention.

So agents appear daily, across cloud environments, SaaS platforms, and on-premise infrastructure, frequently without formal review or security assessment. When the project ends or the person who built the agent leaves, the agent often keeps running. Initial enterprise scans on one platform surface an average of 47 orphaned agents per organization: autonomous systems still active, still holding credentials, still processing transactions, with no owner and no record. An untracked agent is not inert. That is the part worth sitting with.

The error-scaling problem compounds this in a way most governance conversations underweight. When an employee makes a bad decision, the blast radius is bounded by that person's capacity to act. When an agent makes a classification error, it repeats that error across every transaction it processes until someone catches it. Risk scales with activity, not headcount. An agent processing ten thousand records a day with a misconfigured permission scope is a categorically different threat than a human with the same bad setting, because the human eventually gets tired, distracted, or questioned. The agent does not.

Agents also create a distinct IAM problem that existing tooling was not designed to handle. They combine programmatic credentials with flexible, runtime decision-making. OAuth grant records and IAM logs were designed to represent service accounts with bounded, predictable behavior, not an agent that might decide at runtime to query a database, call an external API, and write a summary to a shared document, all within a single transaction. The signals exist in the network. Interpreting them requires knowing what agentic activity looks like versus a standard service call, and most IAM tooling does not make that distinction.

Manual spreadsheet inventories go stale almost immediately. This is an architectural problem, not a tracking-discipline problem. The distinction matters because one of those has a technical solution.

What a Complete Agent Inventory Actually Contains

An agent inventory is a centralized, continuously updated catalog. Not a one-time audit. A live control plane.

The core record for each agent covers what it does, what systems and data it can access, what tools and models it uses, who owns it by name, its version history and behavioral constraints, and its required permissions and SLAs. The schema is not complicated. The hard part is keeping it current and enforcing it as the entry point for deployment, rather than as a retrospective documentation exercise that happens six months after the agent is already in production doing whatever it wants.

Use-case specificity matters more than most initial implementations account for. A customer support agent needs guardrails for PII, toxicity, hallucination, and prompt injection. A warehouse inventory agent cares about SQL accuracy and database read/write access. A healthcare EHR agent requires HIPAA-compliant audit logs and clinical accuracy checks. A single generic record schema will not adequately serve all three. Governance policies that apply equally to all three will be too permissive for the high-risk cases and too restrictive for the low-risk ones; usually both, in different places at the same time.

There is also an important distinction between a registry and a discovery platform that gets collapsed too often. A registry catalogs agents that are known. A discovery platform finds agents that are unknown. The highest-risk agents are almost certainly the ones absent from any inventory: operating without oversight, often with inherited credentials, without any defined permission boundary. A registry without discovery is just a catalog of the agents you were already comfortable with, which is precisely the population that needed the least governance to begin with.

Anything that acts autonomously needs an owner, a permission boundary, and a record. The registry is where those three live together.

The Four Techniques That Together Make Agent Discovery Comprehensive

No single technique achieves adequate coverage. The field has converged on four complementary approaches, each catching ground the others miss.

OpenTelemetry telemetry scanning. The industry is coalescing around OpenTelemetry as the standard for agent telemetry. As of OpenTelemetry v1.41, the specification defines agent, workflow, tool, and model spans, along with required latency and token-usage metrics. GenAI semantic conventions remain in Development status, so implementations should expect the spec to keep evolving, but the directional commitment from major cloud providers is clear enough to build on. Scanners implemented in OTel-supported cloud loggers detect agent framework signatures as they appear; telemetry listeners monitor OTel streams for new agents, new tools, configuration changes, and other signals of agentic activity. This is your best signal for what is actively running.

MCP server monitoring. The Model Context Protocol, introduced by Anthropic in late 2024, defines a standardized interface for agents to interact with external tools, systems, and data sources. Adoption has been fast: over 110 million monthly downloads, and the open MCP marketplace MCP.so listed over 16,800 public servers by 2025. Monitoring MCP server activity is high-signal precisely because MCP traffic represents agents actively using external tools, not just agents that exist but are idle. Idle agents are a governance problem; active agents using external tools are a security problem. MCP monitoring targets the latter.

Network layer analysis. Correlating OAuth grant records, API gateway logs, cloud audit trails, vault activity, and code repository signals produces a picture of credential and API behavior that is independent of what agents self-report. This is particularly valuable for detecting agents built outside standard frameworks or that predate the telemetry infrastructure entirely. The interpretive challenge is distinguishing agentic activity from standard service calls, which requires purpose-built analysis. Generic log review will miss it.

API-driven and protocol-based discovery. The Agent-to-Agent protocol, released at v1.0 in April 2026 and supported by over 150 organizations, defines how agents discover and interact with each other as peers. Donated by Google to the Linux Foundation and integrated into AWS, Microsoft, and Google cloud platforms, A2A is positioning itself as the emerging standard for inter-agent communication. Each agent publishes an Agent Card: a machine-readable description of its capabilities, input/output modalities, and authentication requirements. Agents that self-declare via Agent Cards are telling you what they are; the question is whether anyone is listening.

OTel catches what is running. MCP catches what is actively connecting to external tools. Network analysis catches credential and API behavior that agents do not self-report. A2A and Agent Cards catch what agents advertise about themselves. Each technique surfaces a genuinely different population of agents, and the overlap between them is smaller than most practitioners expect. An organization that deploys only one is making a deliberate choice about which blind spots to keep.

How the Platform Market for Agent Discovery Is Structured, and What Each Category Actually Covers

The market has organized into four categories with distinct architectural roots and meaningful trade-offs between them.

Purpose-built agent discovery and governance platforms. These platforms were designed from the ground up to discover, inventory, and govern agents across any cloud, framework, or deployment model. They combine automated multi-technique discovery with a centralized registry, policy enforcement, and continuous evaluation, treating discovery and governance as a unified lifecycle rather than separate concerns.

The architectural framing matters: discovery is the entry point to the full governance lifecycle, not a reporting feature that exists downstream of governance tooling. For organizations facing cross-environment complexity, that distinction separates a system that governs agents from one that merely documents the agents you have already decided to trust.

Cloud-native tools. Major cloud providers have built native agent inventories within their own environments. The core limitation is visibility: an agent built on LangChain and deployed on AWS will not appear in Salesforce Agentforce's inventory. Cloud-native tooling is viable if your agent footprint is single-cloud and expected to stay that way. Most enterprise environments are heterogeneous by default, given the proliferation of low-code platforms across organizational functions, which makes single-cloud tooling a partial answer at best.

SaaS ecosystem platforms. Microsoft Copilot Studio and Salesforce Agentforce have added agent registry features within their own ecosystems. They face the same visibility boundary as cloud-native tools: excellent within their platforms, blind to agents built elsewhere. Useful complements for organizations standardized on a single SaaS ecosystem; inadequate as an enterprise-wide discovery mechanism.

AI governance and risk platforms. These platforms have roots in traditional ML model governance: version tracking, audit trails, regulatory compliance. Some are extending their inventories to include agentic AI systems. Gartner published its first Magic Quadrant for AI Governance Platforms in June 2026, signaling that the category is maturing. These tools tend to be stronger on compliance workflow than on real-time discovery, which makes them better suited as complements to purpose-built discovery than as standalone replacements.

The practical question for any evaluator: what percentage of your agents live outside the platforms you already own? The higher that number, the more a purpose-built or cross-environment approach becomes necessary rather than optional. Nearly three-quarters of companies plan to deploy agentic AI within two years, and only 21% have a mature governance model. The cost of retrofitting governance onto an ungoverned agent population grows with every agent added.

Building a Discovery Practice That Stays Current as Agent Counts Grow

Discovery is not a project with a completion date. It is closer to a staffing problem: the population keeps changing, and the records have to keep up.

The first scan will almost certainly surface agents no one knew existed. Treat initial results as a baseline, not a clean bill of health. The orphaned agents, the agents running on expired credentials, the agents built by a team that no longer exists: these are the first things to triage, and they are also the things that make the case internally for why a sustained practice is necessary. The list will be longer than anyone expects. Budget time accordingly.

Assign ownership at registration. Every agent that enters the inventory needs a named owner before it is considered governed. Agents without owners are the highest near-term risk, because there is no escalation path when behavior changes and no accountability when something goes wrong. "We're not sure whose this is" is not a governance posture; it is the starting condition for an incident report.

Differentiate by risk tier from the beginning. Agents with access to production data or external systems are the highest priority for monitoring and policy enforcement. Agents with write access or financial transaction authority require the strictest permission boundaries. Internal-only, read-only agents are lower priority but still require records. Applying uniform treatment across all three tiers is simultaneously inefficient and wrong, in opposite directions.

The governance posture shifts from reactive to proactive when no agent can be deployed without first appearing in the registry. This requires process change, not just tooling. If the deployment workflow does not route through the registry, agents will continue to appear outside the inventory, and the registry will remain a catalog of the agents you already knew about.

Connect discovery to runtime monitoring. An inventory that stops at cataloging cannot catch an agent that changes behavior after deployment. Real-time monitoring and policy enforcement must run continuously against the registered agent population.

Gartner predicts that over 40% of agentic AI projects will be canceled by end of 2027 due to escalating costs, unclear business value, or inadequate risk controls. A documented, governed agent inventory directly addresses two of those three failure modes. The end state is a live registry where every agent is known, owned, and operating within defined boundaries. For most organizations right now, that is not the baseline. It should be, and the gap between those two states is not technical. It is a decision about whether to run the inventory before or after something goes wrong.