- Home
- AI agents
- AI agent registry and sprawl
- What is an AI agent registry?
Govern and secure · AI agent registry and sprawl
What is an AI agent registry?
An AI agent registry is a catalogue with one record per AI agent: its name and purpose, its owner, the identity it runs under, the tools and data it can reach, its risk tier, its version and its approval state. People use it to answer who owns what; agents and gateways use it to find approved agents and tools.
In this guide: 83 pages
Key takeaways
- A registry entry is useful when it names an accountable person and an identity that can be revoked. Everything else is detail that helps you decide how closely to watch the agent.
- Three products hold the core fields natively on 2 Nov 2026: the Microsoft Agent 365 registry, AWS Agent Registry and Google Agent Registry. Risk tier, data classes and review date are fields you add as tags.
- A registry is read by two kinds of client: admins who want to know who owns what, and agents or gateways that want to find an approved tool or agent. The second use is why AWS exposes the registry as an MCP endpoint (MCP, the Model Context Protocol, is the standard agents use to call tools) and Google enforces it through Agent Gateway.
- It is a different thing from a CMDB, a model registry and an MCP registry. Each of those answers a different question, and a mature setup links them rather than merging them.
What goes in a registry entry?
An entry holds the fields that let someone act on the agent without opening it: who to call, which identity to disable, which systems it touches, how risky it is and whether it is approved. The table lists the fields we ask for and why each one matters when something goes wrong.
Fields in a registry entry and why each one matters. The last column says where the three cloud registries hold the field on 2 Nov 2026.
| Field | Why it matters | Where the products hold it |
|---|---|---|
| Name, description, purpose | A reviewer can tell two "HR assistant" agents apart only if the purpose is written down. Duplicates are found by purpose, not by name. | Name and description native in all three; purpose is written by the owner (Microsoft also exports the agent’s instructions) |
| Platform, environment, source | Tells you which kill switch applies. A Copilot Studio agent is quarantined through Power Platform; a Foundry agent is stopped in Foundry Control Plane; an AgentCore agent is cut off through AgentCore Policy and Gateway authorization, then deprecated in the registry. | Native: Microsoft (platform, channel), AWS (provenance, source ARN), Google (project and resource) |
| Version | Behaviour changes with the prompt, model and tools, so a record must say which version is approved. AWS keeps the approved revision live while a new draft is reviewed. | Native in all three |
| Owner | The person who answers for the agent’s behaviour and receives the alerts. Microsoft counts agents without owners as a headline number for a reason. | Native: Microsoft owner, AWS publisher and ownership fields, Google owner in Gemini Enterprise |
| Sponsor | The business person who answers for why the agent exists, so that an agent survives its builder leaving. Entra can transfer sponsorship when someone changes role. | Microsoft Entra Agent ID; tags on AWS and Google |
| Identity | The thing you disable. An agent with its own identity can be blocked by Conditional Access, audited by name and revoked without touching a human account. | Microsoft Entra Agent ID; AgentCore Identity; Google Agent Identity (a SPIFFE ID, an open standard for workload identities; API in preview) |
| Tools, connectors, MCP servers | Tells you the blast radius: an agent that only reads SharePoint is a different risk from one that calls an HTTP connector into SAP. | AWS descriptors; Google registered MCP servers and tools; Microsoft connector usage in Power Platform inventory (preview) |
| Data reached and data classes | Needed for data protection reviews and for the EU AI Act deployer duties. The products do not classify data for you. | Tags on all three; Purview signals feed the Microsoft Risks column |
| Acts for a user or as itself | A delegated agent can never exceed the user’s rights; an autonomous agent has its own grants and needs a tighter review. | Entra blueprint and identity type; AgentCore inbound and outbound auth settings; Google Agent Identity |
| Risk tier | Decides how much review the agent gets before it is published and how closely it is monitored after. | A tag you define (Microsoft allows up to 50 admin-managed tags; AWS custom metadata) |
| Approval state | Separates "exists" from "allowed". Only approved AWS revisions are returned to agents by the discovery APIs; Microsoft holds unpublished agents in the Requests queue. | Native: Microsoft Requests queue; AWS DRAFT to APPROVED; Google sharing review |
| Review date and retirement | The field that stops the list growing forever. Microsoft’s own practice deletes individually owned agents when the employee leaves. | A tag you define; Microsoft and Entra deletions carry a 30-day recovery window |
| Monitoring link | Where the traces, costs and evaluation results live, so an incident starts from the record. | Foundry Control Plane shows runs, error rate and cost per agent; AgentCore Observability; Google Agent Observability |
Microsoft says the admin center can export more than 30 items for each agent, so do not expect to fill every column by hand. Take what discovery gives you, then add the tags.
How is a registry different from a CMDB, a model registry and an MCP registry?
These four catalogues answer four different questions. The agent registry says which agents exist and who owns them. The CMDB (the IT service management database of servers, applications and services) says what they depend on. The model registry says which model versions are approved. The MCP registry (a catalogue of tool servers that speak the Model Context Protocol) says which tool servers are available. Link them; do not try to merge them.
Four registries, the question each one answers and an example as of 2 Nov 2026.
| Catalogue | One record per | Question it answers | Examples |
|---|---|---|---|
| AI agent registry | Agent (and, on AWS and Google, MCP servers and skills) | Which agents exist, who owns them, what they can reach, are they approved? | Microsoft Agent 365 registry; AWS Agent Registry; Google Agent Registry; ServiceNow AI Control Tower |
| CMDB | Configuration item: server, application, service, database | What does this agent depend on, and what depends on it? | ServiceNow CMDB; AI Control Tower maps AI assets onto it |
| Model registry | Model version or prompt version | Which model and prompt versions are approved, and when do they retire? | MLflow Model and Prompt Registry; Foundry model catalogue with retirement dates; Amazon Bedrock model lifecycle |
| MCP registry | MCP server | Which tool servers can an agent connect to, and from where? | The official MCP Registry (preview since 8 Sep 2025); private sub-registries; AWS Agent Registry and Google Agent Registry also hold MCP servers |
The lines are moving. AWS Agent Registry and Google Agent Registry both store MCP servers and skills next to agents, so for those two clouds the agent registry and the MCP registry are the same product. The model registry stays separate everywhere, because models retire on the vendor’s schedule, and an agent record must point at a pinned version rather than contain it.
Who reads the registry, and how?
Two audiences read it. Admins and auditors read it through a console or an export to answer who owns what and how many agents exist. Agents and gateways read it through an API to find an approved agent or tool at run time. The second use is newer and changes what the registry has to be.
For people, the Microsoft 365 admin center shows the registry with counters for Total agents, Agents without owners and Unmanaged agents, and exports the records to a file. Microsoft Graph lists the same agents through a preview endpoint. On AWS, the management APIs return the latest revision of a record in any state; on Google, the Agent Registry API and the console list what is registered in a project.
For agents, AWS exposes the registry as an MCP endpoint and through discovery APIs that return only approved revisions, so an agent that asks for a tool can only find one a curator has approved. Google enforces the registry through Agent Gateway, the policy point every tool call passes through, and uses agent cards from the A2A agent-to-agent protocol to describe agents to each other. On Microsoft, the equivalent is the agent store: an agent reaches users only after an admin publishes it from the Requests queue.
This second use is why approval state matters more than any other field. A registry that agents consult at run time is also an allow list, and an unreviewed record in it is an unreviewed tool in production.
How do Microsoft, AWS and Google implement it?
How the three clouds implement the registry, with statuses as the vendor pages showed on 2 Nov 2026.
Capability, Microsoft, AWS, Google
| Capability | Microsoft | AWS | |
|---|---|---|---|
| Product and status | Agent 365 registry in the Microsoft 365 admin center, generally available 1 May 2026; Entra Agent Registry converged into it in April 2026 | AWS Agent Registry, public preview 9 Apr 2026, generally available 31 Aug 2026 in five Regions | Agent Registry in Gemini Enterprise Agent Platform, generally available 18 Jun 2026 |
| Record types | Agents (Microsoft, partner, Copilot Studio, Agent Builder, Foundry, SharePoint, SDK-registered) | Agent, MCP server, skill, gateway, custom | Agents (A2A v1 agent cards), MCP servers and tools, endpoints, skills |
| Fills itself from | Power Platform inventory, Foundry Control Plane, Defender AI agents inventory, Agent 365 SDK | Auto-detection of AgentCore Runtimes and Gateways across AWS Organizations | Supported workloads deployed in the project; external endpoints registered by hand |
| Approval | Requests queue (Pending review, Pending update, Pending activate), Publish to store or Reject submission | DRAFT, PENDING_APPROVAL, APPROVED, REJECTED, DEPRECATED; only approved revisions are discoverable | Admin review of sharing requests in Gemini Enterprise (generally available 23 Feb 2026) |
| Read by agents | Through the agent store and Microsoft 365 Copilot; Graph API in preview for admins | MCP endpoint and discovery APIs | Agent Gateway; A2A agent cards |
Google’s release notes carry conflicting labels for Agent Identity (generally available at the platform launch, Agent Identity API in preview on 18 Jun 2026), so this page calls the API a preview.
Frequently asked questions
What is the main purpose of an AI agent registry?
To make every agent accountable and controllable: one record that names an owner, an identity that can be disabled, the tools and data the agent reaches, a risk tier and an approval state. A second purpose, newer, is to let agents and gateways find approved tools and agents at run time.
Is an A2A agent card a registry?
No. An agent card is a self-describing manifest one agent publishes at /.well-known/agent-card.json (name, description, version, skills, security schemes, and optionally a signature). A registry is a curated catalogue of many agents with approval attached. Registries store and validate agent cards; AWS Agent Registry and Google Agent Registry both do.
Do we need a registry if we only use Microsoft 365 Copilot?
Yes, once staff can build agents. Agent Builder and Copilot Studio agents appear in the Microsoft 365 admin center registry and in Power Platform inventory whether or not you look. The useful step is to turn on the management rules for ownerless and unused agents and to decide which agents need approval before they are published to everyone.
Who should be able to edit a registry record?
Discovery writes the fields it can observe (platform, version, provenance); the owner edits purpose and reach; only a curator changes risk tier and approval state. AWS makes this explicit with ReadOnly, Consumer, Publisher and Admin permissions and a curator step in the approval flow. On Microsoft the Requests queue is the equivalent gate.
Can agents built outside the cloud be registered?
Yes, by hand or through an SDK. Microsoft registers non-Microsoft agents through the Agent 365 SDK and syncs with AWS Bedrock and Google Cloud in public preview; Google takes manual registration of external endpoints; AWS lets you create records manually or from a URL. Automatic discovery is strongest for each vendor’s own platform; Microsoft Defender also discovers agents on supported non-Microsoft platforms, including Amazon Bedrock and Google Cloud.
More in AI agent registry and sprawl
Sources
Each source was read on 2 November 2026. The date shown is the date on the page, or the page’s ms.date for Microsoft Learn; an undated page shows the date it was read.
- Agent Registry in the Microsoft 365 admin center
- Agent Registry convergence with Microsoft Agent 365
- Agent settings in the Microsoft 365 admin center
- Agent requests
- Microsoft Entra Agent ID key concepts
- Manage agents in Foundry Control Plane
- Power Platform inventory
- Deploying Microsoft Agent 365 at Microsoft
- AWS Agent Registry now generally available
- AWS Agent Registry record lifecycle
- AWS Agent Registry developer guide
- The future of managing agents at scale: AWS Agent Registry now in preview
- Agent Registry overview
- Gemini Enterprise Agent Platform release notes
- Gemini Enterprise release notes
- A2A protocol specification, version 1.0.0
- Introducing the MCP Registry (preview)
- Foundry Models lifecycle and retirement
Planning an AI program?
Talk to the team that builds it and runs it after launch.
- Built to SOC 2, HIPAA and GDPR standards
- EU AI Act-aligned delivery
- Microsoft Solutions Partner