AWS Agent Registry: The New Way to Govern Enterprise AI Agents

Why AI Agent Governance Is Becoming a Platform Problem

Traditional software has a well-understood management layer: code moves through a repository, a CI/CD pipeline, a deployment, and monitoring. Agentic software adds a much wider set of things to keep track of — agents, tools, MCP servers, skills, models, data access, permissions, and a runtime, on top of everything traditional software already needed.

In practice, this shows up as a predictable pattern: one team builds an MCP server to expose an internal API, another team unknowingly builds something nearly identical weeks later, and a third team's agent has access to a tool nobody remembers approving. None of this is a failure of any individual team — it's what happens when a fast-moving category of software has no shared catalog, no ownership model, and no approval step between "someone built this" and "this is safe for other teams to use." Platform and security teams end up needing a basic answer: what agents, tools and MCP servers actually exist right now, who owns each one, and which are approved for reuse? Without a registry, that answer usually lives in nobody's head.

What Is AWS Agent Registry?

According to AWS, AWS Agent Registry is a fully managed discovery service that provides a centralized catalog for organizing, curating, and discovering resources across your organization. Teams publish MCP servers, agents, agent skills, and custom resources into a searchable registry, access is controlled through an approval workflow, and both human users and AI agents can discover the right tool or agent through hybrid search, catalog browsing, or a native MCP endpoint.

The core idea is a simple pipeline: registry → catalog → approval → discovery → reuse. A resource is published into a registry, it's reviewed against that registry's approval settings, and only once approved does it become part of the discoverable catalog other teams can search, browse and reuse — rather than every team rebuilding the same capability because they had no way to find it.

Discovery itself supports two complementary approaches: semantic search, for natural-language queries like "find me a tool that looks up customer order status," and keyword search, for exact name or identifier lookups — plus a dedicated catalog-browsing experience with filters, for teams that prefer to explore what's available rather than search for something specific.

How AWS Agent Registry Works

AWS Agent Registry is organized around two resources. A registry is the catalog itself — it has a name, description, an authorization configuration (IAM or JWT from a corporate identity provider), and its own approval settings. Organizations can create one org-wide registry, or split registries by resource type, environment (production, QA, development), or team — whichever boundary matches how the organization actually operates. A registry record represents one published resource inside a registry, capturing the metadata that describes what it is, what it does, and how it can be found.

The typical workflow follows four steps: an administrator creates a registry and configures its authorization and approval settings; a publisher creates a record describing their MCP server, agent, or tool and submits it for approval; a curator reviews pending records and approves, rejects, or later deprecates them; and consumers — human developers or AI agents — search, browse, or connect to the registry's MCP endpoint to find what they need. Each record moves through a defined lifecycle: draft → pending approval → approved (or rejected) → deprecated.

That lifecycle is also why AWS describes the registry as having two logical planes: a Governance Plane, which holds every record regardless of its approval state, and a Discovery Plane, which surfaces only the approved, curated subset that consumers actually see when they search or browse. Separating the two is what makes "this exists somewhere" and "this is safe to use" two distinct, deliberate states instead of the same thing.

What Can Be Registered?

AWS Agent Registry supports four record types, and validates the first two against their respective protocol schemas rather than accepting arbitrary metadata:

• Agents. Autonomous or semi-autonomous AI agents, registered and discoverable as Agent-to-Agent (A2A) resources — including agents hosted on Amazon Bedrock AgentCore Runtime.
• MCP servers. Model Context Protocol servers that expose tools, resources, or prompts. The registry validates these against the MCP protocol schema, and can even sync metadata directly from a live external MCP or A2A server rather than requiring it to be entered by hand.
• Skills. Reusable, packaged capabilities that an agent can invoke — the kind of narrow, well-defined function that's genuinely worth sharing across teams instead of reimplementing.
• Custom resources. Anything else an organization wants cataloged, described with custom JSON metadata rather than a fixed protocol schema.

It's worth being precise about MCP here: the Model Context Protocol is an open, AWS-independent standard for connecting AI applications to external tools, data and prompts. AWS Agent Registry doesn't reinvent MCP — it provides a governed discovery layer around MCP servers your teams already build, whether those servers run on AWS or elsewhere.

Governance: The Important Part

Discovery alone isn't the hard problem — a shared spreadsheet can list what exists. The harder problem is making sure that "something exists" and "this is an approved capability developers can safely use" aren't treated as the same fact. That gap is exactly what the approval workflow, ownership metadata, and lifecycle states are designed to close.

In practice, governance here means: an approval step between publishing and discoverability, a defined owner for every record, the ability to deprecate a resource when it's no longer maintained, tags for organizing records by cost center or access boundary, and — critically for security and compliance reviews — an audit trail. AWS Agent Registry logs registry API calls through AWS CloudTrail, so who created, approved, or modified a record is a matter of record, not institutional memory.

AWS Organizations and Auto-Detection

One of the more consequential capabilities AWS shipped alongside general availability addresses what's often called "Shadow AI" — agents and MCP servers that get deployed without ever going through a central review. An administrator enables endpoint detection once at the AWS Organizations level, and from that point on, AWS Agent Registry automatically detects agents and MCP servers running on Amazon Bedrock AgentCore Runtime and AgentCore Gateway across every member account in the organization.

Detected resources don't appear as approved, discoverable entries — they flow in as draft records, waiting for a curator to review, approve, or reject them. That distinction matters: auto-detection gives platform and security teams visibility into what's actually running, without silently promoting anything to "approved for reuse" on its own. It's also worth being precise about scope — this covers AgentCore Runtime and Gateway workloads across accounts in the same organization, not AI workloads on other clouds, on-premises, or outside AgentCore entirely. For a mixed environment, auto-detection covers the AWS/AgentCore portion, and manual or API-driven registration still covers the rest.

AWS Agent Registry and MCP

Every registry instance is also exposed as its own remote MCP endpoint, which means any MCP-compatible client can query it directly using the Model Context Protocol rather than a bespoke API integration. AWS specifically confirms that MCP-compatible development environments — including Kiro and Claude Code — can connect to a registry natively, letting a developer run a natural-language search like "find me an MCP server for problem tickets" from inside their editor and get back approved, governed results.

Authorization for the MCP endpoint follows the same model as the rest of the registry — IAM credentials or JWTs from a corporate identity provider — with OAuth setup handled through Dynamic Client Registration so a developer's IDE doesn't need pre-provisioned credentials just to search. Discovering an approved tool becomes part of a developer's normal workflow instead of a separate lookup in a different system.

AWS Agent Registry and Amazon Quick

AWS Agent Registry also connects to Amazon Quick, AWS's business-user-facing AI surface. Once a Quick administrator connects their tenant to one or more Agent Registries, approved agents and MCP servers that expose MCP connectors appear directly on Quick's Integrations page — and from there, business users can reach those same governed capabilities through Quick Chat, Automations, Flows, and Deep Research.

The significance is less about Quick specifically and more about what it demonstrates: the same governed catalog — same approval workflow, same owner and audit trail — can serve a developer querying an MCP endpoint and a business user in a no-code flow alike. Worth noting: this requires explicit configuration by a Quick administrator, not something every organization gets automatically the moment a registry exists.

Agent Registry and Cloud Security

AWS Agent Registry is a genuinely useful piece of an enterprise AI security posture, but it's worth being precise about which piece. What it provides directly: an approval gate between "published" and "discoverable," ownership and audit trails through CloudTrail, lifecycle management (including deprecation), and reduced Shadow AI risk through org-wide auto-detection. What it does not provide on its own is complete AI security.

Enterprise AI security still depends on identity and IAM design, network controls, secrets management, data security, runtime security for the agents and MCP servers themselves, and the observability that shows what agents actually do in production. AWS Agent Registry can enforce that an approval happened; it doesn't replace the identity, network, and data controls that determine whether the underlying resource is actually safe to approve. Our Cloud Security practice focuses specifically on that surrounding layer — IAM, network segmentation, secrets management, and audit logging — that a registry depends on rather than replaces.

Agent Registry and Platform Engineering

For a platform team, AWS Agent Registry is a natural building block inside an internal developer platform rather than a replacement for one. The registry can sit behind a self-service layer: a developer requests an AI capability, the platform routes them to an approved agent, MCP server, skill or tool already in the registry, and they consume it securely — without filing a ticket or rebuilding something that already exists three teams over.

The platform team's job doesn't disappear here — if anything, it becomes more explicit. Someone still needs to define what "approved" means for this organization, decide who holds curator and administrator roles, automate the infrastructure that publishes and hosts these resources, wire in the observability that shows how registered agents actually behave in production, and keep the registry's lifecycle state accurate as tools are deprecated or replaced. That's precisely the kind of standards-and-automation work our Platform Engineering practice is built around, and it pairs naturally with the automation and repeatability our Infrastructure as Code & GitOps and DevOps Solutions work already brings to the rest of an organization's delivery pipeline.

AWS Agent Registry vs. Traditional Software Catalogs

Teams that already run an internal service catalog or API registry might reasonably ask how this is different. The honest answer is that AWS Agent Registry isn't trying to replace a general software catalog — it's purpose-built for a category of resource that traditional catalogs weren't designed around.

This isn't a case of one approach being objectively better — a mature software catalog still matters for the services and APIs it already tracks well. AWS Agent Registry is designed specifically for an AI/agent ecosystem, where the resource types, discovery pattern (agents searching for tools, not just humans), and approval requirements are different enough to warrant a purpose-built layer.

What AWS Agent Registry Does Not Solve

To be technically credible about this service, it's worth being explicit about what stays entirely outside its scope. AWS Agent Registry does not replace:

• IAM design and identity federation — the registry has its own authorization model, but the identity and permission strategy for everything it points to is still yours to design.
• Secrets management for the credentials an agent or MCP server actually uses at runtime.
• Network security — VPC design, PrivateLink, and segmentation around where agents and MCP servers actually run.
• Data governance for what an agent or tool is allowed to read, write, or expose.
• Model governance — evaluating a model's behavior, bias, or reliability is a separate discipline from cataloging the agent that uses it.
• Runtime monitoring and incident response once an approved agent is actually running in production.
• Cost management for the compute and inference the registered resources consume.
• Human approval for sensitive workflows that need judgment a registry's approval workflow can route to, but can't substitute for.
• Compliance processes, agent evaluation, and testing — the registry can require that these happened before approval; it doesn't perform them.

None of this is a criticism — it's a fairly deliberate scope. A discovery and governance layer that tried to also be an IAM system, a secrets manager, and a testing framework would do all of them poorly. AWS Agent Registry is best understood as one well-defined piece of a much larger enterprise AI platform.

Practical Enterprise Architecture

Put together, a reasonably mature setup looks like this: developers and business users reach an internal developer platform, which sits in front of the Agent Registry and the organization's existing security controls (IAM, network policy, secrets management) side by side. The registry catalogs agents, MCP servers, skills, and custom resources, each ultimately hosted through Bedrock AgentCore or an equivalent runtime and backed by real data, APIs and enterprise systems. Wrapping the entire path — not just sitting at the end of it — are observability, audit logging, and security monitoring, watching not just whether a resource was approved, but how it actually behaves once teams are using it. The registry is one layer in that stack: it answers "does this exist, and is it approved," while the layers around it still have to answer "is it secure" and "is it observable."

How Enterprises Should Approach Agent Governance

For an organization starting from scratch — most are, given how recent this category is — a phased approach tends to work better than trying to govern everything on day one:

1. Inventory. Find out what agents, MCP servers and tools already exist, including the ones nobody remembers building. Auto-detection helps considerably here.
2. Ownership. Assign a clear owner to every discovered resource before doing anything else with it.
3. Classification. Decide which resources are safe candidates for reuse, which need rework first, and which should be retired outright.
4. Approval. Define what "approved" actually requires at your organization — security review, testing, documentation — and configure the registry's approval workflow to match.
5. Discovery. Roll out search and browsing access to the teams that need it, once there's something genuinely trustworthy to discover.
6. Access control. Tie registry authorization to your existing identity provider rather than a separate credential system.
7. Monitoring. Extend existing observability practices to cover what registered agents and tools do at runtime, not just whether they were approved.
8. Lifecycle management. Treat deprecation as a normal, ongoing part of the process — an unmaintained approved record is its own kind of risk.

How Isha Technologies Can Help

Building an enterprise AI platform requires more than deploying agents. It requires the cloud infrastructure, security, governance, automation, and observability around them.

Isha Technologies is a Cloud & DevOps Solutions Provider. Depending on where an organization actually is in its agent governance journey, that can mean designing the AI-assisted operational tooling in AI-Powered DevOps & AIOps, hardening the identity, network and audit layer through Cloud Security, building the self-service platform and golden paths in Platform Engineering, automating the infrastructure that hosts these resources with Infrastructure as Code & GitOps, extending delivery practices through DevOps Solutions, instrumenting what's actually running with Observability & Monitoring, or designing the underlying environment itself with Cloud Solutions.