AWS Daily Intelligence #22 - AWS Agent Registry Goes GA, and the Approval Queue Becomes an Allowlist

Executive summary

AWS Agent Registry reached general availability yesterday: a fully managed discovery service that provides a centralized catalog for organizing, curating, and discovering resources across your organization. You publish MCP servers, agents, skills and custom resources into it, and consumers find them by search or by connecting to the registry's own MCP endpoint.

Read as a catalogue, it is unremarkable — every organisation has tried to build one and most have decayed. Two design decisions make this one different, and both are worth understanding before you decide whether it is a documentation tool or a control.

The first is that it does not depend on anyone registering anything. Organisation-wide auto-detection finds agents and MCP servers already running on AgentCore Runtime and Gateway across every account, and files them as draft records. The second is the consequence of the approval workflow: only approved records are discoverable, and the audience for that discovery includes the agents themselves. The curator's queue is not a backlog of documentation to tidy. It is the list of tools an agent in your organisation is able to find.

What changed

AWS Agent Registry is described as a private, governed catalog and discovery layer for agents, tools, skills, MCP servers, and custom resources within your organization. It is organised around two resources: registries, which you create in your account, and registry records, each describing one published resource.

Each registry carries its own Name, Description, Authorization configuration (IAM or JWT), approval settings, and set of records — so a registry is a policy boundary as much as a container. You can run one organisation-wide registry, or several split by resource type, by stage (production, QA, development), or by team.

Four record types are supported: MCP, Agent, Skill and Custom. AWS Agent Registry validates MCP and agent records against their respective protocol schemas, and supports custom metadata for all resource types — so a malformed MCP descriptor is rejected at publish time rather than discovered by whatever tries to use it.

It is generally available in five Regions: US East (N. Virginia), US West (Oregon), Europe (Ireland), Asia Pacific (Tokyo) and Asia Pacific (Sydney).

Architecture

The lifecycle is the control

Records progress through configured lifecycle states, from draft to pending approval to approved, rejected, or deprecated, as reviewers grant approvals. Nothing is discoverable until it reaches approved, and AWS is explicit that administrators control what builders in their organization can discover and use, and can remove resources being discoverable at any time.

Deprecation matters as much as approval here. A tool that was appropriate six months ago and is now superseded, or one whose backing endpoint has moved, can be pulled out of discovery without deleting the record or chasing down whoever published it.

Auto-detection inverts the usual failure mode

Internal catalogues fail in a predictable way: they are populated once, during a push, and then reality moves and the catalogue does not. What is registered becomes a parallel truth that is worse than no catalogue, because people believe it.

Organisation-wide auto-detection is the answer to that, and it is the most interesting thing in this launch. Registry automatically detects agents and MCP servers running on AgentCore Runtime and AgentCore Gateway across every account in the organization, and detected resources appear as draft records following standard governance lifecycles. The catalogue starts from what is running rather than from what someone remembered to declare — and because detections land as drafts, discovery of an unregistered agent does not silently make it usable.

Note the scope carefully. Auto-detection covers AgentCore Runtime and Gateway. An agent running on Lambda, on ECS, in a container on someone's workstation, or against a third-party model endpoint is not detected. "The registry knows about our agents" is a claim scoped to one hosting substrate, and worth stating that way internally.

The registry speaks the protocol it catalogues

The Registry is available at a remote MCP endpoint that lets MCP-compatible clients interact with the registry directly using the Model Context Protocol. Discovery is therefore available to an agent mid-task, not only to a person browsing a console, and the same endpoint serves an IDE.

This is genuinely useful and it is the design decision with the longest tail. It means the answer to "what tools exist in this organisation" is a queryable resource with its own authorization: you choose between AWS IAM credentials or JSON Web Tokens (JWT) from your corporate identity provider to control who can search, browse, and invoke the registry's MCP endpoint.

Business value

The value is not the catalogue. It is that two questions become answerable that mostly are not today.

• What agents and MCP servers are running in our organisation? Auto-detection answers this for the AgentCore substrate without anyone filling in a form.
• Which of them is a team allowed to build on? The approved set answers this, and it is enforced at discovery rather than published as guidance.

The secondary benefit is the one AWS leads with and it is real: teams rebuild MCP servers and tools that already exist because they cannot find them. That is ordinary duplicated effort, and a searchable catalogue with semantic and keyword matching addresses it. But duplication is a cost problem, and the discovery-as-allowlist property is a control problem — the second is the reason to treat this as platform infrastructure rather than as a wiki replacement.

Security considerations

Treat approval as a security review, because that is its effect. An approved record is a resource an agent can find and invoke; an approved record describing a tool with broad permissions is an escalation path that arrives through discovery rather than through a deployment. The workflow is described as ensuring only records meeting your organization's criteria for security, compliance, and quality are discoverable — the criteria are yours, and if nobody has written them the approval step is a rubber stamp with an audit trail.

Three things to get right at setup:

• Separate the publisher and curator roles in IAM. If the team that publishes a record can also approve it, the lifecycle is decorative. The docs define distinct personas for exactly this reason.
• Wire the approval notification to something a human reads. Amazon EventBridge receives notifications when registry records are submitted for approval, so the queue can drive a ticket or a channel message rather than depending on someone opening the console.
• Decide the authorization mode deliberately. JWT from your corporate identity provider ties registry access to your existing identity population; IAM ties it to your existing role model. Choosing JWT because it is convenient for a demo means an access decision has quietly moved out of IAM.

One more, specific to the MCP endpoint: the registry describes your internal tooling estate, and it answers natural-language queries about it. Read access to the registry is read access to a map of what your organisation has built. Scope it like an inventory, not like documentation.

Cost considerations

Consumption-based, with a free tier generous enough that most estates will not pay for records at all.

Put a number on it: a registry holding 20,000 records — a very large estate — is 15,000 chargeable records, which comes to $6.00 a month. Search is priced five times higher than List and Get per call, which is a hint about intended usage: browse and fetch cheaply, search when you actually need semantic matching. An agent that runs a semantic search on every task rather than caching a fetched catalogue will notice the difference before the finance team does.

One clause to read if you are a partner or an ISV: customers that resell AWS Agent Registry to their End Users or customers are not eligible for Free Tier and will be charged from their first record, Search API invocation or List and Get API invocation.

Operational considerations

The operational risk here is not availability, it is the approval queue becoming a bottleneck and then a bypass. A registry whose pending queue is two weeks deep will be routed around — teams will pass endpoint URLs to each other directly, and the catalogue returns to being a parallel truth.

Two mitigations worth building in from the start. Give the queue an SLA and an owner per registry, which is easier if you split registries by team or stage rather than running one organisation-wide catalogue with one reviewer. And use the EventBridge notification to make the queue visible where the team already works.

Note also that auto-detection produces drafts continuously as teams deploy. That is the feature working, but it means the queue has a background rate that is a function of deployment activity rather than of publishing effort — size the reviewer role accordingly.

Tradeoffs

Implementation guidance

The order that gets you a useful registry rather than an empty one:

1. Turn on organisation-wide auto-detection first, before publishing anything. The resulting draft queue is an inventory of what is already running on AgentCore, which is the most useful artefact of the whole exercise and is available on day one.
2. Write the approval criteria before approving anything. What permissions may a registered tool hold, what identity must it authenticate with, what is required in the description. Three bullet points beats an unwritten standard applied inconsistently.
3. Split the personas in IAM. Publisher, curator, administrator, consumer — the docs define these, and the separation between publisher and curator is the one that matters.
4. Subscribe the EventBridge notification to whatever the reviewing team actually watches.
5. Provision registries as code. The registry is a policy boundary with an authorization mode and approval settings; those belong in CloudFormation, Terraform or CDK alongside the rest of the platform, not in console state.

Then connect a consumer to the MCP endpoint and confirm the negative case: that a draft or rejected record does not appear in search results for a consumer identity. That is the property the whole control rests on, and it takes one test to establish.

Best practices

• Treat the approved list as an allowlist and review it periodically. Approval is a point-in-time judgement about a resource that keeps changing behind its record.
• Deprecate rather than delete. Deprecation removes discoverability while keeping the record and its history, which is what you want when working out later what an agent could have reached.
• Do not let the registry imply completeness it does not have. Auto-detection covers AgentCore Runtime and Gateway only. Anything else has to be published deliberately, and the gap should be stated wherever the registry is presented as an inventory.
• Put the registry's own access in the same review as other inventory data. It is a searchable description of your internal tooling.
• Cache catalogue fetches in agents rather than searching per task, both for latency and because Search is the more expensive of the two pricing dimensions.

Who should adopt this

Anyone already running agents or MCP servers on AgentCore at more than one team's scale should turn on auto-detection this week, whatever they decide about the catalogue afterwards — the inventory alone justifies it, and it costs nothing at typical volumes.

Organisations building an internal agent platform should treat this as the governance layer it is, and design the approval criteria and persona split before the first record is published. Retrofitting a review process onto a catalogue everyone already reads is harder than starting with one.

Teams with a single agent, or with agents running entirely outside AgentCore, get little from it today: without auto-detection the registry is a catalogue maintained by hand, which is the thing that historically decays.

Key takeaways

• Only approved records are discoverable, and agents are among the consumers — so the curation queue functions as an allowlist and the reviewer is doing security work.
• Organisation-wide auto-detection files what is already running as drafts, which fixes the failure mode that kills internal catalogues. It covers AgentCore Runtime and Gateway, and nothing else.
• The registry is itself an MCP endpoint, authorised by IAM credentials or JWT from your identity provider. Read access to it is a map of your internal tooling.
• Cost is unlikely to be the constraint — 5,000 records free, then $0.400 per 1,000; a 20,000-record estate is $6.00 a month. Search costs five times what List and Get do per call.
• GA in five Regions, and worth provisioning as code because a registry is a policy boundary, not just a container.

Official AWS references

• AWS Documentation — AWS Agent Registry: discover and manage agents, tools, and resources
• AWS What's New — AWS Agent Registry for centralized agent discovery and governance is now generally available
• AWS Machine Learning Blog — Manage agents, tools and skills at scale with AWS Agent Registry
• AWS Pricing — Amazon Bedrock AgentCore, including AWS Agent Registry