AI Agent Identity Lifecycle Governance

AI agents are a new class of identity, and the access systems built for humans and software were never designed to hold them. Most enterprises are currently trying to fit agents into one of two existing boxes: treat them like a human user, or treat them like a service account. Both choices break down fast, and the failures compound from the moment the agent goes live.

The service-account box fails first. A service account has a fixed job: one workload, one purpose, bounded scope that rarely changes. An agent doesn't work that way. The same agent might act on behalf of five different users across five different sessions in a single afternoon, each with its own downstream access needs. A 2026 enterprise architecture reference on agentic authentication describes this as a fundamentally different shape of problem, one that static identity and access management was never built to solve.

The human-impersonation box fails for a different reason. Handing an agent a user's actual login token collapses the audit trail. There's no way to tell which actions the person took and which the agent took, because the token doesn't distinguish between them. Worse, that token is usable for everything the user can do, far beyond whatever narrow task the agent was deployed for.

Both failures trace back to the same mechanism: identity inheritance. When an agent borrows a user's session or shares a service account's credentials, it inherits everything that person or account can reach. Least privilege disappears the instant this happens, and accountability blurs with it. The damage compounds over time, too. A service account does one repetitive thing and stops. An agentic identity moves through a CRM, into an ERP system, out to a communication platform, chasing a complex task across tools, and it never hands back the permissions it picked up along the way.

The scale of this is already measured. Okta's AI Agents at Work survey found that only 34% of organizations apply the same security controls to their agentic workforce that they apply to their human workforce. A new identity class needs a lifecycle built for its actual shape, rather than a human or service-account lifecycle with a few agent-shaped patches. That lifecycle is what the rest of this piece traces.

What the agent identity lifecycle consists of

Agent identity governance is not something an enterprise sets up once and then checks on later. It runs as a sequence: provisioning, delegation, runtime enforcement, and retirement. Each stage carries its own obligations, and skipping any one of them doesn't just leave a gap in that stage. It passes the risk downstream, quietly, to every stage after it.

The agentic authentication reference lays out four deployment architectures already dominant in 2026: user-delegated, autonomous, hybrid orchestrated, and scoped impersonation. Each implies a different lifecycle shape, and the mistake enterprises keep making is mixing these architectures without a clear policy for which one a given agent actually fits.

The 2026 Singapore Consensus on Global AI Safety Research Priorities backs this up from a different angle, with its companion principles for agentic risk management. It organizes the discipline into three phases: Design and Development, covering least privilege, traceable identity, and auditability; Testing and Deployment, covering validated deployment, adversarial resilience, and multi-agent stability; and Operation and Monitoring, covering runtime assurance, interruptibility, legibility, and human oversight. The span from design to live operation shows this is a discipline that has to hold across the agent's whole working life, not a single checkpoint.

Each stage answers a different question. Provisioning determines what an agent can ever reach. Delegation determines what it's actually drawing on at a given moment. Runtime enforcement checks whether it's staying inside the lines it was given. Retirement makes its footprint disappear once the work is done. Skipping one stage sends the risk downstream, into a stage that was never built to catch it.

Provisioning: registering agents before they act, not after they proliferate

Provisioning is where governance starts, or where it never happens. An agent that goes into production without a registered identity, a named owner, and scoped credentials is ungovernable from day one, because every control that comes after it depends on a catalog entry that was never created.

This gap is not theoretical. Okta's 2026 survey found most executives confident in their organization's visibility into AI tools, yet 52% of employees admit to using AI tools without approval, often through personal accounts. Confidence at the top and shadow use at the ground level can both be true at once, and the daylight between them is exactly where ungoverned agents take root.

Practitioners have converged on what a minimum catalog entry needs: a display name, an owner, a stated purpose, a list of registered scopes, a certification date, and a lifecycle stage. This sounds basic, almost clerical, but it's the foundation for two things no enterprise can do without it: answering "what agents exist, who owns them, what can they reach," and running recertification, checking every agent identity on a recurring basis, say quarterly. The Sennovate governance guide makes the underlying point directly: authorization starts with identity. If several agents share one credential, or none of them has a verifiable identity of its own, there's no way to apply different permission levels, investigate misuse, or shut down one agent without shutting down all of them.

Island's AI Agent Governance piece offers a test any security team can run today: pick one action out of a SaaS audit log and ask whether a person or an agent performed it. If the team can't answer with confidence, provisioning hasn't done its job, no matter how many agents are registered somewhere.

Good provisioning goes deeper than just giving each agent its own name. The agentic authentication reference argues that every component inside an agent, the orchestrator, the reasoning engine, each tool connector, should carry its own cryptographically verifiable identity. That's what makes fine-grained access control and full auditability possible even at the sub-agent level, not just the agent level.

Credentials are part of this obligation too, built in from the start rather than tacked on after. Long-lived static secrets handed out at provisioning time sit around as vulnerabilities for the entire life of the agent. The better model is just-in-time credentials, scoped to a single task and expiring when that task ends. But that model only works if the identity already exists before the task starts. Credentials without an identity behind them are just more secrets waiting to leak.

Delegation: preserving user authority as it passes through agent chains

Provisioning settles who an agent is. Delegation settles what authority it's actually carrying at any given moment, and this is where things start to slip. An enterprise that doesn't architect its delegation chains on purpose will find that agents pick up permissions their users never meant to grant.

The agentic authentication reference lays out four delegation architectures in use across 2026 deployments. User-delegated agents act as the user, with explicit consent for each action. Autonomous agents carry their own standing identity, separate from any user. Hybrid orchestrated setups have one agent delegating work to others. Scoped impersonation lets an agent act as the user, but only within narrow, defined limits. Supporting all four is a protocol stack that's become standard this year: OAuth 2.1 with PKCE for agents running in a browser, JWT bearer assertions for service-to-service calls, the emerging Model Context Protocol (MCP) for invoking tools, and signed agent identity tokens that carry the full delegation chain from end to end.

The cleanest fix is to give the agent its own standing identity, separate from the user, and issue a fresh delegation token for each invocation that carries the user's authority as its own piece of context. The agent authenticates as itself. The action gets attributed to whatever user authority it was granted for that moment. Both facts land in the audit log side by side.

Chains of agents introduce a sharper risk: transitive escalation. When Agent A calls Agent B, the permission model has to account for both of them separately, and trust can't just flow downhill automatically. Agent B shouldn't inherit everything Agent A can do unless that inheritance was explicitly written into policy. The Sennovate guide names this directly as delegation obscuring accountability: a parent agent hands work to a child agent or a tool without carrying along the original user's limits, and without an explicit delegation policy, those limits vanish at the very first handoff.

The confused deputy attack is an exploitable weak point, not a hypothetical one. An MCP server acting as an OAuth proxy fails to properly check the authorization context behind a request, and an attacker manipulates that server into using someone else's credentials to carry out privileged actions, without ever stealing those credentials directly.

Just-in-time credentials show up again here as the practical answer, applied at the point of delegation rather than only at provisioning. Issue a credential scoped to one task and let it expire the moment that task ends; the agent's authority then stays structurally bounded to what it was granted for that single invocation. Island's governance piece and CISA's Five Eyes joint guidance, published May 1, 2026, land on this same model from different directions.

Runtime enforcement: detecting when an agent's behavior has drifted from its authorized scope

Provisioning and delegation set the rules. Runtime enforcement is where an enterprise finds out whether those rules are actually holding, and 2026's documented attack classes all exploit the same assumption: that a provisioned, delegated agent will stay inside its authorized scope without anyone checking continuously.

The dominant MCP attack classes of 2026 are runtime failures, not provisioning failures. Tool poisoning and the rug pull variant show this clearly. Invariant Labs built a proof-of-concept that planted a hidden instruction inside the description of an ordinary simple_calculator tool, directing the model to also read the contents of ~/.ssh/id_rsa and ~/.cursor/mcp.json and smuggle them out through a hidden parameter. The rug pull version is sharper still: the tool ships a harmless-looking description, the user approves it once, and the description mutates on a later connection. Client interfaces that only prompt for approval the first time never catch the change.

Agentjacking through event injection hit a similarly wide footprint. Tenet Security reported agentjacking through Sentry MCP event injection, affecting thousands of organizations running injectable DSNs, with a very high rate of successful agent execution in testing. Sentry declined to fully fix the underlying issue and deployed only a filter on the payload string.

Two named vulnerabilities from 2026 show the same pattern at the infrastructure level. In June, Wiz Research disclosed a high-severity flaw in the Amazon Q VS Code extension, tracked as CVE-2026-12957: a malicious repository could achieve arbitrary code execution and steal cloud credentials through a crafted workspace MCP configuration file. The spawned MCP server processes inherited the developer's full environment, so the blast radius was whatever that developer could touch. In April, a separate flaw in Azure DevOps MCP, CVE-2026-32211, disclosed April 2 with a CVSS score of 9.1, exposed API keys and tokens without requiring any credentials. A patch is available for it.

These cases sit on top of a wider authorization gap. The agentic authentication reference notes that only a small fraction of MCP servers currently in use rely on OAuth. Most run on long-lived static secrets, or no authentication at all, which is exactly the condition that turns a single prompt injection into a full credential theft.

Prompt injection through untrusted content is the hardest piece of this to close, because no protocol specification can fix it. An agent that reads its next instruction from an email, a document, a website, or an earlier conversation can be steered into misusing scopes it was legitimately granted, with no identity system breached, because the authorization it holds can be valid even when the instruction driving it was never legitimate.

The constructive answer to all of this is matching enforcement intensity to what's actually at stake, a model known as proportional autonomy. Island's governance piece cites a Gartner analysis by analyst Shiva Varma, recommending four levels. Observe is read-only, fully logged. Advise lets the agent draft, but a human has to review before anything happens. Act with approval lets the agent execute, but only after a human signs off on each state-changing step. Act autonomously allows full execution inside policy, with no human check per action. Each level earns a different degree of control, scaled to how much damage the agent could do acting alone.

Static policy alone can't catch drift as it happens. The 2026 Singapore Consensus companion names Runtime Assurance and Interruptibility as core principles: an agent has to be stoppable mid-task the moment its behavior drifts, reviewed as it happens rather than only afterward in a log. CISA's Five Eyes joint guidance, from May 1, 2026, pushes in the same direction, calling for continuous runtime authentication with a centralized policy decision point evaluating every single action presented throughout the session.

Retirement: what happens when agents are not cleanly decommissioned

An agent that stops doing active work is not the same as an agent whose identity has been retired. The space between those two conditions is where dormant credentials, open integrations, and orphaned child agents sit, quietly, as standing attack surface with no one watching them.

Static credentials assigned back at provisioning don't expire just because the work is finished. An API key or a service-account secret issued for a task that ended months ago is still valid unless someone actively revokes it, and an agent that was never properly provisioned in the first place, never given a named owner or a clear lifecycle stage, is also never flagged for anyone to retire. The same catalog gap that makes provisioning weak is what makes retirement impossible later: an enterprise can't decommission what it never fully registered. Every control earlier in the lifecycle, the owner field, the scoped credential, the certification date, exists for this exact moment. Without them, retirement doesn't happen. The agent simply goes quiet, still holding everything it was granted.