AWS Agent Registry Is Now Generally Available for Governing AI Agents, Tools and Skills

September 6, 2026

Amazon Web Services has made AWS Agent Registry generally available, giving organizations a centralized catalog for artificial intelligence agents, tools, skills, MCP servers and custom resources. The service is designed to solve a growing enterprise problem: teams are creating agents faster than security and platform groups can discover, review and govern them.

As agentic AI moves from experiments into production, companies need to know what exists, who owns it, which version is approved and what systems it can access. AWS Agent Registry aims to become that system of record.

AWS Agent Registry: key facts

• Generally available as a private, governed catalog for agentic resources.

• Supports agents, tools, skills, MCP servers and custom resources.

• Includes semantic and keyword search, approval workflows and access controls.

• Integrates with Amazon Bedrock AgentCore, Amazon Quick and Kiro IDE.

• Available initially in five AWS regions with consumption-based pricing.

Why enterprises need an AI agent registry

When individual teams build agents independently, organizations often create duplicate tools and inconsistent security practices. Some agents may continue running after their owners change roles, while others use outdated models or overly broad permissions.

A central registry provides an inventory and a discovery layer. Developers can find an approved capability instead of rebuilding it, and administrators can track ownership, lifecycle status and access. This becomes increasingly important when autonomous agents call one another to complete multi-step work.

Discovery through semantic search

AWS Agent Registry combines keyword and semantic search so users can find resources by meaning rather than exact names. A developer looking for a document-classification tool, for example, could discover an existing approved service even if its title uses different terminology.

The registry can be accessed through the AWS console, command-line tools and software development kits. It is also exposed as an MCP server, allowing compatible development environments and agents to query the catalog directly.

Governance, approval and audit trails

The service separates publishing from curation. Builders can register resources, while designated reviewers approve or reject them according to business, security and compliance requirements. AWS CloudTrail integration helps organizations maintain an audit history.

Records can include ownership, lifecycle information and access policies. Infrastructure teams can provision registries with AWS CloudFormation, Terraform or the AWS Cloud Development Kit. Tags support organization, access control and cost allocation.

Automatic discovery reduces shadow agents

Unregistered agents are a major governance blind spot. AWS says the registry can automatically detect resources running on AgentCore Runtime and AgentCore Gateway across an organization, reducing reliance on manual reporting.

The company plans broader detection across EC2, EKS and ECS, plus future federation with non-AWS environments. The goal is a more complete map of agentic resources wherever teams deploy them.

Integration with workplace and developer tools

A registry is useful only if people can access it in their normal workflows. AWS integrates discovery with Amazon Bedrock AgentCore, Amazon Quick and Kiro IDE. Amazon Quick users can also find custom connectors from the registry.

Planned features include richer security and compliance assessments, versioning, dependency graphs, observability metrics and policy controls that connect approval decisions with runtime behavior.

Availability and pricing

AWS Agent Registry is available in US East in Northern Virginia, US West in Oregon, Europe in Ireland, Asia Pacific in Tokyo and Asia Pacific in Sydney. AWS uses consumption-based pricing and includes a Free Tier.

Organizations should check regional and data-residency requirements before selecting a deployment. Multi-account enterprises should also define who owns the central registry and how local teams can publish resources without weakening review standards.

What companies should do first

Before creating a registry, companies should define a minimum record: owner, purpose, model, tools, permissions, data classification, review date and retirement process. They should also decide which actions require human approval and which telemetry must be retained.

The registry should complement—not replace—runtime security. Identity controls, least-privilege permissions, network isolation, monitoring and incident response remain necessary after an agent is approved.

The bottom line

AWS Agent Registry signals that agent governance is becoming a core cloud category. Building an agent is no longer the hardest enterprise problem; finding, trusting and managing hundreds of agents may be. A reliable inventory with approval and audit controls can help organizations scale without losing visibility.

Source: AWS Agent Registry announcementA registry is not the same as runtime control

Cataloging an agent does not guarantee that it behaves safely. The registry may say which tools are approved, but identity and network systems must enforce those limits during execution. Organizations need a link between the documented policy and the credentials issued to each run.

This distinction prevents a common governance failure: an agent is reviewed once and later gains new tools or data access without a fresh assessment. Version changes should automatically trigger the appropriate approval process.

Building useful metadata

A registry record should describe more than a name and owner. Useful fields include business purpose, model version, tools, data classification, geographic restrictions, evaluation results, cost center and expiration date. Dependencies help reviewers understand what will break when a service changes.

Too many mandatory fields can discourage adoption, so organizations should begin with a small required schema and automate collection wherever possible.

Managing the AI agent lifecycle

Agents need development, testing, approved and retired states. Production access should be limited to reviewed versions, while experimental resources remain isolated. Owners should periodically confirm that an agent is still needed and that its permissions remain appropriate.

Retirement is especially important for credentials and integrations. Removing a registry entry should be paired with revoking access and preserving audit evidence required by policy.

Cross-account and multi-cloud governance

Large AWS customers often operate many accounts across business units. Resource Access Manager can support shared registries, but companies must decide whether governance is centralized, federated or hybrid. Local teams need enough autonomy to innovate without creating invisible production agents.

Multi-cloud environments add another challenge. Planned federation could improve visibility, although enterprises should avoid making one catalog a new point of lock-in. Exportable metadata and open discovery standards will matter.

Security questions for MCP servers and tools

MCP servers expand what agents can do, which also expands the attack surface. Registry reviews should examine authentication, input validation, data exposure and whether a tool can perform destructive actions. A trusted description is not a substitute for technical testing.

Organizations should record the permissions each tool requests and require explicit approval for sensitive capabilities. Runtime logs should connect a tool invocation with the agent, user and task that initiated it.

Measuring whether the registry works

Success metrics include the percentage of active agents inventoried, time required to find an approved capability, duplicate-development reduction and review turnaround. Security teams can track unowned resources, expired approvals and policy violations.

A registry that developers avoid will become incomplete. Integration with IDEs and automated discovery can make compliance part of normal work instead of a separate administrative burden.

What to watch next

AWS plans richer assessments, observability and dependency analysis. Customers should watch how these features connect with non-AWS systems and whether approval decisions can reliably constrain runtime behavior. The strongest platform will unite discovery, evidence and enforcement while remaining usable for builders.