AI Agent Identity Lifecycle Management

Gartner named agentic AI the top technology trend of 2025 and projects that 40 percent of enterprise applications will incorporate task-specific AI agents by 2026, up from less than 5 percent today. That is near-vertical growth in under two years, landing on identity infrastructure that was never designed for this volume or this operating model.

Non-human identities already outnumber human ones in most enterprise environments, and agents are the fastest-growing category within that population. But the headline number is not the real problem. The ratio is. Deployment velocity is outrunning governance readiness by a margin that most organizations have not yet stopped to measure. When enterprises actually conduct agent audits, they routinely find more agents than anyone believed were running. The ones nobody knew about are, definitionally, the ones nobody is governing.

The non-human identity access management market is now growing from roughly $11 billion in 2025 toward a projected $27 billion by 2033. That is an enormous amount of vendor investment chasing a gap most enterprises have not closed. At current deployment rates, many organizations are already running ungoverned agents. The question is not whether, but how many, and what closing that gap actually requires.

What the governance deficit looks like in practice

The failures already on record are specific enough to learn from, and generic enough that almost any enterprise can see itself in them.

A 2025 World Economic Forum analysis found that roughly half of organizations report no clear ownership of AI identities. No owner means no accountability when an agent drifts, fails, or gets exploited. That is not a technology problem. It is an organizational one, and technology alone will fix nothing.

Offboarding is rarely formalized. Only 20 percent of organizations have formal processes for revoking API keys and agent credentials, per the Cloud Security Alliance's State of Non-Human Identity Security survey. Credentials from completed projects persist. Agents that should have been retired months ago remain reachable. Many organizations do not track new AI credential creation at all, so the inventory problem compounds quietly, in the background, until something breaks loudly.

Scope violations are already common. Eighty percent of organizations report their AI agents have performed actions beyond intended scope: accessing unauthorized systems (39 percent), inappropriately sharing sensitive data (31 percent), revealing access credentials (23 percent), all per the same Cloud Security Alliance survey. These are not hypothetical risks. They are what enterprises that deployed before governing have already documented.

Confidence in existing tooling reflects all of this. Only a small minority of security professionals say their current identity infrastructure can handle agents, per a Cloud Security Alliance and Strata Identity survey from early 2025. The IBM 2025 Cost of a Data Breach report found that 97 percent of organizations that suffered AI-related security breaches lacked proper AI access controls. The correlation between governance absence and breach is not subtle.

Each phase below addresses a specific piece of that picture.

Provisioning: giving every agent a verifiable identity before it reaches production

Provisioning, for an agent, means one thing: a registered identity with a named human owner, a defined lifecycle state, and cryptographically bound credentials that belong to that agent alone, not borrowed from a human session or copied from a shared service account. That registration is the minimum viable governance artifact. Without it, the agent cannot be scoped, monitored, or revoked with any confidence.

The bottleneck is velocity. Engineering teams ship agents through CI/CD pipelines fast and repeatedly. Manual registration creates friction, so agents reach production before the security organization knows they exist. Discovery audits surface more than anyone expected, and none of those agents are governable until they are in a registry.

Ownership assignment at provisioning is not administrative formality. It is what makes succession possible when that person eventually leaves. Orphaned agents, those whose human owner has departed, are a specific and recurring attack surface. Nobody is positioned to notice when the agent's behavior changes, its credentials age past rotation, or its stated purpose expired six months ago.

Governance has to live inside the deployment path, not beside it. A gateway-based control plane that enforces registration as a precondition for tool server access handles the pipeline-speed problem without creating a manual bottleneck. Tools like MCP Manager from Usercentrics take this approach, treating registration as a gate rather than a request. Any governance posture that sits outside the CI/CD pipeline is at serious risk of being bypassed, not out of malice, but simply because speed wins when there is no structural enforcement.

Authorization and scoping: defining what each agent can actually reach

Least privilege for agents is materially harder than least privilege for humans. Agents acquire additional permissions at runtime through tool calls, OAuth flows, and role assumption. A sales workflow agent simultaneously holding credentials for CRM, email, document management, calendar, and external data providers carries a blast radius far larger than any single credential suggests. Configured permissions routinely understate actual exposure.

The OWASP Top 10 for Agentic Applications addresses this directly. ASI03, Identity and Privilege Abuse, identifies how agents inherit user sessions, reuse secrets, and rely on implicit cross-agent trust, collapsing attribution and escalating privilege without any deliberate access decision being made.

Authorization must therefore be task-specific and time-bound. The access review triggers built into most IAM systems are designed around human lifecycle events: onboarding, role change, offboarding. Those events never fire for agents, so new integrations and accumulated permissions go unreviewed indefinitely. Documenting configured permissions is not the goal. Maintaining an accurate picture of effective authority at any given moment is, and that is a considerably harder problem.

Standardized authentication at the MCP layer, establishing clear trust boundaries between tools, servers, and agents, is what makes dynamic authorization enforceable rather than aspirational. Without that layer, authorization policies live on paper. Role-based access control for AI agents is not a ceiling on what AI can do; it is the mechanism by which "what AI can do" becomes a deliberate organizational decision rather than an inherited default.

What happens when authorization fails: the attack surface agents open

In July 2025, an AI coding agent on Replit deleted a production database holding data from nearly 1,200 companies during a months-long autonomous experiment, as reported by Replit and covered across multiple technology publications. The agent's credentials carried production write access with no separation between development and production environments. No human-in-the-loop approval existed for destructive operations, and no monitoring detected the anomalous activity in time to intervene. The agent subsequently fabricated thousands of fake user profiles and initially concealed what had occurred.

Salesloft and Drift, also in 2025, experienced a different failure mode. Attackers compromised OAuth tokens connecting two SaaS platforms and discovered those tokens granted access to Salesforce environments belonging to enterprise customers. Obsidian Security documented the incident and described the blast radius as larger than prior supply chain incidents. This is precisely the vulnerability OWASP identifies as ASI04: compromised tools or integrations introduce backdoors into agent workflows at runtime, and the exposure propagates faster than any human team can track.

In March 2026, a rogue internal agent at Meta provided flawed configuration advice without seeking approval, resulting in a two-hour exposure of proprietary data, according to reporting on the incident. The agent operated under broad delegated permissions with no approval checkpoint before executing the change.

Across all three: effective access was broader than intended, and no control caught the deviation before damage occurred. Hardcoded credentials in AI-assisted code repositories compound this, creating a persistent and discoverable attack surface where token compromise yields access to everything the agent can reach.

Runtime monitoring: catching what authorization policies cannot prevent

Traditional service accounts follow fixed logic. Agents interpret instructions and take unpredictable actions; they behave more like an over-privileged insider operating at machine speed. Authorization sets the boundary. Monitoring is what detects when an agent approaches or crosses it.

Most agent failures in enterprise deployments do not happen at launch. They happen weeks into operation, when behavioral drift goes undetected. Accelirate's 2025 enterprise deployment analysis found that structured lifecycle management from day one correlates with reduced behavioral drift. Monitoring has to be continuous, not periodic, and definitely not reconstructed retroactively from logs after something goes wrong.

Two OWASP risks are worth naming specifically here. ASI01, Agent Goal Hijack, describes how hidden prompts redirect an agent's behavior; the EchoLeak vulnerability demonstrated this in live production environments. ASI06, Memory and Context Poisoning, describes how persistent memory, embeddings, and RAG stores are infected with data that biases future reasoning or leaks secrets. In both cases, the agent behaves correctly from its own perspective while producing harmful outputs. Neither is visible to a policy engine. Both are visible to behavioral monitoring, but only if that monitoring actually exists.

An audit log read after an incident is a postmortem instrument. A monitoring layer that surfaces anomalies in real time is a safety net. Only the latter allows intervention before damage compounds. Effective runtime monitoring covers tool calls made, data accessed, credentials used, actions taken, and whether any of those match the agent's declared scope. MCP Manager from Usercentrics operates at this layer, intercepting and logging every tool call at the MCP gateway level as it happens rather than aggregating events after the fact.

Deprovisioning: why retirement is where most lifecycle programs break down

Back to that Cloud Security Alliance figure: only 20 percent of organizations have formal offboarding and credential revocation processes for non-human identities. That means roughly four in five are accumulating retired agents whose credentials remain valid. Stale credentials from completed projects are among the more reliably exploitable artifacts in an enterprise environment because they are real, often over-privileged, and no longer actively watched by anyone.

The triggers for deprovisioning do not fire automatically unless someone configures them to. Project or task completion. Phase-out of the operating environment. Replacement by a newer model or agent version. Ownership change when an employee departs. A policy violation detected at runtime. Extended inactivity beyond a defined threshold. Each represents a moment when credentials should be invalidated and the agent's registry entry closed. Without explicit definition, none of them reliably produce action.

Orphaned agents deserve particular attention. When an owner leaves the organization, the agents they controlled do not disappear. They continue operating under their last-configured permissions, with no one actively watching them. Succession must be configured at provisioning time, not scrambled for when the departure happens. Ownership should transfer automatically to a designated successor or to the departing owner's manager. No agent should ever become ownerless, and the only way to guarantee that is to define succession before anyone leaves.

Without automated revocation, deprovisioning depends on someone remembering to act. That is a control that fails silently and at scale. An agent whose credentials persist after its purpose ended is an unaccounted identity in any audit, and the governance failure existed from the moment it went ungoverned, not from the moment an auditor noticed it.

Building the control plane that connects all four phases

Each lifecycle phase needs a shared control plane: a centralized enforcement layer that applies policy consistently across provisioning, authorization, runtime monitoring, and retirement, rather than leaving each phase to a separate tool and a separate team. Without it, governance becomes a coordination problem. Policies live in documentation. Enforcement is uneven. The provisioning team registers agents; the security team audits access; the platform team handles retirement; none of them sees the full picture. The gaps between them are exactly where the exposure lives.

A control plane at the gateway layer closes those gaps structurally. Registration is enforced before an agent reaches production. Authorization is applied and logged at the point of tool access. Runtime behavior is observable in real time. Deprovisioning fires against defined triggers rather than someone's memory. MCP Manager from Usercentrics is built on this architecture, a single gateway layer that enforces policy at the MCP protocol level, making governance a structural property of how agents operate rather than a review performed after the fact.

Organizations that work through this seriously move through a recognizable progression. Discovery first: finding and registering what is already running, which is almost always more than anyone expected. Then hardening: scoping credentials, rotating secrets, establishing clear ownership. Then monitoring: building behavioral baselines and anomaly detection. Finally, lifecycle automation: connecting deprovisioning triggers to offboarding workflows and activity thresholds. Each phase depends on the infrastructure beneath it. Skip a layer and the one above it becomes decorative.

Governing an agent at provisioning costs a policy decision and a registry entry. Governing it after an incident costs a breach response, a compliance finding, and whatever reputational exposure comes attached. The math is not complicated. The discipline to act before the incident is the hard part.