Identity Governance for AI Agents: Registry and Ownership

AI agents are being created faster than anyone is registering, owning, reviewing or retiring them, so most organisations already have agents with live credentials and nobody accountable for what they do. Identity governance for AI agents applies the disciplines that IGA brought to human access, and that NHI programmes are bringing to service accounts, to a population that changes behaviour with every new model, prompt or tool. This guide goes deep on the governance layer: the agent registry and what a registry record must hold, owners and sponsors, a joiner-mover-leaver lifecycle for agents, lifecycle drift, access reviews and recertification, credential expiry, decommissioning and orphaned agents. It is for IAM, IGA and AI platform teams who have to answer "which agents do we have, who owns them, and should they still have this access". For agent identity models, credentials and delegation, see the Agentic AI Identity Guide.

Key takeaways

No registry record, no credentials. Registration must be the gate that issues an agent's identity, not a form filled in afterwards, or the registry will always lag reality.
Separate the technical owner from the accountable sponsor. The person who configures an agent is rarely the person who should decide whether it still needs access to customer data; both must be named and kept current.
Agents have movers too. A new model, system prompt, tool, data source or autonomy level is a change of identity that should trigger re-review, just as a role change does for an employee.
Review agents by risk and by expiry. Time-bound access assignments that lapse unless a sponsor renews them do more than annual certification campaigns that reviewers rubber-stamp.
Decommissioning is a checklist, not a delete button. Deleting an agent can leave its role bindings, OAuth grants, API keys and tool credentials active; retirement must find and revoke each one.

Why agents need their own governance process

An agent is a non-human identity, so the service account basics apply: an inventory, an owner, least privilege, rotation and offboarding. Three properties make the governance problem harder than for a service account.

Volume and speed: low-code builders let business users create agents in minutes. Manual onboarding cannot keep up.
Behaviour that changes without a code change: swapping the model, editing the instructions or adding a tool changes what an agent will do with the same credentials. A service account review asks "does this job still need this access"; an agent review must also ask "is this still the agent we approved".
Mixed authority: many agents hold their own permissions and delegated permissions from users at the same time, so a review has to cover both. The AI Agent Authorisation Guide covers how that authority should be scoped.

Frameworks already expect this. The NIST AI Risk Management Framework (AI 100-1) requires under GOVERN 1.6 that "Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities", and under GOVERN 1.7 that "Processes and procedures are in place for decommissioning and phasing out AI systems safely". The Generative AI Profile (NIST AI 600-1) adds suggested actions GV-1.6-001, "Enumerate organizational GAI systems for incorporation into AI system inventory", and GV-1.7-001, "Protocols are put in place to ensure GAI systems are able to be deactivated when necessary".

The agent registry

An agent registry is the system of record for every agent allowed to hold credentials. A unified agent registry covers agents from every source (cloud agent platforms, low-code builders, copilots, coding agents, custom frameworks and third-party SaaS agents) in one schema, even when each platform keeps its own native directory. Platform directories are now appearing: Microsoft Entra Agent ID creates agent identities from agent identity blueprints, which Microsoft describes as templates "with parent-child relationships, enabling consistent security policies across large numbers of agents"; Google's Vertex AI Agent Engine assigns each deployed agent a SPIFFE-based principal; and Amazon Bedrock AgentCore Identity implements agent identities "as workload identities with specialized attributes". Your registry should reference these identifiers rather than duplicate them.

The agent registry record

Field	Why it matters	Example
Agent ID and platform identifiers	Links the record to every identity the agent uses (agent identity object ID, principal string, OAuth client ID, role ARN)	AGT-0193; Entra object ID; `principal://agents.global.org-[id].system.id.goog/...`
Purpose and business process	The basis for every later access decision	Drafts replies to tier 1 support tickets
Sponsor, owner, deputy	Accountability and succession (next section)	Head of Support; [developer]; [developer]
Identity model	Acts as itself, on behalf of users, or both	Own identity plus delegated user tokens
Model, version, framework, host	Changes here are mover events	[Model] [version], [framework], [platform]
Tools, MCP servers, data sources, other agents	The real attack surface; drives the review	Ticketing API (read, comment); knowledge base (read)
Entitlements	Roles, scopes, groups, access packages, with expiry dates	Access package "Support agent read", expires 2027-01-31
Credential type and rotation	Platform-issued and short-lived, or static secret	Federated workload identity; no stored secret
Autonomy level and approval points	Which actions need a human approval	Can comment; cannot close or refund
Data classification reached	Sets review cadence	Confidential (customer personal data)
Risk rating, review date, end date	Drives recertification and default expiry	High; reviewed 2026-09-30; ends 2027-03-31
Status	Proposed, active, suspended, retired	Active

Agent registration should be enforced where credentials are issued: platform policies that block publishing an agent without a sponsor, an identity provider that will not issue a client credential without a registry ID, and a secrets manager that refuses requests from unregistered workloads. Agents discovered with no record are shadow AI; bring them in through the Shadow AI Discovery Guide process rather than letting them keep their access while paperwork catches up.

Agent ownership: owners, sponsors and managers

Agent ownership fails in two ways: nobody is named, or the named person is a developer who has moved on. The fix is two kinds of accountability, each with a deputy. Microsoft's Entra Agent ID model is a useful reference because it separates them explicitly.

Role	Accountable for	Typical person	Entra Agent ID equivalent
Agent sponsor	Purpose, continued need, access decisions, renewal or retirement	Business owner, product manager, team lead	Sponsor: "Business representatives accountable for the agent's purpose and lifecycle decisions, including access reviews and agent retention"; required at creation
Agent owner	Configuration, credentials, deployment, technical remediation	Developer or platform engineer	Owner: technical administrators for setup, configuration and credential management; multiple allowed for backup
Manager	Organisational line of accountability; requests access in some models	Line manager of the sponsor or team	Manager: can request access packages, cannot modify or delete agents

In Entra, a sponsor can disable an agent but "Can't re-enable or restore" it, which is the right split: the business can stop an agent, and only a technical owner can bring it back. When a sponsor leaves, Microsoft states that "sponsorship of the agent identities is automatically transferred to their manager", and lifecycle workflow tasks notify co-sponsors and managers of the change. Whatever platform you use, apply the same agent ownership checks on a schedule:

Sponsor is active: the sponsor account is enabled and still in the business unit that uses the agent.
Owner can act: at least one technical owner still has rights on the agent's platform and repository.
Deputy exists: every High-risk agent has two named people who can suspend it.

The general rules for NHI ownership, including how to find owners for existing identities, are in the NHI Ownership Guide.

Agent joiner, mover, leaver

The agent lifecycle maps onto the joiner-mover-leaver pattern used for people. Governed agent lifecycle management means each event has a trigger, an approver and an automated action.

Event	Trigger	Governance action
Joiner (agent onboarding)	Request to deploy an agent with access to non-public data or systems	Registry record created; sponsor and owner named; risk rated; identity issued from a template; access granted through time-bound packages; threat model for High risk
Mover: configuration	New model or version, changed system prompt, new tool or MCP server, new data source, higher autonomy	Change recorded; risk re-rated; entitlement review before the change goes live if risk rises
Mover: ownership	Sponsor or owner leaves or changes role	Ownership transferred before the person's own account is disabled; new sponsor attests within [30 days]
Mover: scope	Agent rolled out to more users, business units or tenants	Delegated scopes and consent re-reviewed; data classification re-checked
Leaver (agent offboarding)	Sponsor retires it; end date reached; failed review; unused for [60 days]; incident	Suspend, revoke, verify, archive (see decommissioning)

Unlike the people version in the Joiner-Mover-Leaver Guide, the trigger feed is not HR but change events from agent platforms and CI/CD pipelines.

Agent lifecycle drift

Agent lifecycle drift is the gap between what the registry says an agent is and what is actually deployed. It is the agent equivalent of entitlement creep, and it grows quickly because agents are reconfigured often. Common forms:

Tool drift: new tools or MCP servers connected without a change record. Compare the registered toolset with the tools the agent actually called in its logs.
Permission drift: roles or scopes added directly on the platform rather than through an access package, so they never expire.
Model and prompt drift: the agent runs a different model or instructions from the version that was reviewed.
Identity drift: the agent starts using a second credential, often a developer token or a shared API key, alongside its registered identity.

Detect drift by reconciling three sources on a schedule: the registry, the platform directories (agent identities, service principals, role bindings, OAuth grants) and the agent's own activity logs. Differences go to the owner; on High-risk agents, the new capability is suspended until reviewed. The AI Agent Observability and Incident Response Guide covers the logging this depends on.

Agent access reviews and recertification

An agent access review asks the sponsor to confirm that the agent is still needed, still the agent that was approved, and still needs each entitlement. To be useful, the review must show the reviewer evidence, not just a list of role names:

Entitlements with usage: each role, scope or access package, when it was last used, and by which tool.
Changes since last review: model, prompt, tools, owners and new delegated consents.
Activity summary: volume of actions, the systems touched, approvals requested and denied, and any alerts.
Delegated access: which users granted the agent authority, with which scopes.

Agent risk	Example	Agent recertification cadence	Default access expiry
High	Writes to production, moves money, reaches personal or regulated data, acts autonomously	Quarterly, plus on every mover event	90 days
Medium	Reads confidential data; writes to internal systems with human approval	Six-monthly	180 days
Low	Reads public or internal data only; no write actions	Annually	1 year

Expiry does much of the work. In Microsoft Entra ID Governance, agent identities can receive access packages; as the expiry date approaches the sponsor is notified, and "If the sponsor takes no action, the access package assignment automatically expires on its end date, and the agent identity loses access to the target resources." That turns agent entitlement review into a default-deny renewal rather than an annual campaign. See the Access Reviews Guide for avoiding rubber-stamp reviews.

Credential rotation and expiry for agents

Governance should set the rule; the platform should enforce it. Record each agent's credential type in the registry and hold owners to these standards:

Prefer platform-issued, short-lived credentials: Google states that Agent Engine agent identities receive an X.509 certificate valid for 24 hours that Google Cloud renews automatically, and that they "can't be impersonated". Credentials like these need no rotation process at all.
Static secrets need an expiry and an owner: any API key, client secret or personal access token an agent uses has a maximum lifetime of [90 days], lives in a secrets manager and is listed in the registry record.
No human credentials: an agent found using a person's token or password fails review and is suspended until moved to its own identity. OWASP lists Human Use of NHI as NHI10 and NHI Reuse as NHI9 in its Non-Human Identities Top 10 (2025).

Rotation mechanics and their pitfalls are in the Guide to NHI Rotation Challenges.

Agent decommissioning and orphaned agents

Google's documentation for Agent Engine is explicit: "Deleting an agent doesn't remove the IAM bindings that reference its principal." The same pattern holds elsewhere: OAuth consents, API keys issued by third-party tools, entries in MCP server allow-lists and webhook secrets all outlive the agent unless someone removes them. Use this agent decommissioning sequence:

Suspend: disable the agent identity and stop the runtime so it cannot act or obtain new tokens. Keep the record.
Revoke: remove role bindings and access package assignments, revoke delegated user grants and OAuth consents, delete API keys and client secrets, remove the agent from tool and MCP server allow-lists, and revoke tokens held in any credential vault the platform uses.
Verify: query each platform for any remaining reference to the agent's identifiers, and alert on any authentication attempt for [30 days].
Archive: retain the registry record, configuration and activity logs for [retention period] for audit and incident response.
Delete: remove the identity after the hold period, and mark the record retired.

Orphaned agents are agents whose sponsor and owners are gone, whose project has ended, or that no registry record claims. Find them by looking for agent identities with disabled or departed sponsors, agents with no successful activity in [60 days] but live credentials, OAuth apps and service principals with AI-related names and no record, and API keys used only by an agent runtime. Treat an orphaned AI agent as High risk until proven otherwise: restrict it first, give the last known business unit [14 days] to claim it, then decommission. Improper Offboarding is NHI1, the first risk in the OWASP Non-Human Identities Top 10.

Implementation roadmap and decisions

Discover (weeks 1 to 4): list agents from every platform directory, low-code environment, OAuth consent log and secrets store. Load them into a registry as "proposed".
Assign (weeks 3 to 8): name a sponsor and owner for each; restrict anything unclaimed after notice.
Gate (weeks 6 to 12): make registration a precondition for new credentials on your main platforms; start in report-only mode, listing what would have been blocked, then enforce.
Time-bound access (months 3 to 6): move agent permissions into access packages or equivalent assignments with expiry, and run the first risk-based review.
Automate lifecycle (months 6 onward): feed platform change events into the registry, reconcile for drift, and automate decommissioning steps with verification.

Roll back by keeping the registry gate in report-only mode for a platform where it blocks legitimate deployments, while the missing sponsors are added. The stages line up with the Agentic AI Identity Maturity Model.

Where to keep the registry	Choose when	Trade-off
Extend the IGA platform	You already certify human and service account access there, and it can treat agents as an identity type	Strong reviews and workflows; weak at discovering agents and runtime context
CMDB record type	Smaller estates, or where the CMDB already drives change management	Cheap and familiar; no enforcement unless integrated with credential issuance
Platform-native directory (for example Entra Agent ID)	Most agents run on one ecosystem	Built-in sponsors and expiry; does not cover agents on other platforms without integration
NHI or agent security platform	Many platforms, many agents, need for discovery and drift detection	Broad coverage; another system to integrate with IGA

Small and large organisations: a small organisation with a handful of agents on one platform can run the registry as a CMDB or spreadsheet with quarterly sponsor sign-off, as long as no agent gets credentials without a record. A large organisation needs a unified agent registry fed automatically from each platform, time-bound access everywhere and drift reconciliation, because manual review will not scale to thousands of agents.

Measuring agent governance

Registry coverage: agent identities found on platforms that have a registry record (target 100% for production).
Ownership health: percentage of agents with an active sponsor and owner; count of orphaned agents and their median age.
Time-bound access: percentage of agent entitlements with an expiry date.
Review completion: High-risk agents reviewed within cadence, and the percentage of entitlements removed at review (zero removals over several cycles suggests rubber-stamping).
Drift rate: registry mismatches found per reconciliation and time to resolve.
Retirement completeness: decommissioned agents with zero remaining bindings, grants or keys at verification.

Governance area	NIST AI RMF / AI 600-1	OWASP NHI Top 10 (2025)	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A
Agent registry	GOVERN 1.6; GV-1.6-001	NHI1	CM-8, AC-2	A.5.9 Inventory of information and other associated assets
Ownership and sponsors	GOVERN 2.1	NHI1	AC-2	A.5.16 Identity management
Access reviews and expiry	GOVERN 1.6	NHI5 Overprivileged NHI	AC-2, AC-6	A.5.18 Access rights
Credentials		NHI7 Long-Lived Secrets, NHI9, NHI10	IA-5	A.5.17 Authentication information
Decommissioning	GOVERN 1.7; GV-1.7-001	NHI1 Improper Offboarding	AC-2	A.5.18 Access rights
Third-party agents	GOVERN 6.1	NHI3 Vulnerable Third-Party NHI	SA-9	A.5.19 Information security in supplier relationships

The OWASP Top 10 for Agentic Applications for 2026, published in December 2025, adds agent-specific risks on top of these; see the OWASP Agentic Applications Top 10. NIST's NCCoE is also scoping a project on "standards-based approaches to identify, manage, and authorize access and actions taken by software agents", tracked in the Agent Identity Standards Tracker.

Common failure patterns

Forgotten agents keep their tokens: a pilot ends but the OAuth grant stays live. In the Vercel Context.ai OAuth breach, a forgotten AI app's stolen token exposed customer secrets.
Registry as a survey: teams declare agents once a year, so the registry is never complete or enforced.
Developer as sole owner: the builder leaves and nobody can say what the agent is for, so nobody dares switch it off.
Reviews without evidence: sponsors approve role names they do not understand. Show usage and changes, or the review is theatre.
Standing, over-scoped tokens: in the PocketOS database deletion, an AI coding agent used an over-privileged token to wipe production.
Delete without revoke: the agent object is removed but its bindings, keys and consents remain, waiting to be reused.

Practitioner checklist

Stand up an agent registry with the record fields above and load every agent found on your platforms.
Name a sponsor, an owner and a deputy for every agent; restrict any agent unclaimed after [14 days].
Make a registry record a precondition for issuing agent credentials, starting in report-only mode.
Grant agent access through time-bound assignments that expire unless the sponsor renews them.
Treat model, prompt, tool, data source, autonomy and ownership changes as mover events that update the record and trigger review.
Reconcile registry, platform directories and activity logs on a schedule to catch lifecycle drift.
Run risk-based recertification that shows reviewers usage, changes and delegated grants.
Decommission with a suspend, revoke, verify, archive, delete sequence and check for leftover bindings and keys.
Report registry coverage, ownership health, time-bound access, drift and retirement completeness monthly.

Identity Governance for AI Agents Guide: Registry and Ownership