What is an agent registry?

Most enterprises don't know how many AI agents they're running. A CSA survey published in April 2026 found that 82% of enterprises had discovered previously unknown AI agents in their environments in the past year. Gartner puts the scale of what's coming into sharper relief: the average Fortune 500 will have over 150,000 agents in production by 2028, up from fewer than 15 in 2025. Only 13% of organizations believe they have the governance infrastructure to manage what they already have.

An agent registry is how an organization accounts for its agents: not just a list of approved deployments, but a system that covers every agent running in the environment, including ones that were never formally sanctioned. It tracks who built each agent, who's accountable for it, what it's authorized to do, what data it can reach, and whether it should still be running. Without that record, agents accumulate permissions, operate on sensitive data without oversight, and leave no trail that compliance teams can reconstruct.

What an agent registry does

The clearest working definition comes from AWS's April 2026 launch of Agent Registry in Amazon Bedrock AgentCore: "a private, governed catalog and discovery layer for agents, tools, skills, MCP servers, and custom resources within the organization." Microsoft's framing in its February 2026 Cyber Pulse report adds the governance dimension: "a centralized registry acts as a single source of truth for all agents across the organization — sanctioned, third-party, and emerging shadow agents — helping prevent agent sprawl, enabling accountability, and supporting discovery while allowing unsanctioned agents to be restricted or quarantined when necessary."

The key distinction between a registry and a simple catalog is that a registry governs, not just lists. A catalog helps developers find and reuse agents. A registry tracks authorization, ownership, lifecycle state, and audit history, and it covers agents the organization didn't formally register alongside the ones it approved.

What an agent registry contains

A complete agent registry tracks several categories of information for each agent.

Agent identity. A unique, managed identity per agent, separate from human accounts and service principals. Without it, an agent is anonymous automation: its actions can't be traced, its permissions can't be scoped, and it can't be decommissioned cleanly when its purpose expires.

Agent card or metadata. A structured record containing the agent's name, version, endpoint, declared capabilities, interaction protocols, and authentication requirements. The A2A (Agent2Agent) protocol, now managed by the Linux Foundation with support from AWS, Microsoft, Cisco, Salesforce, and 150+ organizations, defines a standard Agent Card format that enterprise registries can consume as a baseline for interoperability.

Capabilities and tool access. What the agent can do and what tools it can invoke, including inputs, outputs, preconditions, and the risk level of each tool. This is separate from what the agent claims to be able to do; the registry records what it's been authorized to access.

Permissions and access scope. Scoped, time-bound access tokens rather than broad standing permissions. A key failure mode in deployed agent environments is privilege creep: agents accumulating access beyond what any given task requires, often because permissions were granted at setup and never revisited.

Ownership and accountability. Every agent has a named human sponsor responsible for its purpose and behavior. Governance workflows track ownership changes and handle orphaned agents when a sponsor leaves the organization.

Lifecycle state. Active, suspended, deprecated, or decommissioned. A registry that tracks only active agents leaves "zombie" agents in the environment: agents deployed for a specific task and never formally retired, with live credentials still attached.

Audit trail. Every registration, permission change, invocation, and data access event, logged and queryable. This is what turns an agent inventory into a compliance artifact: the ability to reconstruct what an agent did, when, under whose authorization, and on what data.

Risk classification. Singapore's IMDA framework defines a five-tier autonomy taxonomy, from tool-assisted at Level 0 through fully autonomous at Level 4, with governance requirements that increase at each tier. High-autonomy agents touching sensitive data require different oversight thresholds than narrow, bounded agents with limited tool access. The registry is where those risk classifications live.

What governance frameworks require

Several major frameworks now reference agent registries or agent inventories as explicit requirements.

Singapore IMDA (January 2026, updated May 2026). The Model AI Governance Framework for Agentic AI was described at its Davos launch as the world's first cross-sector governance framework written specifically for AI agents. Its four pillars are agent identity and registration, authority and permission control, behavior monitoring and risk intelligence, and ecosystem and interaction governance. A companion addendum from Singapore's Cyber Security Agency explicitly requires organizations to maintain a trusted agent registry and authenticate agents using verifiable credentials with short-lived tokens. The framework introduced "Agent Identity Cards" as a standardized disclosure format covering each agent's capabilities, limitations, authorized action scope, and escalation protocols.

CISA Five Eyes (May 2026). The joint guidance "Careful Adoption of Agentic AI Services," published by CISA alongside Five Eyes partners from Australia, the UK, Canada, and New Zealand, directly recommends maintaining a trusted registry of components and restricting agent tool access to an approved allow list that's regularly verified as secure. The guidance flags privilege creep and "obscure event records" as primary governance risks, both of which a registry addresses directly.

NIST AI RMF. GV.1.6 of the NIST AI Risk Management Framework requires maintaining an inventory of AI systems resourced according to risk priorities. The CSA's Agentic AI NIST AI RMF Profile (March 2026) extends this to mandate lifecycle governance tracking: what authority each agent holds, what tools it accesses, what delegation relationships it participates in, and when authority should be reviewed or revoked.

Gartner (April 2026). Gartner's six steps to manage AI agent sprawl name "build centralized agent inventory" as Step 2 and "define agent identity, permissions, and lifecycle model" as Step 3. Its prediction: only 13% of organizations believe they have the right governance in place today, and over 40% of agentic AI projects will be canceled by end of 2027 due to governance failures.

How platform-native agent registries work

AWS Agent Registry launched in preview in April 2026 as part of Amazon Bedrock AgentCore. It indexes agents, tools, skills, and MCP servers regardless of where they run: AWS, other clouds, or on-premises. It's accessible via the AgentCore console, CLI/SDK, or as an MCP server that developers can query from their IDEs. The explicit positioning is anti-sprawl: "without a centralized system, agent sprawl accelerates, compliance risks grow, and development effort is wasted on duplicate work."

Microsoft Entra Agent ID reached general availability in April 2026, giving AI agents managed identities with the same Conditional Access infrastructure used for human accounts. Agent 365 serves as the unified control plane for observing and governing agents across Microsoft and partner ecosystems. A registry sync feature in preview as of May 2026 automatically discovers and inventories agents running on AWS Bedrock and Google Cloud.

Google's Gemini Enterprise Agent Platform, rebranded in April 2026, includes an Agent Registry described as "a single source of truth for your enterprise, indexing every internal agent, tool, and skill." It operates alongside Agent Gateway and Agent Identity as part of Google's agent governance layer.

MuleSoft Agent Fabric (Salesforce, GA October 2025) provides an Agent Registry alongside Agent Scanners that automatically discover and inventory agents running on Salesforce Agentforce, Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Copilot Studio. The cross-platform scanning surfaces agents across four major platforms into a single inventory without requiring manual registration for each.

‍

Agent registry vs. agent catalog

The terms appear interchangeably in much vendor documentation, but they describe different things in practice.

A catalog is a discovery and reuse tool. It helps developers find agents that already exist so they don't build duplicates. The audience is primarily engineering teams, and the content is primarily capability descriptions and usage patterns.

A registry is a governance and accountability tool. Its primary function is tracking authorization, not enabling discovery. It covers every agent in the environment, including ones that weren't formally registered, and it records what each agent is allowed to do alongside what it has done. The audience is IT, security, and compliance teams as much as developers.

Microsoft frames the distinction plainly: an enterprise registry covers "sanctioned, third-party, and emerging shadow agents," not just the approved list. A catalog, by definition, contains only what someone consciously added to it.

What platform registries don't cover

Platform-native registries from AWS, Microsoft, Google, and MuleSoft handle the discovery and orchestration problem well. An engineering team can find what agents exist, avoid building duplicates, and connect agents to each other. That's a meaningful capability in an environment heading toward 150,000 agents per enterprise.

Where they're less complete is the governance layer underneath. Three areas stand out.

Shadow agents. The CSA survey found 82% of enterprises have agents they didn't know about. A registry that catalogs sanctioned agents doesn't capture the ones that weren't sanctioned. Governance-grade registries need active discovery: network monitoring, API traffic analysis, and scanning across business-unit environments to find agents that were never registered in the first place.

Data access context. Knowing an agent exists and knowing what data it's accessing are different problems. A registry entry recording an agent's API permissions doesn't show whether that agent is querying a table containing personally identifiable information, whether that table's classification has changed since the agent was provisioned, or whether the data it's acting on meets quality standards. For organizations in regulated industries, that connection between agent identity and data sensitivity is the compliance question that matters.

Audit trails connected to data state. A log that records what an agent queried answers "what did it do?" A governance record that connects that query to the classification status, freshness, and quality of the data it accessed answers "should the result be trusted?" The second question is harder to answer and more relevant when an agent's output feeds a business decision or a downstream automated process.

The agent registry in the Agent Trust Hub

Bigeye's Agent Trust Hub includes an agent registry as part of a broader AI trust infrastructure. The registry connects agent identity and authorization records to the data trust layer: classification status for every data asset an agent can reach, lineage context showing what upstream sources fed each classified asset, and data quality signals that surface whether the data an agent is acting on is fresh and complete. Guardian agents enforce access controls in real time at the point of query, using current classification and policy state rather than a static provisioning record. The result is a registry that answers not just "what agents are running and what are they authorized to do" but "can this agent's output be trusted, given the state of the data it just acted on."