Agentic AI identity risk is outrunning enterprise IAM controls

At a glance

What this is: AI agents are creating a governance gap because they act as dynamic identities that can invoke tools, access data, and chain decisions faster than traditional IAM can review.

Why it matters: IAM, PAM, and NHI teams need to treat agent identity as a runtime control problem, because static roles, quarterly reviews, and shared credentials cannot contain delegated machine action.

By the numbers:

• Gartner projects that 40% of enterprise applications will embed task-specific AI agents by the end of 2026, up from less than 5% in 2025.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Strata Identity's analysis of agentic AI identity governance and MCP risk

Context

Agentic AI identity risk emerges when AI systems are allowed to authenticate, call tools, and delegate work across cloud services without human review of each step. The primary keyword here is agentic AI identity risk, and the problem is that security teams often apply human IAM patterns to actors that do not behave like humans.

The governance gap is not just about more automation. It is about runtime decision-making, MCP-mediated tool access, delegated authority chains, and privilege drift that can appear within a single session. For identity programmes, that means NHI controls, agent governance, and human accountability now intersect in the same access path.

That gap is already visible in production deployments, where teams over-provision scopes to keep workflows running and then struggle to reconstruct who authorized what. The starting position is typical for fast-moving enterprises, not an edge case.

Key questions

Q: How should security teams govern AI agents that can use internal tools and APIs?

A: Security teams should govern AI agents at runtime, not just at provisioning or review time. Give each agent a distinct identity, scope access to the specific task, and enforce policy before every tool call. If the agent can reach systems through alternate paths, the governance layer must sit in front of those paths, not beside them.

Q: Why do AI agents create more identity risk than traditional service accounts?

A: AI agents create more identity risk because they make decisions during execution, not only during setup. Their access can expand through delegated workflows, tool chaining, and reused credentials, which makes standing roles and quarterly reviews too slow to contain the exposure. The result is privilege drift that grows during normal operation.

Q: What breaks when MCP access is not centrally enforced?

A: When MCP access is not centrally enforced, agents can bypass the sanctioned protocol and reach the same data through alternative connectors or direct application paths. That breaks policy consistency, weakens auditability, and leaves security teams with multiple uncontrolled routes to the same backend system.

Q: What should IAM teams do when agent-to-agent delegation is involved?

A: IAM teams should preserve provenance across the delegation chain and avoid credential handoffs that erase the original requester. Every downstream action should remain tied to the initiating subject, the task scope, and the policy that authorized it. That is what makes the workflow auditable and the accountability model defensible.

Technical breakdown

Runtime identity for AI agents

AI agents need identities that can be issued, scoped, observed, and revoked at the moment of action. Unlike a human user or a fixed service account, an agent may initiate tool calls, combine data sources, and alter its next step based on runtime context. That means identity is not a one-time provisioning event. It becomes the enforcement point for each access decision, each delegation handoff, and each tool invocation. In practical terms, the important control boundary is not the application layer alone but the authentication and authorization event that precedes every agent action.

Practical implication: treat every agent action as a live authorisation event, not a static entitlement.

MCP governance and tool access control

The Model Context Protocol creates a standard path between agents and tools, but a standard path is not the same as a governed path. If an agent can reach the same backend through a side door, the protocol becomes advisory instead of enforceable. MCP governance therefore depends on a proxy or enforcement layer that validates identity, checks policy, and records the transaction before the request reaches the target system. This is especially important when multiple agent frameworks coexist, because inconsistent identity handling creates blind spots across the tool chain.

Practical implication: put policy enforcement in front of MCP, not around it.

Broken delegation chains across agent-to-agent workflows

Delegation chains break when each hop issues fresh credentials without preserving the relationship to the originating user or task. In a healthy chain, downstream actions remain tied to the original authority context. In a broken chain, later steps may operate with broader permissions than the first request justified, which destroys auditability and weakens accountability. The technical failure is not only over-permissioning. It is the loss of provenance across hops, which makes it hard to prove whether a given action was authorized, inherited, or silently expanded.

Practical implication: require provenance-preserving delegation instead of credential reissuance at every hop.

Threat narrative

Attacker objective: The objective is to use legitimate agent authority to reach data, tools, or workflows that exceed the intended task boundary.

1. Entry occurs when an agent is granted legitimate runtime access to customer data, internal APIs, or cloud tools through OAuth scopes, shared credentials, or delegated tokens.
2. Escalation occurs when the agent accumulates broader permissions than the task requires, or when a downstream hop receives new authority that was never explicitly intended by the originator.
3. Impact occurs when the agent uses that expanded access to invoke tools, move across environments, or expose data in ways the security team cannot trace back cleanly to the original request.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic AI identity risk is a runtime governance problem, not an access review problem. Access reviews assume identities are stable enough to be certified after the fact. Agents make and complete decisions too quickly for that model to hold. The implication is that identity programmes must stop treating review cadence as the primary control surface for machine action.

Privilege drift is the named concept that best explains why agentic deployments fail first. Development teams expand scopes to prevent broken workflows, then reuse the same credentials across multiple agent paths. That creates a compounding exposure pattern that looks incremental in provisioning but behaves like cumulative overreach in production. Practitioners should read this as evidence that static roles are a poor fit for dynamic agent behaviour.

MCP bypass exposes a governance assumption that was designed for compliant access paths, not evasive ones. The assumption is that sanctioned tool routes will carry most high-value access. That assumption fails when an agent, or a developer building around it, can reach the same data through an alternate connector or web path. The implication is not simply more controls, but a recognition that path-based governance is brittle when the actor can choose routes at runtime.

Delegation chains are only meaningful if the original authority survives every hop. Many agent deployments create a false audit trail by reissuing credentials at each step instead of preserving provenance. That means the later action may be technically authenticated but no longer semantically tied to the original request. For identity governance, the chain itself becomes the control object, not just the credentials inside it.

Identity orchestration is becoming the control plane for agentic AI governance. When agents span LangChain, CrewAI, OpenAI, and cloud platforms, the field does not need another isolated policy layer. It needs a consistent enforcement point for identity, policy, and audit across all agent interactions. Practitioners should expect the market to consolidate around runtime identity orchestration rather than static entitlement management.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That same gap is why the OWASP Agentic Applications Top 10 is becoming a practical reference point for runtime control design.

What this signals

Privilege drift will become the default failure mode for agentic deployments unless identity teams change the control point. Enterprises are already discovering that static roles cannot keep pace with agents that chain tasks and expand access in real time. The next programme question is whether identity orchestration can move from periodic governance to continuous enforcement without blocking business workflows.

Runtime provenance is the concept that should anchor the next wave of agent governance design. If the organisation cannot prove which human, policy, and task created an agent action, it will struggle to satisfy audit, legal, and incident response demands later. That is why security leaders should pair AI agent governance with the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 rather than treating this as a pure IAM extension.

With 52% of companies able to track and audit the data their AI agents access, the remainder are operating with a visibility gap that will become more costly as agent counts rise. For identity programmes, that means the audit problem is no longer after-the-fact reporting. It is the operational prerequisite for safe scale.

For practitioners

• Map every agent path to a distinct identity Assign each AI agent a separate, verifiable identity and stop using shared service accounts or hardcoded API keys for production workflows. Track which user, task, and policy chain created the identity so you can distinguish legitimate delegation from hidden reuse.
• Move access decisions to runtime enforcement Evaluate authorisation at the moment an agent invokes a tool, not during periodic certification. Require the policy decision to consider originator context, task scope, target resource, and whether the delegation chain still matches the request.
• Put MCP behind a policy checkpoint Route every MCP request through an enforcement layer that validates identity and logs the call before the backend system sees it. This closes the bypass pattern where agents reach data through alternate connectors outside the sanctioned path.
• Preserve provenance across delegated hops Use token exchange and proof-of-possession patterns so each downstream action remains linked to the initiating subject. Do not reissue credentials in ways that erase the original delegation context or make later activity look more authorized than it is.
• Test governance with an agentic sandbox Exercise privilege drift, shadow-agent behaviour, and tool-routing bypasses in a controlled environment before production rollout. Validate whether your current controls still hold when the agent changes tools or expands scope mid-session.

Key takeaways

• AI agents are not just another workload. They are runtime identities whose decisions can exceed the assumptions behind static IAM and periodic review.
• The evidence already shows widespread scope overreach, with 80% of organisations reporting agent behaviour beyond intended boundaries.
• Runtime enforcement, provenance-preserving delegation, and MCP checkpointing are the controls that matter when identity becomes dynamic.

Key terms

• Agentic AI identity: The identity assigned to an AI system that can choose actions, tools, and timing during execution. In governance terms, it must be treated as a runtime subject with its own scope, audit trail, and revocation path, not as a human proxy or a simple service account.
• Privilege drift: The gradual or rapid expansion of access beyond what a task actually requires. For AI agents, drift can happen within a single session as scopes are reused, chained, or widened to keep workflows working, which makes static role design a weak control model.
• Delegation chain: The sequence that links an initiating user or system to downstream actions taken by an agent or another service. In agentic environments, the chain must preserve provenance so each action remains attributable to the original authority context, not just a later credential handoff.
• MCP governance: The set of identity, authorization, and logging controls applied to Model Context Protocol traffic. It ensures tool access is checked before the request reaches the backend system and that the resulting activity can be audited as part of the agent's broader authority boundary.

Deepen your knowledge

Agentic AI identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to apply runtime controls to agent access, this course is a practical starting point.

This post draws on content published by Strata Identity: agentic AI governance and identity orchestration for AI agents. Read the original.