Agent proliferation is a fact: as companies adopt AI agents across every part of their business, from customer support to code review, the number of agents, MCP servers, and skills in an enterprise is rapidly multiplying.
Gartner expects the average Fortune Global 500 company to use more than 150,000 AI agents by 2028. Only 13% of organizations surveyed believe they have the right governance in place for AI agents.
Inventory is the first step to security, after all, you cannot secure what falls under your radar, and that’s where an AI agent registry enters the scene.
This article introduces agent registries and their main features, and then covers:
- How to keep your agent registry automatically updated.
- How to integrate an agent registry with access policies.
- How agent registries fit in other areas of security.
What is an AI Agent Registry
An agent registry is a centralized catalog to store metadata and descriptions of AI agents. Each record contains descriptive information about an agent, but it can also hold access information, policies, or even a history of security events related to the agent.
Think of an agent registry as an inventory for agents in your company or project. Once populated, it becomes a source of truth that other elements can rely on:
- It provides accountability.
- It gives visibility into agent governance and ownership.
- It can be used to discover skills, models, and MCPs available.
- It displays the agent lifecycle clearly.
- It maps an agent’s relationships with other systems.
And like any inventory, its real value is in its ability to support other tools:
- LLMs: Can query the registry to discover the right agent for a task.
- Agents: Can self-register to keep the inventory automatically updated.
- Compliance: Can continuously run controls on agents.
- Vulnerability Management: Can check the agents for known vulnerabilities.
- IAM: Can use an agent’s metadata as input for access policies.
- Detection and response: Can use the metadata as input for runtime policies, and as context on security events to help investigation.
Why Agents Should Self-Register
Anyone who has dealt with inventories has the same pain. Manually updating the inventory takes too much effort and leads to errors and metadata drift. When users can’t trust the inventory’s data, they simply don’t use it.
That’s why, although agent registries allow for manual insertion and updating of agents, the preferred ways are via automation:
Registry API and CI/CD pipelines: Registries offer APIs you can leverage in your CI/CD pipelines to register any changes to the agent on deployment. These APIs often use the A2A’s Agent Card to represent the agent’s metadata.
Platform-native registration: Some platforms, like Google Cloud, register (or update) the agent automatically as part of the deployment process. Leverage these tools to simplify your deployments.
Related to identity, agents should register info about their identity providers so users and other agents know what credentials to use when accessing them. You’ll find an example of what this looks like in the section below.
How A2A Supports Agent Registration
Agent2Agent (A2A) is an open standard that enables seamless communication between agents. While MCP is meant for agents to access resources, A2A has a different scope focused on communication and task coordination between agents.
While A2A’s scope is limited to communication between agents, registries broadly use its agent card format to transfer agent metadata.
- Each platform has its own quirks, but overall most support some kind of self-registration.
- Overall, their flow is as follows.
Step 1: The agent publishes its own metadata in Agent Card format stored in a well-known location at /.well-known/agent-card.json.
Agent card is A2A’s standard for representing an agent, and it’s designed to provide the essential information in a compact manner, so other systems can find and read it.
Here’s an example Agent Card using the format defined for an A2A-compliant agent:
{
"name": "invoice-processor-agent",
"description": "Processes and validates vendor invoices against declared pricing data.",
"version": "1.2.0",
"supportedInterfaces": [
{
"url": "https://agents.internal.company.com/invoice-processor",
"protocolBinding": "HTTP+JSON",
"protocolVersion": "1.0.0"
}
],
"skills": [
{
"id": "invoice-validation",
"name": "Invoice Validation",
"description": "Validates invoice line items against vendor pricing records.",
"tags": ["finance", "invoices", "read-only"],
"examples": [
"Check invoice INV-2291 against vendor pricing"
]
}
],
"securitySchemes": {
"corp-oauth2": {
"type": "oauth2",
"description": "OAuth2 client credentials",
"flows": {
"clientCredentials": {
"tokenUrl": "https://auth.internal.company.com/oauth/token",
"scopes": {
"invoice:read": "Read access to invoice records"
}
}
}
}
},
"security": [
{ "corp-oauth2": ["invoice:read"] }
]
}Let’s see some of the fields being presented in the agent card:
supportedInterfaces:This answers the question: “How do I connect with this agent?”. So expect here a list of endpoints of type JSON-RPC, gRPC, or HTTP+JSON.skills:A list of the capabilities of this agent, describing what it does.securitySchemes:the expected identity that callers need to present (like apiKey, oauth2, mTLS, etc.). Note that this is not the authentication itself, just the method that needs to be used.
Step 2: The environment detects the change in the agent
As we mentioned earlier, the A2A protocol is limited to agents and doesn’t cover agent registries. There isn’t a broadly adopted standard for this step, and each registry and platform has its own mechanism. For example, in Google Cloud, this is achieved via a cloud configuration in Agent Runtime, or using introspection tools in a Kubernetes Cluster.
Step 3: The observer provides the agent card to the registry.
Step 4: The registry parses the agent card and updates the entry. Most registries would validate the card against the A2A schema version (e.g., 0.3, 1.0) and insert it as a record.
Now that we know how the registry gets populated, let’s see what the main interactions with our system are.
Where Agent Registry fits with Discovery
The main benefit of an agent inventory is that it lists the capabilities of all available agents.
Think of an agent that just received a prompt that it can’t fulfill on its own. It could query the registry to find an MCP server to complete the task. Then, the agent could use the identity information on the securitySchemes field of the record to choose the right credentials to access the MCP server. At scale, agents can use this information with IAM tools to request just-in-time access to the resources they need, similar to what we saw with AWS Bedrock AgentCore. This means that administrators don’t need to provision credentials for each agent, and they can focus on defining access policies.
Additionally, agent registry systems include what are called heartbeat checks (agent-reported) or liveness checks (registry-polled), which are confirmations from the agent that it is still alive, updating its current status (e.g., from stale to active).
Example: Discovery on AWS Agent Registry
AWS’s strength is discovery, as it lets you query agent registry records from the CLI (as an MCP server) or from the data plane API.
Using AWS CLI, you can try querying your agent registry for all entries:
aws agent-registry list-discoverable-registry-records \
--registry-id "lDlsA0gpH2RHJ3cV" \
--region eu-west-1This returns the following output:
{
"registryRecords": [
{
"registryArn": "arn:aws:agent-registry:eu-west-1:238762754852:registry/lDlsA0gpH2RHJ3cV",
"recordArn": "arn:aws:agent-registry:eu-west-1:238762754852:registry/lDlsA0gpH2RHJ3cV/record/qvD20qu8wYxE",
"recordId": "qvD20qu8wYxE",
"name": "weather-server",
"displayName": "WeatherServer",
"recordType": "MCP",
"recordVersion": "1.0",
"status": "APPROVED",
"createdAt": "2026-09-03T09:48:36.820467+00:00",
"updatedAt": "2026-09-03T09:56:22.736777+00:00"
},
{...}
]
}
From this information, you can now extract elements like:
recordId:the specific ID of the entry in the agent registry.recordType:in this case, it indicates that this record represents an MCP.status:what is the current status of this agent (DRAFT, PENDING_APPROVAL,...)
With that, you can now query a specific entry for further information on an agent in your system:
aws agent-registry-control get-registry-record \
--registry-id "lDlsA0gpH2RHJ3cV" \
--record-id "qvD20qu8wYxE" \
--region eu-west-1This returns all metadata and information from that entry, including a connector to the MCP, that you can later use to discover available tools.
Where Agent Registry fits with Access Policies
IAM tools and other identity providers can use the metadata stored in agent registries as inputs to decide whether an access request should be approved or not. In other words, a policy engine can ask, “Does this request fall within what this agent is allowed to do?”
As we mentioned earlier, policy-based access is easier to manage at scale, as you can focus on a set of rules instead of provisioning each actor individually.
It also enables identity best practices like short-lived credentials, JIT (just-in-time) access, or on-behalf-of tokens.
Example: Authorization Policies on Google Cloud’s Agent Gateway
Google Cloud’s Agent Gateway has a useful connection with agent registry: When an agent makes a request, Agent Gateway orchestrates a lookup and delegation process to determine whether to allow or deny the request.
How does it work internally?
- Agent Gateway looks up metadata in the registry to enforce granular access policies.
- Agent Gateway delegates authorization to Agent Platform Policies (e.g., IAM)
- If the call is not permitted, it doesn’t go through.
Consider this agent registry entry for an MCP tool. Note that this vendor pricing tool modifies data as indicated by the readOnlyHint annotation.
{
"tools": [
{
"name": "update_vendor_pricing",
"description": "Updates pricing records for a vendor.",
"annotations": {
"title": "Update Vendor Pricing",
"readOnlyHint": false
}
}
]
}And a Gateway configured to use the Agent Registry to retrieve context.
name: AGENT_GATEWAY_NAME
protocols:
- MCP
googleManaged:
governedAccessPath: AGENT_TO_ANYWHERE
registries:
- AGENT_REGISTRY_PATH
The invoice agent needs to look up vendor prices to validate invoices. Its access policy allows only read-only tools on the vendor pricing server. When the agent calls update_vendor_pricing, the gateway checks the tool’s registry entry. The entry marks the tool as readOnlyHint: false, so the gateway blocks the call.
Agent Registry in Other Areas of Security
Detection and response (D&R) systems scan and monitor your system for hidden threats and unexpected patterns. In these systems, context is key in order to differentiate normal behavior from a strange action, similar to the mentioned context provided to access control.
Agent registries can be connected with D&R tools bidirectionally. On one side, the registry can enrich security events with context; on the other, D&R tools can log the security events related to an agent in the registry.
More importantly, the agent registry can also annotate its entries with findings from the D&R systems for a particular agent. One example agent registry that supports this flow is Microsoft Agent 365.
Agent registries could also complement regular inventories in tasks like continuous compliance and vulnerability management. If an agent falls out of compliance or has vulnerabilities, it’s possible to check its ownership to know who to ping to solve the issue. However, we haven’t found any security product that supports this workflow, so it would require a manual check or some custom development on your side.
Agent Registry is Still Maturing
In general, the idea of agent registries seems promising, but it’s still a young ecosystem.
There are plenty of initiatives like NANDA, an attempt to create a global catalog of agents like a DNS for AIs, or the LOKA Protocol, a decentralized framework with a consensus protocol that could enable agents to make ethical decisions. But still, these initiatives are in very early stages.
We expect this ecosystem to grow, as agent registries have the potential to become a cornerstone of agentic AI.
What to Remember
Agent registry fits perfectly in the agent ecosystem: it serves as an inventory of your agents, not only for humans but for other agents and processes in your company. But great power comes with great responsibility: The registry is only useful if the metadata info accurately represents the real world.
An agent registry really shines when you connect it with your enterprise identity security, by feeding context to runtime policy tools, supporting agent discovery within your ecosystem, and helping detection and response tools find suspicious patterns.
Be aware of the challenges associated with agent registries, like metadata drift, scaling issues, and ambiguity around governance and ownership.
