What Is an Agent Registry?

Overview

An agent registry is the record of the agents an enterprise has reviewed and decided to trust: identity, owner, purpose, permissions, reachable tools, lifecycle state. Nobody argues with that definition, and on its own it describes a table. What makes a registry different from a spreadsheet is the list of other systems that are required to read it before they let an agent do anything.

By mid-2026 the average enterprise has several of these tables and no agreement between them. Microsoft's identity layer keeps agent identities in Entra, and Microsoft moved the discovery surface elsewhere: the Entra what's-new page, dated 1 May 2026, says "agent registry experiences are converging under Microsoft Agent 365." The Model Context Protocol has a public registry of servers, not of the agents that call them. A2A publishes capability documents at a well-known URL and treats registries as one discovery option among three. Meanwhile your security tooling has its own list of OAuth applications that users connected without asking anyone.

Breadth is covered separately in what is an agent inventory, the distinction between the two records in agent registry vs. agent inventory, and the build sequence in building an enterprise agent registry. What follows is narrower: what a single entry has to contain, which systems are supposed to consult it, and where real registries break.

The Control Plane

The term is borrowed from infrastructure on purpose. A control plane is not where work happens. It is where decisions about the work are made, and the interesting property is that the data plane cannot proceed without it.

Agent protocols have started to specify the data-plane half of that contract, which is what makes the registry half suddenly concrete. In the Model Context Protocol's 2026-07-28 specification, a protected MCP server "acts as an OAuth 2.1 resource server." It MUST implement OAuth 2.0 Protected Resource Metadata (RFC 9728), it MUST validate "that access tokens were issued specifically for them as the intended audience," and it MUST NOT "accept or transit any other tokens." Insufficient scope gets a 403 carrying the scopes the operation needs.

Read those requirements as a set of questions the server has to answer at call time. Which authorization server do I trust. Is this token addressed to me. Is this caller allowed the scope it is asking for. The first two are answerable from static configuration. The third is not, and the registry is where that answer lives.

Documentation describes the world as someone last understood it. A control plane constrains what happens next. The test is unglamorous: delete an agent's entry and see whether anything stops.

Anatomy of an Entry

Registration carries obligations, and an agent that cannot satisfy them does not belong in the record. A name alone tells a reviewer nothing.

Table 1 — The seven fields an entry needs, and the runtime check each one feeds.

Identity deserves the most attention, because it is the field that everything else hangs off, and it is the one teams get wrong first. Two workable conventions already exist. SPIFFE defines a workload identifier as an RFC 3986 URI of the form spiffe://trust-domain/path, where the trust domain "MUST NOT be empty" and the path "allows for the unique identification of a given workload." The MCP Registry takes the other route, reverse-DNS names such as io.github.user/server-name, tied to a namespace whose owner has been verified through GitHub, DNS or an HTTP challenge. Both give you a name that a second system can verify. A display name typed into a form gives you neither.

Take a vendor-onboarding agent approved to draft and route new-supplier packets. Its entry names a procurement-platform owner, scopes it to read approved vendor records and to draft but never submit onboarding documents, points at a vault reference rather than an inline key, and sets a review date six months out. Drop the identity field and the audit trail says a request arrived. Drop the review date and the six-month limit was decoration.

What Shipping Registries Record

It helps to be specific about what the available systems are registries of, because the word is doing four jobs at once.

Table 2 — Five records that all get called registries, and the one job each refuses.

The MCP Registry is explicit that its metadata is "deliberately unopinionated" and that security scanning is delegated to package registries and downstream aggregators. Inclusion is not endorsement, and treating a public catalog as an allowlist is the most common misreading of it.

A2A is the useful counterexample, because it inverts the direction. An agent publishes its own card at https://{domain}/.well-known/agent-card.json, following RFC 8615. The spec lists three discovery mechanisms and describes the registry option plainly: "A2A Servers publish their Agent Cards to the registry" and "Client agents query the registry's API, and search by criteria such as 'specific skills'." Self-published capability claims are a discovery aid. They are not a review record, and a card is exactly as trustworthy as the agent serving it.

Microsoft's tenant-scoped registry is the closest thing to the enterprise sense of the word, and its own field list is worth reading. Agents are grouped as Microsoft, external partner-built, published by your org, or shared by creator. The export carries name, status, channel, date created, last modified, publisher, publisher type, version, owner, description, platform and instructions, with the documentation noting "over 30 different items" available per agent. There is a preview Graph endpoint, GET /copilot/admin/catalog/packages, behind the CopilotPackages.Read.All scope. A risk column aggregates signals from Purview, Entra and Defender, and the docs warn those counts "might be up to an hour behind what the security portals show."

Enforcement

A registry that only records is a ledger. The difference shows up in what happens on a call.

Figure 1 — Four outcomes, one lookup. The registry supplies the answer; the gateway is what makes it binding.

The wire format for two of those branches is already specified. MCP servers SHOULD answer an unauthorized request with a challenge naming where to find their metadata and which scopes the operation wants:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

Insufficient scope on a token that is otherwise valid gets a 403 with error="insufficient_scope" and the scopes the current operation requires. The spec also tells servers to send every scope needed for the operation in one challenge, because "challenging incrementally... forces multiple authorization round-trips for a single operation."

That is the enforcement point, aact:enforcement-point/gateway in the taxonomy's terms. The registry's job is to be the thing that decided, in advance and in writing, which agent may hold which scope, so that the gateway's answer is a lookup instead of a judgment call. Where the two disagree, the gateway wins and the registry is wrong, which is a useful way to find stale entries.

Review Dates and Lifecycle

A review date is only real if a job reads it. The mechanics are not exotic. Entra access reviews can be scheduled "at set frequencies such as weekly, monthly, quarterly or annually," with reviewers notified at the start of each cycle, which is the same machinery enterprises already point at group membership and privileged roles.

The states themselves are worth naming, because "registered" is not one state.

Figure 2 — Five states and one that most registries lack. Reduced is the one that buys time without either lying or breaking the agent outright.

Ownership decay is the failure that arrives on its own. Microsoft's documentation is blunt about the mechanism: shared agents "can become ownerless when you delete the user who created them from the organization," and the admin center surfaces a live count, updated when a user is hard-deleted, with a one-click filter to isolate them. Entra's governance side added lifecycle workflow templates that reassign sponsorship when an agent's sponsor changes role or leaves, described as a way "to prevent orphaned agents." An agent whose owner left the company is not a documentation problem. It is a live credential with nobody accountable for it.

Deletion needs the same care as admission. Entra documents a "cascade cleanup process and soft-delete functionality for agent identities," which matters because the pieces of an agent outlive the agent: credentials, vault entries, group memberships, log records. NIST's AI RMF puts the retention question in GOVERN 1.7, recommending policies that "delineate where and for how long decommissioned systems, models and related artifacts are stored." Offboarding in depth is its own subject.

What Regulators Require

Registration is already a legal act in two jurisdictions, and both are more specific than most internal processes.

Under Article 49 of the EU AI Act, providers of high-risk systems listed in Annex III must "register themselves and their system in the EU database" before the system goes on the market or into service. Article 49(2) extends that to providers who have concluded their system is not high-risk under Article 6(3): the exemption still has to be registered. Article 49(3) requires public-authority deployers to "register themselves, select the system and register its use." Article 71 makes the Commission the controller of that database, and says information registered under Article 49 "shall be accessible and publicly available in a user-friendly manner." Law-enforcement, migration and border systems register into a secure non-public section instead.

The US federal version is worth studying because it is running at scale and published. OMB Memorandum M-25-21 requires agencies to inventory AI use cases; the 2025 consolidation covers 56 agencies, 3,611 reported use cases and 445 designated high-impact. One rule in it is the kind of thing internal registries forget: retired use cases must be reported as retired immediately following their final operational year, after which they can drop out of later submissions. Retirement is an entry state, not a deletion.

NIST's framing sits underneath both. GOVERN 1.6 of the AI RMF describes an inventory as "an organized database of artifacts relating to an AI system or model" and suggests policies defining what gets recorded, naming "documentation, links to source code, incident response plans, data dictionaries, AI actor contact information." Its coverage guidance is a reasonable default for an agent registry too: inventory everything, or at minimum everything high risk.

How Registries Fail

Four failures account for most of what we would expect to find in an audit, and they look different from each other.

The list nobody reads. Entries are complete and access does not depend on them. The tell is that revoking an entry changes nothing, and the fix is not a better schema.

Name drift. A redeploy produces a new identifier, so one agent accumulates three entries and none of them is current. Reverse-DNS names bound to a verified namespace, or SPIFFE-style identifiers bound to a trust domain, are the cheap prevention. The symptom to watch for is an audit query that returns fewer calls than you know happened.

Ownerless entries. The owner column is populated and the person left. This one is measurable rather than debatable: the CSA and Oasis survey of 383 practitioners, fielded in August and September 2025, found 51% reporting no clear ownership or accountability for non-human identities, and 78% without documented policies for creating or removing AI identities.

Post-approval scope creep. The agent's token is broader than its entry. If the agent asked for every scope during its first authorization, nobody ever sees a 403, and the step-up flow that would have made the widening visible never fires. Compare granted scopes against registered scopes on a schedule; the diff is the finding.

OWASP's Top 10 for Agentic Applications, published 9 December 2025, has categories for the two ends of this: ASI03 Identity and Privilege Abuse, and ASI10 Rogue Agents. A registry is not a control for either on its own. It is the thing that makes both detectable, because "rogue" is only meaningful relative to a record of what was sanctioned.

Where Fabriq Fits

Agentic Fabriq holds credentials per user in a vault and attaches them server-side at the moment of the call, so the agent never handles the secret. Every call carries two identities, the agent and the acting user, into the audit record, and an agent's effective tool list is the intersection of the user's scopes and the agent's own. That intersection is the registry-shaped part: a registered scope set that narrows what a token can reach, enforced at the call rather than described in a document.

What it does not do is reach into the provider on your behalf. Clearing a vault copy is not the same act as invalidating a grant upstream, so that call stays yours to make.

Frequently Asked Questions

What is an agent registry? The record of agents an organization has reviewed and authorized, holding identity, owner, purpose, scopes, credentials, audit binding and lifecycle state. The working definition we would use is narrower than the dictionary one: a registry is a record that at least one enforcement point consults before granting access.

What is the difference between an agent registry and an agent inventory? An inventory records what exists, including what nobody approved. A registry records what has been reviewed. The inventory is populated by discovery, the registry by a review process, and the gap between the two counts is the honest measure of how much of your estate is ungoverned. Longer answer in agent registry vs. agent inventory.

Is the MCP Registry an agent registry? No. It is a metadata catalog of publicly reachable MCP servers, deliberately unopinionated about quality, and it "does not support private servers." It tells you a server exists and who owns the namespace. It says nothing about which of your agents may call it.

Does an Agent Card count as a registry entry? No. A card is a self-published description served from the agent's own domain. Useful for discovery, worthless as a review record, since the agent asserting its capabilities is the same party you are trying to verify.

Do we need a registry for compliance? For some systems it is not optional. Article 49 of the EU AI Act requires registration in the EU database for Annex III high-risk systems, and for systems the provider has decided are not high-risk under Article 6(3). US federal agencies inventory use cases under M-25-21. Outside those regimes, NIST's AI RMF treats an inventory as a governance baseline rather than a rule.

What fields should an entry have? The seven in Table 1. If you want a shorter version: a verifiable identifier, a human who answers for it, a scope set, and a date the approval expires. Everything else is elaboration on those four.

Who owns the registry? Whoever operates the enforcement point, in our view. A registry owned by a team that cannot change what the gateway does will drift, because it has no way to notice when it is wrong.

How often should entries be reviewed? Tie the interval to blast radius rather than a calendar habit. Quarterly for anything that writes to a system of record, annually for read-only, and immediately on a scope change, which should route back through review rather than inherit the wider grant silently.

How is this different from a CMDB? Different questions, overlapping fields, and the comparison has its own post. The short version is that a CMDB describes configuration; a registry authorizes behavior.

Conclusion

A registry is the place an agent stops being an anonymous process holding credentials. That happens on the day something refuses a call because the entry is missing, not on the day the table is populated.

So build backwards. Start at the hop every agent call already passes through, make it require an identifier that a second system can verify, and let the record grow into whatever that hop needs in order to decide. Add the review date early, because it is the field that fails quietly. Watch the granted-versus-registered scope diff, because that is where approved agents drift.

Sources

All URLs read 2026-09-29.

• Agent Access Control Taxonomy — the identity-model term for an agent identity that is registered and revocable on its own, and the enforcement-point term for the hop a registry entry has to be read at.
• The MCP Registry — "deliberately unopinionated" metadata, reverse-DNS namespaces verified through GitHub, DNS or HTTP challenge, no private servers, scanning delegated downstream.
• MCP specification 2026-07-28: Authorization — the OAuth 2.1 resource server role, RFC 9728 metadata, audience validation, the 401 challenge and insufficient_scope 403.
• A2A: Agent Discovery — the /.well-known/agent-card.json path and the three discovery mechanisms, including curated registries.
• What's new in Microsoft Entra Agent ID — general availability, registry convergence under Agent 365, sponsor lifecycle workflows "to prevent orphaned agents", cascade cleanup and soft delete.
• What is Microsoft Entra Agent ID? — agent identity blueprints, OAuth 2.0 / MCP / A2A support, third-party agents via sidecar or workload identity federation.
• Agent Registry in the Microsoft 365 admin center — the four agent types, the unmanaged and ownerless counters, the export field list, the Graph preview endpoint and the risk-signal delay.
• What are access reviews? Microsoft Entra ID Governance — recurring review frequencies and reviewer notification.
• SPIFFE-ID standard — the spiffe://trust-domain/path URI form and the trust-domain constraints.
• NIST AI RMF Playbook, GOVERN — GOVERN 1.6 on inventories and the attributes to record, GOVERN 1.7 on decommissioned artifacts.
• EU AI Act Article 49: Registration — provider and deployer registration duties, including systems judged not high-risk under Article 6(3).
• EU AI Act Article 71: EU database for high-risk AI systems — the Commission as controller and the public-availability requirement.
• 2025 Federal Agency AI Use Case Inventory — M-25-21 as the governing memo, 56 agencies, 3,611 use cases, 445 high-impact, and the reporting rule for retired use cases.
• OWASP Top 10 for Agentic Applications — the ASI01 to ASI10 categories, published 9 December 2025.
• The State of Non-Human Identity and AI Security, CSA and Oasis Security — 383 responses fielded August and September 2025; ownership and policy gaps.