AI Agent Registry and Lifecycle

An AI Agent Registry is the authoritative inventory of the agents operating in an environment, recording which agents exist, what identity each holds, which runtime instance it maps to, and where it sits in its lifecycle from provisioning through decommissioning. It is the least novel and most immediately actionable part of agent identity: the first governance problem organizations encounter is the inability to enumerate what they are running, well before any question of delegation. Registries supply the discovery layer that A2A Agent Cards are published against, the subject data that policy-based access control (PBAC) policies evaluate, and the inventory that posture and audit tooling consumes.

What a Registry Holds

Beyond a list of agents, a useful registry records the metadata that other controls depend on: the identity and credentials issued to each agent, the human or team accountable for it, the tools and systems it is permitted to reach, the runtime instance it currently corresponds to, and its provisioning state. The instance mapping matters more for agents than for conventional workloads. Because agent behaviour can diverge between instances of the same deployment, audit attribution requires knowing which instance acted, which in turn requires the registry to track instances rather than only agent definitions.

Accountable ownerSCIM provisioningPurchased softwareAgent registryPBACISPMA2A discovery accountableregistereddiscoveredsubject datainventorypublished from
Inventory is the control the others wait on: policy decisions read it for subject data, posture management reads it to find orphaned identities and drifting credentials, and A2A discovery is published from it — and one of the two ways an agent arrives in it is discovery, because an agent embedded in purchased software was registered by nobody.
Agent definitionRuntime instanceCredential issuanceAudit record instantiatedcreated, destroyedissued, revokedwhich instance acted
Two instances of one deployment can behave differently, which is why the entry that matters is the instance rather than the definition: a credential appears when an instance starts and is withdrawn when it exits, and the audit record then names which instance acted instead of which agent was configured.

Lifecycle is where registries earn their place. Agents may be created and destroyed within seconds, which puts credential issuance and revocation beyond the reach of ticket-driven provisioning. Issuing credentials at instantiation and revoking them automatically at decommission is the Zero Standing Privileges pattern applied to agents, and it depends on the registry being the system that observes both events.

Standardization

Provisioning is the furthest along, though not yet standardized. Several individual Internet-Drafts, none of them adopted by the IETF SCIM working group, propose agent resource types for the System for Cross-domain Identity Management (SCIM); the AI Agent Resource Extension, for example, defines an Agent resource type with named owners. The shared idea is a schema for agent lifecycle that existing SCIM-capable governance tooling can consume without protocol changes. For organizations already provisioning users over SCIM, this is a considerably shorter path than a bespoke agent onboarding process, once one schema is settled.

Representation and resolution are less settled. Draft-sharif-openid-agent-identity proposes agent identity claims, an Agent ID Token, and agent identity provider metadata as an extension of OpenID Connect. For cross-organizational resolution, the W3C Agent Identity Registry Protocol Community Group, formed in April 2026, is developing a web-anchored DID method (did:wba) built on decentralized identifiers, coordinating with the OpenID Foundation, the Decentralized Identity Foundation (DIF), and the IETF Workload Identity in Multi-System Environments (WIMSE) working group. That work is still maturing. Establishing that a party from another organization is a member in good standing of something accountable is not a new problem, and OpenID Federation is the finalized answer to it. No agent identity effort has adopted it as the trust anchor for registries yet, but it is the obvious existing candidate. The NIST National Cybersecurity Center of Excellence (NCCoE) concept paper sets the governance floor these efforts are measured against: unique verifiable identification, policy-based authorization, user context delegation through agent chains, and dual-attribution audit logging.

Implementation Maturity

Unlike most of agent identity, registry capability does not depend on the standards converging first. Enterprise directory platforms became generally available with agent identity as a first-class object type during 2026, and identity governance tooling has begun treating agents as governable entities alongside conventional accounts, including discovering agents created in low-code and embedded AI platforms, which are otherwise invisible to conventional account governance. Controlling which applications an agent may connect to is emerging as a related capability in the same platforms.

Agent inventory therefore need not wait, and the scale argument says it should not. Agents increasingly arrive embedded in applications an organization already runs, which means most organizations will acquire agents through software they already have rather than through deliberate agent projects. Discovery-based inventory consequently matters as much as registration-based inventory: an agent nobody chose to deploy still holds credentials. Registry data feeding identity security posture management (ISPM) tooling is what surfaces the resulting misconfigured scopes, orphaned agent identities, and credential drift.

Where that inventory lives deserves a deliberate decision. Agents are a population of non-human identities, and standing a registry up beside the existing workload and machine identity governance tends to produce two inventories that nobody reconciles: the service account an agent authenticates with sits in one, the agent itself in the other, and neither is authoritative when an auditor asks who is accountable. Extending the population an organization already governs keeps ownership, certification, and joiner-mover-leaver handling in one place. The instance-level tracking described above is the test: a separate registry earns its place only where the existing tooling cannot express which instance acted.

Summary

The registry is the foundation the rest of agent identity governance sits on, and it is the part an organization can act on without waiting for draft specifications to stabilize. The sequence that works is inventory first (including discovery of agents arriving inside purchased software), then ownership and accountability for each entry, then automated lifecycle so credentials appear and disappear with the instances they belong to. Modelling agents as SCIM resources where tooling supports it keeps that inventory in the protocol identity governance tooling already speaks, whichever agent schema the SCIM working group eventually adopts, and leaves the less settled questions of cross-organizational agent resolution to be adopted later without rework.