AI agent registries: built for discovery, not for trust

What is an AI agent registry?

An AI agent registry stores records about agents and serves them on request. A record typically includes an identifier or name, some description of the agent, one or more endpoints, and cryptographic material that lets a caller authenticate the agent or its publisher. Registries differ in who can write to them, what they check before accepting a record, and what their answers are supposed to mean.

Registries are not new. DNS is a registry of names; certificate transparency logs are registries of certificates; package registries such as npm and PyPI are registries of code. Agent registries borrow from all three, and the choices they inherit, especially about who is trusted, carry over too.

What does a registry actually do: discovery, naming, resolution?

Three functions are often bundled together under the word registry. It helps to pull them apart, because a system can be good at one and deliberately absent from another.

• Discovery: finding agents you did not already know about, usually by capability, category or search. This is the function a marketplace or a directory serves.
• Naming: assigning an identifier that is unique and stable, and deciding who may claim which names. Human-readable names raise disputes and squatting; opaque identifiers avoid them but need another route to be found.
• Resolution: going from a known identifier to the current record, including keys and endpoints. This is the function a verifier depends on, and the one where trust matters most.

Should a registry be the source of trust?

The core argument of this guide is that it should not. A registry that is the source of trust can change what any agent is, and every relying party inherits that change without being able to detect it. A registry compromise, an insider, a legal order or a plain bug then becomes an identity failure for everyone downstream. The more successful such a registry is, the more attractive a target it becomes.

The alternative is to treat the registry as a distribution mechanism. Records are signed by the parties they describe, using keys the registry never holds, and verifiers check those signatures themselves. The registry can still be useful, even essential, for finding and fetching records. What it cannot do is make a false record verify.

This is the same move certificate transparency made for web PKI and that package ecosystems are making with signed provenance: keep the convenient central service, but make its output checkable against something it does not control.

How does AgenID make its registry non-authoritative?

The AgenID registry at www.agenid.com is designed on the principle that it is a convenience, not an authority. Four properties make that concrete.

• Operators sign, the registry does not. An operator generates an Ed25519 key on its own machine or in the browser at /issue, signs a ManifestProof over its agent's manifest, and submits only public material. The registry holds no operator private keys and cannot sign on an operator's behalf.
• The registry checks before it stores, and so can you. Registration verifies the strict schema, the digest binding, the Ed25519 signature, the key's role and controller and the proof's validity window. A verifier re-runs the same checks on the resolution envelope and reaches its own conclusion.
• The key comes from two places. Two-path key discovery lets a verifier fetch the operator key from the registry at /v1/keys/<key-ulid> and from the operator's domain at https://<operator_domain>/.well-known/agenid/keys.json, and require that they agree. Where the operator publishes no copy, the verifier has one source, not two.
• Verification works offline. Once a verifier has the envelope, recomputing the digest, verifying the signature and computing the level needs no network access. A distributed envelope stays checkable even if the registry is unreachable.

What happens if the registry lies or goes down?

If the registry altered a manifest, the recomputed manifest digest would no longer match the proof, and the verifier would reject it with manifest_digest_mismatch. If it reported a level no valid assertion supports, a verifier that recomputes the level from the assertions would not reproduce it. If it served a different operator key, the comparison with the operator's own .well-known copy would disagree, provided the operator publishes one.

The residual risks are stated in AgenID's threat model rather than hidden. A verifier who trusts the registry's reported level without recomputing it is not protected. A compromised database credential could suppress or delete records, and could substitute key documents for agents whose operators publish no domain copy. None of these lets an attacker forge an operator's signature.

Availability failures are reported as such. A 503 registry_unavailable means an identity's status is unknown, not disproven, and an unknown identifier returns a neutral result rather than a warning. Absence of a record is not evidence of anything beyond the absence.

What design questions does every agent registry have to answer?

Whatever the architecture, a registry makes choices on the questions below. Asking them of any registry you are evaluating is a quick way to learn what its answers mean.

What registry approaches exist today?

Several approaches are in public discussion. The summary below describes each in its owner's or authors' own terms, with sources at the end of the page. It is a survey, not a ranking, and several of these can be combined. A 2025 academic survey, Evolution of AI Agent Registry Solutions, compares five of them across security, authentication, scalability and maintainability.

• Agent Name Service (ANS). An individual IETF Internet-Draft, draft-narajala-ans, proposed structured agent names resolved through a registry with X.509 certificates. Its successor, ANS v2, with authors from GoDaddy, OWASP and Cisco among others, anchors agent identity to a DNS domain, verifies domain control with ACME challenges and records lifecycle events in a transparency log. See the GoDaddy ANS comparison.
• MCP Registry. The MCP Registry is a centralized metadata repository for publicly accessible Model Context Protocol servers, currently in preview. It authenticates namespaces through GitHub, DNS or HTTP challenges and delegates security scanning to package registries and downstream aggregators. It describes servers rather than agents; see Model Context Protocol.
• A2A Agent Cards. The Agent2Agent specification has each agent publish a self-describing Agent Card, typically at /.well-known/agent-card.json on its own domain. Cards may be signed with JWS over RFC 8785 canonical JSON. This is decentralized discovery with no central registry required. See agent card and the A2A comparison.
• NANDA Index and AgentFacts. MIT's Project NANDA describes a lean index that resolves to AgentFacts, cryptographically verifiable metadata about an agent's capabilities and endpoints, with privacy-preserving discovery across organizations.
• Enterprise directories. Identity providers extend existing workforce directories to agents, which suits agents that act inside one organization's boundary. The arXiv survey above includes Microsoft Entra Agent ID as an example; see the Entra Agent ID comparison.
• AgenID. A resolver for operator-signed agent identities with a non-authoritative registry, as described above. Its primary function is resolution of a known identifier. It also publishes an opt-in agent directory listing only agents whose operators signed a listing consent with the agent's own key; a listing is not an endorsement and changes no level, and there is no capability search.

What can an agent registry not tell you?

A registry record tells you what was registered and, if it is built on signatures, who signed it. It cannot tell you that the declared content is true, that the operator is reputable, or that the agent behaves well at runtime. Those need other evidence, and the strength of that evidence should be labeled honestly. The reference deployment at agenid.com issues nothing above L1_REGISTERED today. L2_DOMAIN_VERIFIED and every level above it require a VerificationAssertion signed by a root authority key, and that key has not been created yet. L5 is reserved and is not issuable at all.

Which agent is acting is not the same question as what it is allowed to do. AgenID answers the first. Protocol v1.1.1 defines no signed authorization object, so the permission decision stays with the relying party and the operator. A v1.2 authorization layer exists only as a draft in development.

A registry also cannot bind a live request to a registered agent on its own. Resolving an identifier tells you about the identity; whether the request in front of you came from that agent is an authentication question, covered in agent-to-agent authentication.

How should you evaluate an AI agent registry?

A short checklist, useful whether you are choosing a registry to publish in, to resolve against, or to build.

• Can you verify a record without trusting the registry, and is the procedure written down?
• Who holds the signing keys for records: the subject, or the registry?
• Is there a second source for keys that the registry does not control?
• Are identifiers permanent, and can a name ever be reassigned?
• Does every level or badge say exactly what was checked, and does absence of verification render neutrally?
• Is there an independent conformance suite for implementations? AgenID's is at AgenID-protocol/conformance.
• Does the registry distinguish identity from permission, or does it imply that a listed agent may act?