AI Agent Registry: Live Inventory of Agents and Cards

Most organisations cannot answer a simple question about their AI agents: which ones exist, who owns each one, what it can call and what identity it runs as. A spreadsheet register written once for compliance goes stale within weeks, because agents are created in low-code builders, cloud AI platforms, developer laptops and vendor SaaS faster than anyone updates it. This guide explains how to build an AI agent registry that stays live: the data model, where records come from, how to ingest and verify A2A Agent Cards, how to tie each agent to a non-human identity, and how to make registration a precondition for getting credentials. It is written for identity, platform and AI governance teams. The policy wording for an AI register is in the AI Register and AI Inventory Template; this page is the engineering and operating method behind it.

Key takeaways

A registry is a control, not a list. If an unregistered agent can still obtain tokens, the registry records history rather than governing anything. Gate credential issuance on a registry record.
Agent Cards are self-description, not truth. The A2A Agent Card says what an agent claims to offer; the registry must add what the organisation knows: owner, identity, granted scopes, risk tier and status.
Verify signed cards where they exist. A2A 1.0 lets providers sign Agent Cards with JWS over a JCS-canonicalised payload. Store the verification result and the signing key ID with the record.
Pull from many sources, reconcile to one. Builder platforms, cloud AI services, identity providers, MCP gateways and well-known endpoints each see part of the estate. Reconciliation finds the agents nobody registered.
Measure ownership and drift. Agents without an owner, agents whose live card no longer matches the approved record, and agents with credentials but no registry entry are the numbers that matter.

What an agent registry is and how it differs from an AI register

NIST's AI Risk Management Framework asks for an inventory at GOVERN 1.6: "Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities." The NIST AI RMF Playbook suggests recording documentation, links to source code, incident response plans, data dictionaries and contacts for the responsible people, and naming who maintains the inventory. That is an AI system register. An agent registry is narrower and more operational: it tracks running software agents as actors, with identities, permissions and endpoints, and it is consulted by machines at runtime as well as by auditors.

Aspect	AI register (governance)	Agent registry (operational)
Unit of record	AI system or use case	Individual deployed agent instance or agent definition
Main consumers	Risk, legal, audit, regulators	Identity provider, gateways, other agents, SOC, plus audit
Update cadence	On change and periodic review	Continuous, driven by platform events and discovery scans
Key fields	Purpose, risk class, data, accountable owner	Identity, credentials, scopes, tools, endpoints, Agent Card, status
Failure if wrong	Compliance gap	Unknown agent holds live access; incident scoping fails

Link the two: every agent registry record should reference its AI register entry, and every AI register entry for an agentic system should list its registry IDs.

The registry data model

Keep the core small enough to be complete for every agent, then extend for higher risk tiers. The fields below combine what A2A Agent Cards can supply with what only the organisation can know.

Field group	Fields	Source
Identity of the record	Registry ID, display name, version, status (proposed, approved, active, suspended, retired)	Registry
Accountability	Business owner, technical owner, cost centre, AI register reference	Registration workflow
Runtime identity	Workload or agent identity ID in the identity provider, credential type (federated token, certificate, secret), issuer, credential expiry	Identity provider, secrets manager
Access	Granted scopes and roles, tools and MCP servers reachable, data classes touched, acts as itself or on behalf of a user	Identity provider, MCP gateway, policy engine
Self-description	Agent Card URL, card version, skills (id, name, tags), supportedInterfaces, securitySchemes, capabilities	A2A Agent Card
Card trust	Signature present, verification result, signing key ID (`kid`), last fetched, content hash	Registry ingestion job
Risk	Autonomy level, risk tier, external exposure, last review date, open exceptions	Risk assessment
Provenance	Platform (builder, cloud AI service, custom code), model provider, code repository, deployment pipeline	Platform APIs, CI/CD

Use the same naming and tagging convention you use for other machine identities so that a registry ID can be found in cloud tags and logs. See the Machine Identity Naming and Tagging Standard Template, and rate autonomy with the AI Agent Autonomy Levels Framework.

Ingesting and verifying A2A Agent Cards

The A2A specification (latest released version 1.0.0, checked 28 October 2026) defines the Agent Card as the JSON document an A2A server publishes to describe itself. Its discovery section names three mechanisms: a well-known URI at https://{server_domain}/.well-known/agent-card.json, curated registries or catalogs, and direct configuration. The A2A discovery documentation notes that the specification does not prescribe a standard API for curated registries, so an enterprise registry is your own design.

What to take from the card

Identity: name, description, provider (organisation and URL), version.
Endpoints: supportedInterfaces, each with a url, protocolBinding and protocolVersion.
Security declarations: securitySchemes and securityRequirements. Compare them with what your policy requires for the agent's risk tier.
Skills: each skill's id, name, description and tags. Treat new skills as a change that needs review.
Capabilities: streaming, pushNotifications and extendedAgentCard. Push notifications imply outbound webhooks; record the destinations.

Verification steps

Fetch with HTTP caching: the specification says servers should send Cache-Control with max-age and an ETag derived from the card version or a content hash, and clients should use conditional requests such as If-None-Match. Use the ETag to detect change cheaply.
Check the signature: Agent Cards may be signed using JWS (RFC 7515). The card is canonicalised with the JSON Canonicalization Scheme (RFC 8785) before signing, the signatures field is excluded from the payload, and the protected header must carry alg and kid, with typ set to "JOSE" and an optional jku. Verify against a key you trust for that provider, not simply the key the jku points to.
Bind the card to an approved record: store the content hash and verification result. A card that changes without a matching change request is drift.
Handle extended cards with care: when capabilities.extendedAgentCard is true, the fuller card is returned only to an authenticated client. Fetch it with the registry's own identity and store it with the same access controls as the source.
Reject embedded secrets: the A2A discovery guidance recommends out-of-band dynamic credentials rather than static secrets in the card. Flag any card that contains anything resembling a credential.

Card signing and client authentication choices are covered in the A2A Protocol Security Guide; MCP server listings have their own publishing risks, covered in the MCP Registry and Server Publishing Security Guide.

Where records come from

No single source sees every agent. Build connectors to each, and let reconciliation decide what is registered, what is new and what is gone.

Source	What it reveals	Typical gap
Low-code agent builders and productivity suites	Agents created by business users, owner, publisher, status. For example, the Microsoft 365 admin center Agent Registry reports counts of agents without owners and unmanaged agents, with a read-only Graph API in preview	Only agents built on that platform
Cloud AI platforms	Deployed agents, the service identity they run as, attached tools	Agents run from containers or functions outside the managed service
Identity provider	Agent and workload identities, app registrations, granted permissions, sign-in activity	Agents using a human's token or a shared secret
MCP gateway and API gateway logs	Which client identities call which tools	Direct connections that bypass the gateway
Well-known endpoint scan	Published Agent Cards on internal and external domains	Agents that do not speak A2A
Code repositories and CI/CD	Agent frameworks in code, deployment definitions, secrets referenced	Experiments never committed
Expense and procurement data	Paid agent products and model API accounts	Free tiers and personal accounts

Discovery of unsanctioned agents is its own discipline; see the Shadow AI Discovery Guide. The matching and conflict rules are the same as for other NHIs, covered in NHI Inventory Reconciliation.

Making registration enforceable

A registry earns its keep when other systems depend on it. Three enforcement points do most of the work.

Credential issuance: the workflow that creates an agent identity, federated trust or secret requires a registry ID in an approved state, and writes the identity ID back to the record. Retiring the record triggers revocation.
Gateway admission: MCP and API gateways admit only client identities that map to an active registry record, and log the registry ID with every call.
Agent to agent calls: a client agent resolves remote agents through the registry rather than arbitrary URLs, and the registry can apply selective disclosure, returning cards only to clients entitled to see them, as the A2A discovery guidance describes.

The identity model behind this is described in the Agent Identity and Access Guide. Each agent should run under its own identity, never a person's credentials or a shared service account.

Implementation roadmap

Weeks 1 to 2, define the minimum record: agree the core fields, status values and the owner of the registry service. Link it to the AI register.
Weeks 2 to 6, connect read-only sources: start with the identity provider and the largest agent builder platform, then cloud AI services. Load everything as "discovered" and assign owners.
Weeks 4 to 8, add Agent Card ingestion: scan known domains for well-known cards, store hashes, verify signatures where present, and report unsigned or changed cards without blocking.
Weeks 6 to 10, pilot enforcement in audit mode: log credential requests and gateway calls from identities with no active record. Fix the false positives before enforcing.
Weeks 10 onwards, enforce for new agents: new agent identities require a registry ID. Bring existing agents in by risk tier, highest first, with a dated exception for the rest.
Rollback: keep enforcement behind a policy switch per gateway and per identity workflow, so a registry outage or bad data can be reverted to audit mode without code changes. Treat the registry as a tier one dependency with its own availability target.

Decision guidance

Situation	Approach	Trade-off
Under 50 agents, one main platform	Use the platform's native registry plus an identity provider export, reviewed monthly	Cheap, but blind to agents outside that platform
Several platforms and custom agents	Central registry service fed by connectors, with the identity provider as the enforcement point	Needs engineering ownership and connector upkeep
Agents exposed to partners or customers	Signed Agent Cards, authenticated extended cards, registry with selective disclosure	Key management for card signing becomes another duty
Regulated or high-autonomy agents	Extended fields, quarterly recertification, change control on skills and scopes	Slower change; worth it where actions are irreversible

Monitoring and metrics

Feed registry events (created, approved, card changed, suspended, retired) to the SIEM alongside identity logs so analysts can resolve an agent identity to an owner during an incident. The targets below are illustrative starting points; set your own from a baseline.

Metric	How to calculate	Illustrative target
Registry coverage	Agent identities with an active record, divided by all agent identities seen in the identity provider and gateways	95% or more
Ownerless agents	Active records with no current, employed owner	Zero older than 14 days
Card drift	Agents whose live Agent Card hash differs from the approved record with no change request	Zero unexplained after 7 days
Unsigned external cards	Externally reachable agents publishing unsigned cards	Falling each quarter
Retirement lag	Days from retirement to revocation of all credentials	5 working days or fewer
Audit-mode denials	Credential or gateway requests from unregistered identities per week	Trending to zero before enforcement

Recertify owners and scopes on a schedule; see Agent Identity Recertification and Agent Permission Drift.

Common failure patterns

Registry as a form: a manual intake form with no connection to credential issuance, so the registry describes the agents people chose to declare.
Trusting the card: treating an Agent Card's declared skills and security schemes as verified facts, when they are the provider's claim.
Verifying with the attacker's key: accepting any signature whose key is fetched from the jku URL in the same card, which proves only that someone signed it.
Owner equals creator: the person who built an agent in a low-code tool leaves, and the agent keeps running with nobody accountable. See Ownership for Orphaned and Abandoned AI Agents.
Retirement without revocation: the record is marked retired while its token grants and secrets remain valid.
Registry exposure: an internal catalogue of every agent, endpoint and skill published without access control becomes a reconnaissance map.

Framework mapping

Framework	Reference	How the registry supports it
NIST AI RMF	GOVERN 1.6, GOVERN 1.7	Inventory of AI systems; safe decommissioning
NIST CSF 2.0	ID.AM-02, ID.AM-04, ID.AM-08, PR.AA-01	Software and service inventories, supplier services, life cycle, managed identities
NIST SP 800-53 Rev. 5	CM-8, PM-5, IA-4, IA-9, AC-2, SA-9	Component and system inventory, identifiers, service authentication, account management, external services
OWASP Top 10 for Agentic Applications 2026	ASI03 Identity & Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities, ASI07 Insecure Inter-Agent Communication, ASI10 Rogue Agents	Known identities and scopes, provenance of third-party agents, trusted discovery, detection of agents that should not exist
CIS Controls v8.1	Controls 1, 2 and 5	Asset, software and account inventories extended to agents

Practitioner checklist

Agree a minimum registry record and link it to the AI register.
Connect the identity provider and main agent platforms as read-only sources first.
Scan internal and external domains for /.well-known/agent-card.json and store card hashes.
Verify Agent Card signatures against provider keys you trust, and record the kid.
Require a registry ID before any agent identity, federated trust or secret is issued.
Log the registry ID at MCP and API gateways.
Protect the registry itself with authentication and selective disclosure.
Report ownerless agents, card drift and retirement lag monthly.
Run enforcement in audit mode first, with a per-gateway rollback switch.

AI agent registry: build a live inventory of agents and agent cards