OWASP’s Q2 2026 landscapes split agentic AI from LLM security

At a glance

What this is: OWASP’s Q2 2026 update splits agentic AI, LLM and GenAI applications, and red teaming into separate landscapes, signalling that these systems need different security controls.

Why it matters: IAM, NHI, and AI security teams need to treat agentic workflows as a distinct control plane because runtime tool use, memory, and delegated actions create governance gaps that model-only protections do not cover.

Context

OWASP’s Q2 2026 update is really about control boundaries, not taxonomy. Once an AI system can call tools, keep memory across sessions, and make runtime decisions, the security problem changes from protecting prompts and outputs to governing actions, privileges, and downstream reach.

That distinction matters for IAM and NHI programmes because agentic systems behave like a new class of non-human actor. If the control model still assumes a person reviews each action, the governance model will miss how access is requested, delegated, and exercised inside a single workflow.

Key questions

Q: What breaks when agentic AI is governed like a standard LLM application?

A: The control model breaks because LLM governance assumes the main risk is what the model says, while agentic systems create risk through what the model does. Once an agent can call tools, pass context, and act across sessions, the security boundary shifts to runtime decisions, delegated access, and downstream system reach.

Q: Why do agentic AI systems require continuous red teaming?

A: Agentic systems change when models are retrained, prompts are updated, retrieval sources shift, or new integrations are added. Those changes can reopen vulnerabilities even if the model was previously tested. Continuous red teaming is how teams detect drift, validate fixes, and keep security evidence aligned to the current system state.

Q: What are the signs that an agentic security programme is too close to GenAI-only governance?

A: The clearest sign is when controls focus only on prompt content, model outputs, or pre-release evaluations while ignoring tool permissions, memory scope, and delegation paths. That usually means the programme is testing the model in isolation rather than governing the agent as an acting system.

Q: How do IAM and NHI teams govern agent access across the request chain?

A: They should treat the human identity, the agent session, and the downstream tool as one governed path with shared lifecycle rules. That means role changes, revocation, logging, and recertification must reach the agent-mediated access point at the same time they reach the primary identity record.

Technical breakdown

Why agentic AI needs a different security boundary

An agentic system is not just an LLM with a wrapper. It can call APIs, read and write files, pass context to other agents, and decide when to act without human review at each step. That means the relevant security boundary is no longer the model input and output. It is the full execution path, including tools, memory, orchestration, and the systems the agent can reach. Traditional guardrails mostly assess text before or after generation, so they miss risks that appear only when a model takes action in a live environment.

Practical implication: Treat agentic workflows as governed execution paths and not as prompt-response systems.

How multi-agent orchestration expands the attack surface

When one agent delegates to another, the trust boundary moves from a single model to a chain of agents and protocols such as MCP or A2A. A compromised instruction in one node can be inherited downstream, which makes reasoning lineage and context provenance as important as authentication. This is where agentic risk starts to resemble NHI governance: one identity may trigger multiple delegated actions across systems, but the security decision must still be traceable across each hop. Static prompt checks do not reveal that propagation pattern.

Practical implication: Track delegation paths and scope hand-offs across agents before approving multi-agent production use.

Why continuous red teaming is now part of the control stack

The article’s red teaming point is that agentic systems change after release because tools, prompts, knowledge bases, and downstream dependencies keep moving. That makes quarterly testing too slow for a target whose behaviour can drift between deployments. Continuous adversarial simulation is therefore less about a one-time assessment and more about re-testing the current behavioural state. For teams, that shifts assurance from code diff alone to behaviour diff, which is a better fit for systems whose risk comes from runtime decision-making rather than fixed application logic.

Practical implication: Build red teaming into ongoing operations so behavioural drift is detected after change, not after compromise.

Threat narrative

Attacker objective: The attacker’s objective is to turn a trusted agentic workflow into a delegated execution path that can reach systems, data, or actions beyond its intended scope.

1. Entry occurs when an agent receives a prompt or task that leads it to invoke tools or share context across systems without a human reviewing each step.
2. Credential or authority abuse follows when the agent uses delegated access, runtime tool permissions, or cross-agent trust to reach systems beyond the original prompt boundary.
3. Impact emerges when that delegated execution produces unintended file changes, API actions, data exposure, or persistence across sessions and downstream agents.

Breaches seen in the wild

• Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic AI governance now has to start at the decision layer, not the model layer. Once a system can invoke tools, move context, and act across sessions, classic prompt guardrails stop being the primary control. The real issue is whether the organisation can govern the actions an agent takes after inference. That is why agentic AI cannot be folded into a generic GenAI policy without losing the actual risk boundary. Practitioners should treat decision authority as the new control point.

OWASP’s split is a signal that LLM security and agentic security are not interchangeable disciplines. LLM security is still about constraining content, outputs, and model-facing abuse. Agentic security adds orchestration, memory scope, tool governance, and downstream trust propagation. For IAM and NHI teams, that distinction matters because an agent’s access is operational, not just informational. The right governance question is who or what can act, with what scope, and under which runtime conditions.

Memory and tool scope are the new blast-radius controls for agentic systems. The article is right to highlight that behaviour can drift without a code change. That means the most important governance failures are not always visible in source control or release management. They emerge in runtime permissions, external tool dependencies, and knowledge updates that alter action paths. Practitioners should assume the attack surface is dynamic and that security controls must watch execution, not only deployment.

Red teaming should be treated as a live assurance function, not a pre-release ceremony. The article correctly notes that an agent today may not behave like the agent tested last month. That undermines any model where red teaming ends at launch. Continuous simulation, behaviour baselines, and post-change validation are now part of governance for autonomous systems. Security leaders should update assurance cadences to match the speed at which agentic systems change.

Named concept: behavioural drift detection. OWASP’s new landscape gives a precise term for a problem many teams still undercount. Agentic systems can change through prompt edits, tool swaps, and knowledge base updates without a traditional software release. That creates a governance gap between what was approved and what is now executing. Practitioners should build controls that measure behaviour change over time, not just code change at release.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Security Guide

What this signals

Behavioural drift is now the governance problem that matters most for agentic systems. Agents can change through prompt updates, tool substitutions, and knowledge base edits without a normal deployment signal, so security teams need runtime observation rather than release-only approval. The practical shift is toward controls that detect when an agent’s current behaviour no longer matches the behaviour that was signed off.

Agentic workflows should be treated as non-human actors with delegated authority. That framing matters for identity governance because the central question is no longer just authentication, but how much action authority a system can exercise on its own. In the current market, 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.

Continuous red teaming is becoming a control expectation, not an optional assurance layer. If the environment can change after launch, the testing model must change with it. For practitioners, that means architecture reviews should ask whether simulation, inventory, and runtime monitoring are operating as one assurance loop rather than as separate point controls.

For practitioners

• Define an agentic security boundary Separate agentic workflows from conventional GenAI use cases and document where runtime decisions, tool calls, and memory persistence begin.
• Inventory every agent, tool, and MCP server Create and maintain a complete list of agents, the tools they can invoke, and the servers or services they can reach.
• Move assurance into runtime monitoring Add controls that inspect execution behaviour, context scope, and tool use during operation rather than relying only on pre-release checks.
• Run continuous red teaming against live behaviour Use adversarial testing that revalidates agents after prompt changes, tool updates, knowledge base changes, and downstream orchestration changes.
• Restrict delegated access by task scope Limit how far an agent can act across systems so delegated authority expires with the task and does not become persistent reach.

Key takeaways

• Agentic AI changes the security boundary from model output to runtime action, which makes tool use, memory scope, and delegated execution the real governance problem.
• OWASP’s split between agentic AI and LLM security confirms that one control model no longer fits both attack surfaces.
• Security teams should move from release-only evaluation to continuous assurance because agent behaviour can change without a code deploy.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Behavioural Drift: Behavioural drift is the gradual change in what an identity does compared with what it was originally approved to do. For AI agents, drift can come from prompt changes, model updates, expanded integrations, or altered workflows, which makes access review alone an incomplete control.
• Agent Orchestration: Agent orchestration is the coordination of multiple AI agents or workflows to complete a task set with limited human intervention. In identity terms, it creates delegated execution paths that need ownership, scope limits, and auditability because work is no longer performed only by a person in one session.
• Runtime Tool Security: Runtime tool security is the protection of external tools, plugins, and services that an AI system invokes while it is executing. The key concern is that behaviour can change at runtime without a code change, so the control problem becomes tool trust, tool scope, and live monitoring.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management. It helps security practitioners align identity controls with the systems now taking action on their behalf.