AI agent identity risk is outpacing enterprise IAM controls

At a glance

What this is: This is an analysis of how AI agents have crossed from advisory use into autonomous action, with the key finding that traditional security controls cannot reliably govern reasoning-driven execution.

Why it matters: It matters because IAM, PAM, and NHI programmes now need to govern actors that retrieve, combine, and act across systems without the stable boundaries those controls were built around.

By the numbers:

• Gartner estimates that by 2028, 15% of day-to-day work decisions will be made autonomously by agentic AI.
• As of today, 14% of organizations have already deployed autonomous agents into live production environments.
• 67% year-over-year as organizations moved from pilots to, as organizations moved from pilots to production.
• Only 4% of organizations rate their AI security confidence at the highest level, despite widespread adoption.

👉 Read Lakera's analysis of AI agent identity risk and execution-layer security

Context

AI agent identity risk now sits at the point where software is no longer only answering questions but initiating actions. That matters for AI agent identity risk because the control problem is no longer just who can sign in, but what the system can retrieve, decide, and execute once it is connected to enterprise data and tooling.

The gap is structural. Traditional IAM and NHI models assume a request, a boundary, and a reviewable action trail. Agentic systems collapse those assumptions by assembling context at runtime, selecting tools dynamically, and triggering workflows across multiple systems in one decision path.

Key questions

Q: What breaks when AI agents are governed like normal application accounts?

A: Normal application-account governance assumes the actor has stable intent, stable tool use, and a reviewable privilege window. AI agents can change tools and execute actions inside one session, so account-centric controls miss the real decision point. Teams need action-scoped governance, not just identity-scoped access management.

Q: Why do AI agents complicate least privilege?

A: Least privilege is usually defined at provisioning time, but agent intent is assembled at runtime from prompts, context, and tool selection. That makes the needed privilege set dynamic, not fixed. Security teams should treat the agent's reachable actions, not just its assigned account, as the privilege boundary.

Q: How do security teams know if an AI agent is exceeding its intended scope?

A: Look for tool calls that extend beyond the original user request, unexpected access to internal documents, or actions that chain across systems without a separate approval step. The most useful signal is not raw volume but mismatch between the stated task and the resulting execution path.

Q: Who is accountable when an AI agent performs an unauthorized action?

A: Accountability sits with the programme that granted the agent access, defined the policy boundary, and approved the integration. If ownership is split across product, security, and platform teams, gaps appear in logging, review, and rollback. Clear ownership is the only way to assign responsibility when autonomy blurs the operator chain.

Technical breakdown

Why agentic AI breaks request-based security models

Classic security controls are built around discrete requests: a user authenticates, an API call is authorised, and the action is logged. Agentic AI breaks that sequence because intent is inferred inside the model, then translated into tool calls and data retrieval across several systems. The security-relevant decision is no longer visible as one clean transaction. Instead, the risk is distributed across prompt, context assembly, tool selection, and execution. That makes boundary-based inspection incomplete, because each individual step can look valid while the combined behaviour is not authorised.

Practical implication: security teams need controls that evaluate the whole agent workflow, not just the individual API call.

Model Context Protocol and the execution layer

Model Context Protocol standardises how AI systems discover tools and data sources, which makes integration easier but also concentrates risk at the execution boundary. In practical terms, MCP becomes the junction where reasoning turns into action. If that junction is not governed, the system can reach internal knowledge, third-party services, and operational tools with a consistency that outpaces legacy approval models. The architectural issue is not that MCP is inherently unsafe. The issue is that a standard interface can become a high-trust corridor if authorisation, logging, and policy enforcement are not tied to the action itself.

Practical implication: enforce policy and telemetry at the tool-access layer, not only at the model or application layer.

AI Defense Plane and layered exposure surfaces

A layered AI security model reflects three distinct exposure surfaces: employees using AI tools, AI-powered applications, and autonomous agents. These surfaces do not fail in the same way, so one control plane cannot treat them identically. The useful insight is that telemetry from one layer should inform enforcement in another, especially when prompt injection, jailbreak attempts, or unintended data disclosure cross from chat interfaces into live systems. That is a governance model for systems that think and act, not just systems that route traffic.

Practical implication: segment controls by exposure surface and correlate signals across user, application, and agent layers.

Threat narrative

Attacker objective: The attacker seeks to induce an AI system to reveal sensitive information or perform unauthorized actions while each individual step still looks permitted.

1. entry: A user prompt or retrieved document introduces unstructured context that appears legitimate but influences the agent's internal decision path.
2. credential_harvested: The agent gains access to internal data, APIs, or workflow tools through a valid integration rather than a classic compromise.
3. escalation: Dynamic tool use expands the session's reach, allowing actions across multiple enterprise systems without a single explicit approval boundary.
4. impact: The agent modifies records, discloses sensitive data, or triggers workflow changes that are technically valid but operationally unauthorized.

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

Access review processes were designed for actors whose privileges persist long enough to be observed. That assumption fails when the actor is autonomous because access can be acquired, used, and discarded within a single session. The implication is not a new control, but a broken governance premise: review cadences no longer guarantee a reviewable state. Autonomous systems change the timing of privilege in a way human IAM and conventional NHI governance do not expect. If the actor can choose tools and act without approval gates, the old audit window closes before recertification starts. Practitioners need to recognise the collapsed assumption before they build around it.

AI agent identity is becoming an execution problem, not just an authentication problem. The article's central shift is from asking whether the system can log in to asking what it can do after it has access. That pushes governance toward action-scoped policy, tool-level authorisation, and correlated telemetry across context, data, and workflow layers. Practitioners should treat agent identity as an operational control plane, not a feature of the login stack.

Model Context Protocol creates an identity and access choke point for agentic systems. Standardisation improves interoperability, but it also creates a single place where trust can be overextended if authorisation is not tied to each tool call. This is where OWASP-AGENTIC and OWASP-NHI overlap in practice: the same integration that makes agents useful can also make overreach easier to miss. Practitioners should map every MCP-connected tool to a named owner, a policy boundary, and a log source.

AI Defense Plane thinking is strongest when it connects human use, application behaviour, and autonomous execution. Security teams often split those concerns into separate programmes, but the attack paths now cross between them. A prompt entered by a human can influence an application, which then hands control to an agent that acts in production. Practitioners should align IAM, NHI, and AI governance under one operating model rather than three disconnected reviews.

Runtime intent is the named concept security teams need to internalise. In agentic systems, intent is not fully known at provisioning time and can shift as the model assembles context and selects actions. That means least privilege defined only at onboarding is incomplete. Practitioners should reframe governance around observable runtime intent rather than static assumptions about what the system was meant to do.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Agentic AI extends that visibility problem into execution, which is why practitioners should also examine the Ultimate Guide to NHIs , Key Challenges and Risks for the governance gaps behind over-privilege and unmanaged access.

What this signals

Runtime intent is now the programme-level control problem. Once agents can retrieve data and trigger workflows, the question for security leaders is no longer whether AI is in use, but whether the organisation can see the full path from instruction to action. The practical shift is toward correlating prompts, tool calls, and outputs as one governance record, not three separate logs.

The security model should increasingly align with OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 thinking, because agent behaviour now blends identity, access, and operational risk. The teams that will move fastest are the ones that treat AI agents as governed actors with named owners and bounded execution paths.

With only 4% of organisations rating their AI security confidence at the highest level, the market signal is clear: adoption is outrunning governance. That should push practitioners to prioritise inventory, policy boundaries, and incident investigation paths before scaling agent deployment further.

For practitioners

• Define tool-level authorisation for every agent Assign explicit permissions to each API, database, and workflow tool an agent can reach. Do not rely on broad application access or inherited user entitlements when the system can decide which tool to call at runtime.
• Map approval boundaries to the action itself Require a policy decision at the point of execution for high-impact actions such as record changes, external messages, and workflow triggers. If the action cannot be separately approved, it is too broad for autonomous use.
• Correlate agent telemetry across context and output Collect logs for prompts, retrieved documents, tool calls, and outputs in one investigative path. Separate logs make agent behaviour look harmless when the real risk emerges only after the full sequence is reconstructed.
• Assign ownership to every agent-connected integration Name the business owner, security owner, and technical owner for each integration the agent can use. Unowned integrations become shadow AI pathways, especially when agent behaviour changes faster than governance reviews.
• Test for scope drift in live workflows Run scenarios where an agent receives ambiguous instructions, competing context, or a partially trusted document. Watch whether it expands beyond the intended task and then restrict the most permissive pathways first.

Key takeaways

• AI agents create a governance problem that traditional IAM and NHI controls cannot solve by themselves.
• The evidence points to fast adoption, weak confidence, and rising incident volume, which makes runtime control a present-day requirement.
• Practitioners should govern agent action paths, not just agent logins, if they want meaningful control over autonomous behaviour.

Key terms

• Agentic AI identity: An identity model for AI systems that can select actions, tools, and timing during runtime. It is more than authentication or access control because the security question becomes what the system is allowed to do once it is connected to data and workflows, not simply whether it can sign in.
• Runtime intent: The effective purpose an AI system is pursuing at the moment it acts, assembled from prompts, context, instructions, and tool selection. Unlike static policy intent, runtime intent can shift during a session, which means governance must evaluate observable behaviour rather than only the original request.
• Execution layer: The part of an AI system where reasoning becomes action through APIs, tools, databases, and workflow automation. This is where security decisions fail most often because traditional controls are designed for visible requests, while execution layers may perform several valid steps that produce an unauthorised outcome.
• Model Context Protocol: A standard interface that lets AI agents discover and use tools and data sources. It improves interoperability, but it also creates a concentrated trust boundary, so the security problem shifts to controlling each tool call, logging each action, and limiting what the agent can reach at runtime.

What's in the full article

Lakera's full article covers the operational detail this post intentionally leaves for the source:

• The article maps the three AI exposure surfaces in more detail, including how each one changes the control design.
• It expands on the agentic threat landscape diagram and the sequence from prompt to tool use to output.
• It explains the AI Defense Plane concept with more implementation context for teams building layered controls.
• It points to real-world examples from Dropbox and Nubank that show how the framework is being applied in practice.

👉 Lakera's full article covers the threat landscape, execution-layer risks, and the AI Defense Plane framework in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.