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 governance problem organizations encounter first is not delegation semantics but the inability to enumerate what they are running. Registries supply the discovery layer that A2A Agent Cards are published against, the subject data that 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.

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. The SCIM Agent Extension draft, presented at IETF 125 in March 2026, proposes two new resource types — Agents and AgenticApplications — giving agent lifecycle a standard schema 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.

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, continuing the line of work begun as OIDC-A. 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, DIF, and IETF WIMSE. Worth noting while that work matures: 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 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 the agent identity landscape, 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. Industry analyst projections put embedded agents in roughly 40% of enterprise applications by the end of 2026, up from under 5% a year earlier, which means most organizations will acquire agents through software they already run 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 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 genuinely 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. Adopting the SCIM Agent Extension schema where tooling supports it keeps that inventory aligned with the standard most likely to be reflected in identity governance tooling, and leaves the less settled questions of cross-organizational agent resolution to be adopted later without rework.