AI Agent Discovery: Inventory, Security, and Governance

Traditional software comes with pre-defined integrations – a developer programs in the APIs, and that’s it. The capabilities of the application are fixed at launch. However, AI agents are threatening to overturn this status quo. As these agents grow more capable and able to perform higher-value tasks, they often need to find and utilize a particular tool, data set, or even another autonomous agent to complete their task – without direct human input.

This is the challenge that the new AI agent discovery protocols aim to address. Anthropic’s Model Context Protocol, introduced in late 2024, represents an important step towards greater interoperability between different models and tools. By standardizing the way that different models access external data and functionality, MCP replaces a number of disparate proprietary approaches with a common open standard that other major models have since adopted. Google’s newer A2A protocol targets a slightly different problem – enabling agents to discover and delegate tasks to one another – and addresses this by developing standardized “Agent Cards” that can be read and interpreted by other AI models. Meanwhile, more recent proposals focus on enabling intent-based discovery, wherein an agent can describe a task and receive a ranked list of potential tools or agents that could help accomplish it.

A seemingly minor detail, but one which has enormous implications for the capabilities, safety, and overall usefulness of these autonomous agents. This blog explores fundamental concepts of AI Agent Discovery.

What is AI Agent Discovery and Inventory

AI agent discovery and inventory refers to the process of detecting all AI agents within an enterprise, whether authorized or not, and storing information about their capabilities. This involves identifying who created and owns the agent, what business function or purpose it serves, what SaaS applications and data sources it connects to, what OAuth scopes and credentials it uses, how widely the agent is deployed and who has access to it, and whether it is active, orphaned, unauthorized, etc. Note that inventory of AI agents differs from a general inventory of all software and tools in the enterprise, since user-created agents typically operate using an OAuth token or API key rather than a username/password and connect to third-party services, and thus are not visible in the same way to standard identity and access management systems.

Why AI Agent Discovery and Inventory Matters for Security Teams

AI agents are already in production; they’re performing actions, making decisions, and accessing data faster than security teams can audit. Unlike traditional software, agents aren’t necessarily installed through a procurement process, and many are created by unvetted employees using a low-code platform. This creates a new shadow IT problem: the workforce itself. The challenges of discovery and inventory for AI agents are critical to address for the following reasons:

• To reduce the exposure created by overly permissive agents: Most AI agents operate with excessive permissions and perform data access operations at a far greater rate than humans, exposing a vastly larger attack surface.

• To close the detection gap left by existing security tools: Single sign-on, mobile device management, and network monitoring solutions were designed to secure human-entered actions and approved software. Sensitive data access by agents is typically done using OAuth tokens or API keys, and the connections are often made directly to external services, leaving no visibility in existing tools.

• To identify shadow agents already operating in production, business users are creating and deploying agents using tools such as Copilot Studio, n8n, or Salesforce Agentforce. These agents operate on production data before being reviewed by security.

• To secure the execution layer where agents operate: When acting, an agent will use a tool, which will act by accessing a database, calling an API, or writing to a file. This is the part of the stack that most attacks in 2026 will target, and security operations need to inventory and govern this layer.

• To replace blind spots with actionable visibility: In recent industry surveys, less than a fraction of enterprises have visibility into which AI agents are communicating with each other.

• To track each new connection as it is created: With protocols such as MCP, agents can connect to databases, filesystems, and APIs in a standard way. Without inventorying these connections, security teams cannot understand what data access they have permitted.

• To enable actual governance and controls: With automated access review and runtime protection rules, enterprises can only govern what they can inventory. Unknown agents are unreviewed agents, representing a fundamental weakness in any security program.

Agent-to-Agent Capability Discovery

Imagine a world with thousands of specialized AI agents: one that books travel, one that analyzes legal contracts, one that controls lab instruments, one that manages a company's CRM. For these agents to truly collaborate, each must be able to answer three questions about every other agent they might work with: does this agent exist, what can it do, and how do I talk to it? That trio of questions is what "capability discovery" is about, and what forms the plumbing behind what researchers are referring to as the "Internet of Agents" or "Agentic Web."

Why this is a hard problem

In a traditional software system, you know in advance which service you're calling and you hardcode the integration. Autonomous agents are intended to operate on a more open network where new agents appear, and existing ones change their capabilities, without central control. This means that agents need to have something like a shared language for advertising what they can do and some mechanism for finding the right collaborator on the fly, rather than having a hardcoded address book.

How agents advertise themselves

The dominant pattern that's emerged is the "Agent Card" - a machine-readable (usually JSON-based) document that an agent publishes describing its skills, what data it can accept and return, and how to authenticate with it. Think of it as a cross between a resume and an API spec: meant to be read by other agents (or discovery services acting on their behalf). In protocols like A2A, Google's Agent2Agent standard, agents place this card at a predictable web location (like a service descriptor in microservices architecture) so that any client agent can fetch it and understand what the agent offers.

How agents find each other

Advertising alone isn't enough; something has to bring supply (agent capabilities) and demand (a task that needs doing) together. This is where discovery mechanisms come in. Some are simple and static (agent is manually configured with addresses of known partners) while more ambitious versions envision distributed discovery services: registries where agents publish their cards, and where a "query language" lets a requesting agent describe what it needs (natural language or structured) and get matched against capability descriptions. This matching process is subtle - it's not just keyword search, it requires some form of semantic alignment so that a task described as "translate this document" correctly matches an agent that calls its skill "language conversion." Researchers generally agree this semantic matching problem is still unsolved in any robust, general way.

How they actually collaborate once matched

Discovery is just the entry point - once a suitable agent is found, the requesting ("client") agent has to hand off work as a structured task object, not a natural language request. Protocols define this as a lifecycle with states (submitted, working, waiting on input, completed, failed, etc.) so that both sides can track progress on long-running work, possibly through streaming updates or webhook-style notifications rather than a single blocking call. This is what distinguishes real agent-to-agent delegation from a simple API call: there's a shared contract for negotiating, monitoring, and completing multi-step work between parties that may not have a codebase in common.

Where this fits among current protocols

Two protocols get discussed together a lot, and it's worth being clear on the difference: MCP (Model Context Protocol, from Anthropic) is about connecting a single agent to its own tools and data sources. It can't help two independent agents discover and negotiate with each other. A2A, on the other hand, is explicitly for that horizontal agent-to-agent layer: discovery via Agent Cards, task delegation, and coordination across agents built by different vendors. People often describe it as "MCP is the wrench that connects an agent to its tools; A2A is the conversation between two mechanics." A related effort, ACP, adds more formal negotiation semantics (proposal, acceptance, rejection, counter-offer) drawing on multi-agent-systems research from the 1990s (FIPA-ACL).

The unresolved parts

This space is still forming. Centralized discovery registries are simple but introduce single points of failure and privacy questions around who can see what an agent can do. Fully decentralized approaches are more secure but harder to trust. Beyond the technical matching problem, there's a governance gap: none of the current protocols talk much about accountability - who's responsible if an autonomous agent misrepresents its capabilities, or if it delegates a task to another agent that fails silently. This is likely to be the next layer built on top of the discovery and delegation mechanisms that exist today.

Categories of AI Agent Discovery Platforms

The space for finding and registering agents has fractured into several categories that address slightly different use cases. Here is a breakdown of the major categories as of the first quarter of 2026:

1. Purpose-built agent discovery and governance platforms

This category represents discovery and inventory tools purpose-built to address the unique challenges of discovering and governing agents. Discovery and governance are deeply integrated, with platforms typically allowing users to discover agents, catalog them into a central inventory, assign ownership, and apply governance policies and risk scores.

Strengths

Discovery and inventory capabilities are typically comprehensive, applying across clouds and frameworks, and governance controls are applied throughout the agent’s lifecycle. Being purpose-built, they tend to offer the most comprehensive view of the agent landscape while accounting for the unique nature of agents, their non-deterministic behaviors, and the varying levels of control an enterprise has across different agent frameworks.

Weaknesses

As a relatively new category, many enterprise security leaders are less familiar with them compared to more established security and cloud management categories.

2. AI security posture management and identity platforms

This category takes a security-first approach to agent discovery, with products typically being extensions of posture management or identity governance tools that now aim to inventory and secure agents as a new category of non-human “identities.” Discovery tends to focus on what permissions, credentials, and service accounts the agent is using, providing the who and what rather than focusing on the agent itself. Many such tools were born out of the cloud security or identity management space, with companies expanding their scope to secure agents as a new type of workloads.

Strengths

Comprehensive understanding of the agent permissions, associated risks, and threats across different clouds. Typically provide extensive controls around these permissions.

Weaknesses

Governance tends to be limited to permissions. While such tools can provide extensive information on what an agent can do, they typically don’t offer guidance, guardrails, or policy evaluation on how well the agent performs its functions, hallucinates, or is susceptible to prompt injection attacks. They also typically lack inventory and governance of actual agent instances.

3. Cloud-native agent inventory tools

Many cloud vendors provide native inventory visibility into agents executed on their platform. These tools tend to offer very comprehensive inventory and governance of agents utilizing the cloud’s native stack, but have very limited ability to inventory agents used on other clouds or on-premises.

Strengths

No extra setup is needed – agents are discovered natively within the cloud’s security stack. Comprehensive inventory and governance within the cloud.

Weaknesses

Discovery is limited to the cloud environment, with no cross-cloud or cross-framework inventory. Enterprises using multiple clouds (which is becoming the norm) will not be able to unify the inventory from different clouds into one agent catalog. Additionally, these tools only inventory agents developed with the native framework (e.g., Vertex AI agents for GCP, Bedrock for AWS, etc.), and hence cannot discover third-party agents developed with other frameworks.

4. Enterprise SaaS and ecosystem agent platforms

Many enterprise SaaS vendors are beginning to offer extensive agent management and governance within their own SaaS ecosystems, providing rich agent inventory and governance within their data warehouse or other enterprise-centric stack. Tools in this category tend to offer the most complete set of controls and policy enforcement within the broader SaaS ecosystem, but have very limited ability to inventory and govern agents beyond it.

Strengths

Comprehensive governance, controls, and policy enforcement within the SaaS ecosystem.

Weaknesses

Inventory and governance are typically limited to the SaaS ecosystem, with little to no ability to manage agents developed outside of it or executing in other clouds. For example, if an enterprise uses multiple SaaS vendors (which is becoming the norm), the tools offered by one SaaS vendor will typically only inventory agents running within it. Similarly, tools in this category are typically unable to discover agents developed with third-party frameworks such as LangChain or similar.

5. AI governance and risk platforms

This category encompasses tools that focus on AI governance and risk management across enterprise AI/ML lifecycle, with some vendors beginning to extend their inventory capabilities to include agentic systems as well. Governance and risk management platforms typically have limited agent-specific inventory and risk controls, focusing on more traditional aspects of model governance such as lineage, versions, and regulatory compliance.

The general theme that emerges from this analysis is that, aside from purpose-built agent governance platforms, all other categories have limitations and blind spots in terms of agent inventory and governance. Tools originating from the security or compliance stack typically only inventory agents up to a certain point – up to the cloud or identity accounts, or up to the SaaS stack. This leaves enterprises with inconsistent, fragmented agent inventory and governance, and with the inability to enforce consistent policies across different agent frameworks and clouds. It is why many enterprises with diverse agent environments are choosing to adopt purpose-built agent governance platforms alongside their existing tools, in order to ensure consistent governance across all agent workloads.

How to Tell Which One You Actually Need

To identify which category your organization needs, first specify the problem you are trying to resolve, as there is a significant difference between the goals of agent discovery in the fields of security, governance, and interoperability.

Define: Do You Know What Agents You Have?

If there is no central record of which agents are running, who built them, and what were their goals, the starting point is a discovery and inventory platform. It is about establishing a baseline, and about being able to secure and govern something that you first had to identify and list.

Validate: Do You Know What Those Agents Can Access?

Once the agents are discovered, the next step is to establish what access and permissions they have. This requires an identity and security-posture platform that treats agents as an extension of your non-human identities, and allocates them to the credentials and service accounts that run them. An inventory tells you that an agent exists - validation tells you what it can actually do.

Scope: Is Your Environment Single-Cloud or Multi-Cloud?

This step is about establishing the scope - what is the environment that the agents operate in? If you're operating in a single-cloud environment, it's likely that you'll be able to rely on your cloud's native inventory tools. If you're multi-cloud, you'll need to account for the fact that your visibility tools will only see up to a cloud, and you'll have to address this blind spot consciously.

Assess: Do Your Agents Interact With Outside Agents?

The question if you need a protocol-level security product (think A2A, MCP) or something else entirely depends on whether you have agents that talk to agents that weren't built by you. It's a question about trust between systems, about what one agent can say about itself to another, and about what either can do when it delegates a task to the other. It's about controls at the protocol level, rather than the visibility.

Prioritize: Is Your Focus Compliance or Real-Time Risk?

This step is about prioritization - if you need something focused on audit trails, documentation, and building a case for a regulator, you're looking for a governance and risk platform. It is focused on control, but built around established and documented model-governance practices, rather than real-time discovery.

Check: Are You Locked Into a Single SaaS Ecosystem?

This step is about the blind spot - if you're using a SaaS ecosystem as your core operations (think Salesforce), you might be tempted to rely on their native governance tools. However, those are often focused on the tools they provide, rather than third-party agents built in the same ecosystem.

How Akto Approaches Security-sense AI Agent Discovery

Akto addresses the agent discovery challenge with two purpose built products: Atlas and Argus. These two products attack the agent discovery problem from two different angles, focusing on agents, and their host environments, at two different levels in the organization.

Akto Atlas: Discovery at the Employee Layer

Akto Atlas focuses on AI usage at the employee layer, as opposed to internally developed systems. Akto Atlas discovers every AI app, LLM, agent, or MCP server that a user may be using across the enterprise, including shadow AI that enterprise security would not otherwise be aware of, through browser extensions and endpoint visibility. It then enforces collection-based RBAC over the discovered agents and MCP servers, blocking PII, credentials, and prompt injection across all surfaces, assigning risk scores to agentic assets, and performing thousands of adversarial probes on a regular cadence. In essence, Akto Atlas provides visibility into what AI the enterprise is using and how safe it is.

Akto Argus: Discovery at the Homegrown Application Layer

Akto Argus focuses on discovering internally developed agents, Gen AI applications, and MCP servers. It provides continuous visibility into what agents, application-layer infrastructure, and tools are present across the enterprise, enabling coverage across dev, staging, and production, for cloud and on-premises setups, through extensive integration with CI/CD and cloud runtime. With a growing number of 80+ connectors, Akto Argus can provide agent discovery across a broad range of agent implementations, including AWS Bedrock, Snowflake Cortex, LangChain, LangGraph, Microsoft Copilot Studio, Azure AI Foundry, Hugging Face, and many more, providing heterogeneous agent management as opposed to a single-vendor solution.

From Discovery to Context

The context of the discovered agents, tools, and data resources can be visualized in an agent context graph, providing a valuable resource for security teams to understand the relationships between different components of their agent infrastructure.

Discovery Enables Enforcement

What makes Akto’s approach unique is the fact that discovery is deeply intertwined with the rest of the product, providing a powerful foundation for enforcing governance and security policies over agents and their host infrastructure. Once agents and MCP servers have been discovered, Argus can be deployed as a proxy to their clients to enforce authentication and tool-level authorization, while also providing visibility into their decision making processes and runtime behaviors to detect rogue agents and privilege escalation. Additionally, Akto Argus can enforce multimodal guardrails on the fly, based on the permissions of the authenticated user, what data they are trying to access, and what tools they are trying to use. Akto’s approach to agent security is rooted in the belief that teams cannot govern what they cannot see, and as such, runtime visibility and enforcement must be built into the system, as opposed to being an afterthought.

Why It Matters

The reason why Akto has centered the entire approach around agent discovery is because traditional AppSec and Cloud Security tools were not built to deal with agents and prompt-based interactivity. By design, agents are significantly more dynamic than regular applications, often using changing combinations of tools and third party APIs, and using prompts to make decisions that are not easily visible to traditional security tools. As such, discovery needs to be continuous, as opposed to a one time exercise, since an agent’s toolset and behaviors can change significantly once it has been deployed.

Book an AI agent Security demo to see how Akto Atlas and Akto Argus work in action.

Final Thoughts on AI Agent Discovery

Agent discovery extends beyond just discovery and encompasses issues of governance, interoperability, and marketplaces. These address fundamentally different aspects of the problem. As agentic AI systems grow and evolve, visibility is the key to solving a range of issues, including securing, governing, and connecting agents. Tools such as Akto's Atlas and Argus are already demonstrating how continuous and security-centric agent discovery can be executed in practice.

FAQs on AI Agent Discovery

1. Is AI agent discovery a security concept or a technical/architecture concept?

It is both, depending on the perspective. As a security concept, it is about discovering and inventing all AI agents that exist across the enterprise landscape in order to understand the attack surface and govern these agents. As a technical/architecture concept, it is about the mechanisms by which autonomous agents discover each other and negotiate coordination – exemplified by standards such as A2A and MCP. The former is about security-related discovery of agents, while the latter is about discovery as a feature, implemented via specific protocols.

2. What is agent-to-agent capability discovery, and how is it different from security discovery?

Agent-to-agent capability discovery is the process by which one autonomous agent discovers the capabilities of another autonomous agent – typically through standardized representations such as Agent Cards as defined in the A2A specification. This is a fundamentally different concept from security discovery, which is about discovering the agents that exist within our own ecosystem, who owns them, and what they can do. The former concept is about discovering what capabilities exist so that agents can coordinate with each other, while the latter is about understanding the agents we have and governing them accordingly.

3. What is the “Internet of Agents”?

The Internet of Agents is a concept used to describe an envisioned ecosystem where autonomous AI agents developed by different entities can communicate with each other, discover each other’s capabilities, and delegate tasks to each other – similar to how websites and web servers communicate with each other using HTTP and related protocols. Note that this is more of a research vision than an existing standard, and there are several different approaches and standards being developed within the industry.

4. How do autonomous agents discover each other’s capabilities?

In most cases, an autonomous agent will publish a machine-readable description of its capabilities somewhere accessible to other agents (for instance, as an Agent Card). Other agents can then read this description and attempt to find an agent that can perform the tasks they need to delegate. Some protocols allow for querying for agents that expose certain capabilities through well-defined mechanisms. Once a capability has been discovered, the agents can exchange messages using a standardized, structured format and protocol to delegate tasks.

5. Is there a difference between “AI agent discovery” and “AI agent inventory”?

There is a difference between “discovery” and “inventory,” though the two concepts are closely related. Discovery is the ongoing process of identifying AI agents across the enterprise landscape. Inventory is the central repository/view of all AI agents that have been discovered, including information about who owns them and what they can do. The two concepts are linked because the inventory is populated by the results of the continuous discovery process.