AI Agent Registry: Count Your Agents Before You Govern Them

Most agent-governance programmes start with a policy document. An AI agent registry is the inventory of your organisation's AI agents, Model Context Protocol (MCP) servers, tools and skills, recording who owns each one, which identity it uses and what it may call. Every policy in that document assumes you already know which agents exist. So ask yourself: how many agents does your organisation run, and what can each one reach? If the answer is a guess, that is the gap this note is about. The platforms have noticed it too. Microsoft's Agent 365 registry shows a count of "agents without owners" and another of "unmanaged agents". OWASP's MCP Top 10, still in beta, gives shadow MCP servers an entry of their own.

This note explains what belongs in an AI agent registry, and why a registry only works when something enforces it.

A registry nobody enforces is a spreadsheet. Its value is in the connections it refuses.

If you read only this:

• A registry is the inventory of your agents, MCP servers, tools and skills, with an owner, an identity and a list of what each may call.
• A gateway is the enforcement point. It checks the registry and the agent's identity before any connection is made, and refuses by default.
• Both need a lifecycle. Approve before use, review again when a tool definition changes, and retire agents whose owner has left.

The vendor master, for agents

Finance teams solved a version of this problem long ago. Accounts payable will not pay a supplier who is not in the vendor master, however genuine the invoice looks. The vendor master matters not because it is a list, but because the payment run checks it every time.

An agent registry is the vendor master for your agents and the tools they call. The gateway is the payment run.

Here is the running example. Picture a platform team at a mid-size insurer, asked by its security lead for a count. It is an illustrative scenario, not a client story. In a week, they find four kinds of agent:

1. A claims-triage agent the team built and runs on Google Cloud.
2. An invoice assistant the finance team built in Copilot Studio and shared with colleagues.
3. An MCP server on a developer's laptop, installed from a public listing, that can read the claims database.
4. A repair-shop network's booking agent, which the claims agent calls over A2A (Agent2Agent).

Each needs the same three answers: who owns it, what identity it uses, and what it may connect to.

What an AI agent registry is

The major platforms now describe the same thing in similar words:

• Google Cloud. Google's Agent Registry overview says it lets you "register, discover, and govern agentic components": agents, MCP servers and tools, endpoints, and standalone skills. Agent Registry reached general availability on 18 June 2026, according to the Agent Platform release notes, as part of Gemini Enterprise Agent Platform, which Google describes as an evolution of Vertex AI.
• AWS. AWS Agent Registry, as its general availability announcement describes it, is a private, governed catalogue of agents, tools, skills, MCP servers and custom resources, whose records you can also discover from Amazon Bedrock AgentCore. It entered preview through AgentCore on 9 April 2026, according to the Agent Registry preview announcement, and became generally available on 31 August 2026.
• Microsoft. The Agent 365 registry is a unified inventory of all agents in the organisation, Microsoft and non-Microsoft. Microsoft is converging its registry experiences there, while Entra Agent ID remains the identity foundation, as its Agent Registry convergence page explains.

A registry is not a package registry. The official MCP Registry, still in preview, makes the distinction itself: it hosts metadata that points to packages on npm, PyPI or Docker Hub, and it leaves security scanning to those package registries and to downstream aggregators. It also does not accept private servers. For those, it recommends that you host your own private registry.

What to record for each entry

A registry entry earns its place when it answers the questions an incident review or an auditor will ask. Here is a starting set of fields, applied to the claims-triage agent:

Much of this can come from documents the components already publish. An Agent Card, defined in the A2A specification and served at /.well-known/agent-card.json, describes an agent's skills and how to authenticate with it, and can be signed. The A2A specification lists curated catalogues as one way to discover agents. An MCP server's server.json gives it a reverse-DNS name, which the public MCP Registry ties to a verified GitHub account or domain. Agent Skills, now hosted by the Agentic AI Foundation, has a proposed roadmap that starts with versioned releases and security guidance, according to Anthropic's announcement, Donating Agent Skills to the Agentic AI Foundation.

Treat all of that as a claim, not a fact. An Agent Card says what an agent offers. The registry records what you have approved it to do, and the identity proves which agent is asking. Our note on AI agent identity covers that third part.

Discovery: find what is already running

You cannot register what you have not found. The platforms help in different ways:

• Google Cloud registers supported workloads in a project automatically. You register custom components and external endpoints by hand.
• AWS can pull metadata, such as tool schemas, from a live MCP server or agent endpoint given its URL. Records need administrator approval before anyone can discover them.
• Microsoft lists agents shared by individual creators alongside those published by the organisation, and flags agents managed outside Agent 365.

Run the four agents in the example through that net. The claims-triage agent appears automatically. The finance assistant appears in Agent 365 as a shared agent. The booking agent is found in the claims agent's configuration, or in the gateway's logs once traffic flows through one.

The laptop MCP server appears nowhere. No cloud registry sees a process on a developer's machine. This is the shadow MCP server OWASP describes: an unapproved deployment operating "outside the organization's formal security governance". Finding it takes endpoint inventory and network egress logs, not a registry. The registry's job starts once it is found: register it, give it an owner, or remove its access to the claims database.

Open the diagram full size:

Enforcement: the gateway refuses what the registry does not know

The vendor master works because the payment run checks it. For agents, the payment run is a gateway that every call passes through.

Keep the two jobs apart. The table splits them for the example insurer.

The vendors' own pages draw the same line. Google's Agent Registry overview calls the registry the "authoritative registry" and names Agent Gateway as the enforcement point: before routing, it "queries Agent Registry and evaluates your configured IAM and content security policies." Its IAM access policies "bind agent principals to the target resources registered in Agent Registry". The registry page does not say the registry enforces anything by itself. The AWS general availability announcement, dated 31 August 2026, describes "a private, governed catalog and discovery layer" with approval workflows, and says nothing there about IAM or policy enforcement. Microsoft's registry overview lists inventory and risk signals, with admin actions to block or delete an agent.

On Google Cloud, that is Agent Gateway. According to Google's Agent Gateway overview, it governs outbound requests from agents to "external tools, remote MCP servers, SaaS APIs, or downstream agents", and inbound traffic from clients to hosted agents. Before it routes a request, it queries Agent Registry and evaluates your policies. The default is the one you want: "all connections are blocked unless an explicit IAM policy grants access." It can also send prompts and tool responses through Model Armor to screen for prompt injection and data leaks. Google's Agent Platform release notes record that Agent Gateway reached general availability on 18 June 2026 for agents on Agent Platform. Google says support for GKE, Cloud Run and cross-cloud environments will follow through an early preview.

The other platforms place the enforcement point differently:

• AWS. The AgentCore Gateway documentation describes a single entry point for agent traffic, handling both inbound and outbound authentication. AgentCore Policy, generally available since 3 March 2026 according to the Policy general availability announcement, intercepts Gateway tool calls before they run, with rules written in plain language or in Cedar, as the AWS News Blog post Amazon Bedrock AgentCore adds quality evaluations and policy controls describes.
• Microsoft. Agent 365 holds the inventory and shows its risk signals. Enforcement runs through Entra for agents that have an Entra agent identity: Conditional Access policies, including a template that blocks high-risk agents, listed in What's new in Microsoft Entra Agent ID.
• Anthropic and OpenAI APIs. The model API connects to whatever MCP server URL your code passes, so the allow-list is yours to apply. Per Anthropic's MCP connector documentation, the connector can enable only named tools, and a newer beta can pin a server's tool list so that it cannot change mid-conversation. OpenAI's MCP servers guide says its MCP tool imports only the tools in allowed_tools, and asks for approval before sharing data with a server unless you turn that off. Put your own egress proxy in front of both if agents must reach only registered servers.

Open the diagram full size:

In the example, the claims-triage agent's calls to the claims MCP server pass: the server is registered and the agent holds a grant. Its calls to the booking agent pass too. When the laptop server is finally registered, it is a new entry with no grants until someone approves it.

Lifecycle: approve, review again, retire

A vendor master that is never cleaned fills up with suppliers nobody uses. The same happens to agents, and faster.

Open the diagram full size:

• Approve before use. AWS Agent Registry makes approval a step before discovery. Do the same wherever your platform does not.
• Review again on change. An MCP server can change its tools at any time. Pin the approved tool list and descriptions, and treat any change as a new approval, as our note on MCP vs A2A recommends.
• Keep an owner on every entry. Agent 365 counts ownerless agents and lets administrators block or delete them. Entra Agent ID's sponsor workflows hand an agent's sponsorship on when its sponsor changes role or leaves.
• Retire on purpose. A retired entry loses its grants at the gateway on the same day. Otherwise it is only marked retired in the registry while it keeps working.

Where each platform puts these pieces

Honest limits

• Registries are per platform. The organisation in the example needs Agent 365 and a cloud registry at once. We found no standard yet that federates them. The MCP Registry publishes an OpenAPI interface that private registries can implement, which is a start for MCP servers only.
• Discovery is never complete. Laptops, embedded SaaS agents and personal accounts escape every cloud console. Count what the gateway sees as well as what the registry lists, and investigate the difference.
• Entries are claims. Metadata is written by whoever registers the component. Signed Agent Cards, verified namespaces and per-agent identities narrow the gap; none closes it.
• A registry is not a security review. The public MCP Registry says plainly that it delegates scanning. Your approval step must include the review.
• A gateway is a choke point. Every call now depends on it. Decide in advance whether it fails closed or open, and test that decision.
• Status moves. On 29 October 2026 the MCP Registry was still in preview, and Agent Gateway support for GKE, Cloud Run and cross-cloud environments was still promised through an early preview. AWS Agent Registry was in preview from 9 April until it became generally available on 31 August 2026, so check labels on the day you decide.

Takeaways

• Inventory first. You cannot govern, secure or cost an agent you have not counted.
• Registry plus gateway. The list matters only because a gateway refuses what is not on it.
• Identity ties them together. The gateway decides on who is asking; the registry says what they may reach.
• Owners and change control. Every entry has an owner, and every change to a tool sends it back for review.

Reread-me checklist

• Every agent, MCP server and skill in production has a registry entry with a named owner and sponsor.
• Each entry lists its identity and the exact servers, tools and agents it may call.
• Tool lists and descriptions are pinned at approval, and any change triggers a new review.
• All agent traffic passes a gateway or proxy that denies unregistered targets by default.
• Discovery runs on a schedule, including endpoint and egress data, and differences are investigated.
• Ownerless entries are suspended until someone takes them on.
• Retiring an entry removes its grants at the gateway on the same day.

What's next

A registry tells you which agents exist. The next questions are who each agent is when it calls something, and how much it may do without a person. Our note on AI agent identity, linked above, covers the first, and our note on autonomy tiers and human approval covers the second.

Count your agents this week, and send us the number that surprised you: the gap between what your registry lists and what your gateway sees. If you are building MCP servers that will sit behind such a gateway, our MCP engineering work covers their design and review, and an AI agent readiness assessment is the place to start if your agents are not in production yet.

Further reading

• The MCP Registry, Model Context Protocol: A plain account of what a public registry does and does not do, and why it suggests you run a private one for your own servers.
• A2A specification, A2A project: How Agent Cards are published, signed and discovered, which is most of what a registry entry for a remote agent can start from.
• OWASP MCP Top 10, OWASP: The shadow MCP server and the other risks a registry and gateway are meant to contain, in a form you can use in a threat model.
• Agent Gateway overview, Google Cloud: A clearly documented example of a gateway that consults a registry and denies by default, useful as a model whichever platform you run.

Registry and gateway products are moving from preview to general availability quickly, and their labels change, so check each vendor's own page before you rely on a label.