Agentic AI security in 2026: why current controls fall short

At a glance

What this is: Agentic AI behaves as a non-human identity with runtime decision-making, tool access, memory, and execution paths that make legacy application controls insufficient.

Why it matters: IAM, NHI, and human identity programmes all need to account for agents that can change actions mid-session, because governance breaks when identity no longer behaves predictably.

By the numbers:

• 97% of security leaders expect a material AI-agent-driven security incident this year, with only 6% of security budgets currently allocated to this risk.
• More than 80% of technical teams have already moved past planning into active testing or production deployments.
• Only 14% of those agents are going live with full security and IT approval according to Gravitee.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Lasso Security's guide to securing agentic AI in the enterprise

Context

Agentic AI is software that can plan, decide, and act without a human reviewing every step. That matters for identity security because the same agent can change its behaviour based on memory, tools, and session context, which makes static access assumptions unreliable. In practice, this is a non-human identity problem, but one with autonomous characteristics that force IAM teams to think beyond conventional application controls.

Enterprises are deploying agents through engineering, operations, and low-code business tooling at the same time, often without a consistent security review model. The result is an identity layer that can accumulate tool access, data reach, and execution authority faster than governance can map it. For teams already managing service accounts, APIs, and secrets, agentic AI adds another class of non-human actor that can initiate actions rather than simply respond to them.

Key questions

Q: How should security teams implement least privilege for agentic AI systems?

A: Security teams should scope each agent to a dedicated identity, a narrow tool allowlist, and time-bounded credentials that expire with the task. The important shift is from user-style permissioning to runtime task scoping. If an agent can read, write, and execute across multiple systems under one identity, a single manipulation can create broad blast radius.

Q: Why do agentic AI systems complicate zero trust and IAM models?

A: Agentic systems complicate zero trust because they do not behave like stable applications with fixed request patterns. They can change actions mid-session, chain tools, and reuse context in ways that make one-time access decisions insufficient. IAM teams need to govern the sequence of actions, not just the initial authentication event.

Q: What breaks when agent behaviour is monitored only through standard logs?

A: Standard logs usually capture individual events, but they do not show whether the full action chain was safe. That means an agent can take several authorised steps that together create an unsafe outcome without triggering a clear alert. Behavioural baselines and sequence tracing are necessary to spot scope drift.

Q: Who is accountable when an AI agent causes an unauthorised action?

A: Accountability should sit with the system owner and the governance process that granted the agent its access, not with the agent itself. If the workflow has no owner, no approval path, and no recorded scope, responsibility becomes diffuse very quickly. Organisations need named ownership for agent identities before production use.

Technical breakdown

Task boundaries and policy enforcement for agentic AI

Agentic systems become risky when task scope exists only in prompts. Policy must define which tools an agent can invoke, which systems it can write to, and when it must stop and escalate. The technical distinction is important: a prompt is advisory, while infrastructure and authorization layers can enforce constraints. In multi-agent environments, those constraints also need to be consistent across agents because a single loosely governed node can widen the attack surface for the rest of the workflow.

Practical implication: define task boundaries in enforceable policy, not natural-language instructions.

Least-privilege access for tools, data, and memory

Agents inherit the permissions of the identities they operate under, so the access model must reflect the task, not the platform. Dedicated service identities, allowlisted tool access, and time-bounded tokens reduce the chance that a manipulated agent can turn ordinary runtime access into broad system reach. Memory is part of the problem too, because an agent that retains credentials or sensitive context can later reuse them in a different sequence of actions. That makes identity scope and memory lifecycle inseparable.

Practical implication: scope each agent to specific tools, data sources, and short-lived credentials.

Runtime monitoring, prompt isolation, and output validation

Standard application monitoring does not capture how an agent chains decisions across multiple calls. Effective detection requires tracing tool order, inputs, outputs, and deviation from the normal behaviour for that specific agent role. Real-time prompt and data-flow controls also matter because malicious instructions can arrive through content the agent trusts. Output validation adds a final checkpoint before the agent acts on tool results, which closes a common path from poisoned input to legitimate-looking action.

Practical implication: monitor behaviour in-session and validate outputs before downstream actions execute.

Threat narrative

Attacker objective: The attacker wants to turn a legitimate agent identity into a credentialed proxy that can access data, trigger actions, and extend compromise across connected systems.

1. Entry occurs when an attacker plants malicious instructions in content the agent is designed to retrieve and trust, such as a document, web page, or tool response.
2. Credential access and abuse happen when the agent runs under a broadly scoped identity, making its authorised tokens and API access usable as a proxy for the attacker.
3. Escalation follows when manipulated tool calls and multi-agent delegation extend the attack beyond the original task scope into other systems and data sources.
4. Impact lands as unauthorised data access, unauthorized transactions, or other irreversible actions that the organisation may only reconstruct after the session has already completed.

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 is not just another NHI class. It collapses the assumption that access can be provisioned once and safely reviewed later. Identity controls for service accounts were designed for stable behaviour and predictable request patterns. That assumption fails when the actor can choose tools, reorder actions, and change behaviour mid-session. The implication is that governance has to be rethought around runtime intent, not just entitlement state.

Task boundaries become a governance control only when they are enforced outside the prompt. The article is right to treat prompt instructions as insufficient, because agentic systems can misread, ignore, or be manipulated through context. That makes policy, authorization, and tool access the real control plane. Practitioners should treat natural-language scope statements as guidance and enforcement as an infrastructure problem.

Identity blast radius is the right named concept for agentic AI risk: one agent identity can bridge CRM, code, databases, and external APIs in a single reasoning chain. The more systems an agent can touch, the more a small scope error becomes a cross-system incident. This is where NHI governance and Zero Trust converge, because the question is no longer whether the identity is authenticated, but how far its authenticated actions can propagate.

Behavioural monitoring must move from logging actions to understanding action sequences. A single tool call may look legitimate, but a sequence of allowed actions can still produce an unsafe result. That is why agent governance needs baseline behaviour, per-role deviation detection, and review processes for newly connected tools. Without that, organisations only discover drift after damage has already occurred.

Multi-agent workflows create trust seams that conventional IAM does not model well. A compromised subagent can pass manipulated output upstream and trigger valid actions in another agent without an obvious perimeter event. This is a delegation problem as much as a security problem, and it affects both NHI and autonomous governance. Practitioners need to map where trust is inherited, not just where access is granted.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope, which means scope creep is already operational rather than theoretical.
• That is why OWASP Agentic AI Top 10 should sit alongside runtime monitoring when teams move from discovery to control design.

What this signals

The immediate signal for practitioners is that agent governance cannot stay inside the application-security lane. Once an agent can combine memory, tools, and delegated action, the control problem spans IAM, PAM, data protection, and workflow ownership. Teams should expect more pressure to inventory non-human actors as identities, not just as workloads.

Identity blast radius: the article sharpens a useful way to think about agentic AI risk. A single agent can connect multiple systems and amplify one scope error into a cross-domain event, which means security teams need to map where trust propagates across agent workflows. That is one reason the Ultimate Guide to NHIs remains relevant for organisations now extending identity governance into AI.

With 33% of organisations already seeing agents access data beyond intended scope, the governance issue is no longer confined to pilot environments. Security leaders should prepare for agent inventories, runtime policy enforcement, and owner assignment to become routine assurance checks, much like access reviews are for other non-human identities.

For practitioners

• Define enforceable agent task boundaries Write policy that specifies allowed tools, writable systems, and escalation triggers for each agent role. Treat the prompt as guidance only and enforce boundaries at the authorization and runtime control layers.
• Issue dedicated identities per agent role Replace shared credentials with dedicated service identities, scoped allowlists, and time-bounded tokens for sensitive operations. Keep each agent's permissions narrow enough that a manipulated task cannot become a general-purpose proxy.
• Inventory shadow agents and unapproved workflows Build a register of agents created through engineering, low-code platforms, and third-party integrations, then map each one to its tools, data sources, and owners. Any agent without an owner or review trail should be treated as unmanaged identity.
• Monitor for sequence-level behavioural drift Baseline the normal order of tool calls, data access, and output volume for each agent, then alert on deviations that suggest scope drift or prompt manipulation. Sequence-based telemetry is more useful than single-event logging for agentic systems.
• Validate outputs before downstream action Insert a runtime check between agent output and any irreversible action, especially when the next step touches payments, customer records, or code execution. Validation should stop manipulated outputs before they become authoritative tool calls.

Key takeaways

• Agentic AI is an identity governance problem because agents can choose tools, change actions mid-session, and operate beyond static access assumptions.
• The evidence already points to widespread exposure, with security leaders expecting incidents while budgets and policy coverage lag behind adoption.
• Practitioners should move from prompt-based guidance to enforceable identity, runtime, and behavioural controls before agent workflows spread further.

Key terms

• Agentic AI: Software that can plan, choose actions, and execute steps inside an environment with limited human intervention. In identity terms, it behaves like a non-human actor with runtime decision-making, which means access, audit, and control models must account for changing behaviour rather than fixed workflows.
• Identity blast radius: The amount of damage one identity can cause if it is manipulated, over-permissioned, or mis-scoped. For agentic systems, blast radius includes the tools, data, and downstream systems an agent can reach in one reasoning chain, making containment a first-class governance concern.
• Task boundary: The operational limit placed on what an agent is allowed to do, which systems it may touch, and when it must escalate or stop. Unlike a prompt, a task boundary is only meaningful when it is enforced by policy, authorization, or runtime controls.
• Sequence-level monitoring: Monitoring that evaluates the order and combination of actions an identity takes, not just isolated events. This matters for agents because individually valid tool calls can still form an unsafe chain, especially when memory, context, and delegated actions are involved.

Deepen your knowledge

Agentic AI security and runtime governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is extending identity controls from service accounts into AI agents, it is worth exploring.

This post draws on content published by Lasso Security: How to Secure Agentic AI in the Enterprise: Best Practices for 2026. Read the original.