The OWASP AI red teaming landscape and the new security stack

At a glance

What this is: OWASP’s latest agentic AI red teaming landscape reframes AI security around behavioural attack paths, continuous testing, and runtime governance.

Why it matters: IAM teams need to treat agent access, tool use, and policy enforcement as a continuous governance problem because agent behaviour can change after deployment.

By the numbers:

• 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Lasso Security's analysis of the OWASP AI red teaming landscape

Context

Agentic AI changes the security model because the identity is no longer just retrieving data or calling a single API. It is selecting tools, chaining decisions, and operating across trust boundaries in ways that make static application controls incomplete for AI agent governance.

The core problem for IAM and security teams is that behaviour becomes part of the attack surface. That means prompt injection, tool poisoning, memory manipulation, and privilege escalation inside agent chains have to be treated as governance failures, not merely model bugs.

For organisations extending identity controls into AI, this is the same class of problem that emerges when access is granted to a workload or service account that can act dynamically at runtime. The difference is that agentic systems can change what they do mid-session, which makes conventional review and validation cycles too slow for the risk model.

Key questions

Q: How should security teams govern AI agents that can use tools at runtime?

A: They should treat tool use as a privileged execution path and apply policy controls before the agent can complete an action, not after the response is generated. The governance model needs telemetry, approval boundaries, and runtime enforcement that match the speed of the agent’s decisions. Without that, the agent can cross trust boundaries faster than human review can react.

Q: Why do agentic AI systems create a different security problem from static applications?

A: Because the risk is behavioural, not only code-based. Agentic systems can change actions, sequence, and tool use based on live context, which means the attack surface includes decision-making and orchestration. Traditional app security can verify inputs and outputs, but it cannot fully govern what happens when the system starts choosing its own path through connected tools and data.

Q: How do organisations know if AI red teaming is actually reducing risk?

A: They should look for whether findings are linked to concrete runtime controls, whether tests can be repeated against the same abuse path, and whether the same issue is visible in monitoring, audit, and response workflows. If red team results do not change policy, telemetry, or enforcement, the programme is producing reports rather than risk reduction.

Q: What is the difference between testing AI models and governing AI agents?

A: Model testing focuses on prompts, outputs, and adversarial inputs, while agent governance focuses on the full action path, including tool calls, trust boundaries, and downstream effects. In practice, agents need continuous oversight because they can act across systems. That makes governance a runtime discipline, not a one-time validation exercise.

Technical breakdown

Behavioural attack surfaces in agentic AI

Agentic AI systems differ from static applications because they execute actions, call tools, and move across multiple control points. That makes the attack surface behavioural rather than purely code-based. Prompt injection can alter the model’s instructions, tool poisoning can reshape what an agent believes a tool does, and memory manipulation can influence later decisions. In multi-agent systems, one compromised agent can propagate malicious context to another, turning a local issue into an orchestration problem. The result is that the unit of security is no longer the prompt or the API call alone, but the decision path across the full agent lifecycle.

Practical implication: model and test the full agent decision path, not just the prompt boundary or model output.

Why runtime protections must sit in the execution path

Traditional pre-production testing cannot cover the full range of adversarial behaviours once an AI system is live. Runtime protection matters because agentic systems encounter new inputs, tools, and context after deployment, and those conditions can trigger failure states that were not visible in testing. An AI firewall, policy enforcement layer, or runtime proxy only helps if it can inspect the action before it completes, not after the fact. This is especially important where the agent can call external systems, retrieve data, or trigger downstream workflows that are hard to unwind once executed.

Practical implication: place controls where the agent executes, not only where it is tested.

Continuous red teaming for lifecycle-driven AI governance

OWASP’s lifecycle framing matters because it treats security as continuous rather than a pre-launch gate. That is the right model for agentic AI, where new tools, new context sources, and new orchestration patterns can create fresh abuse paths without any code change. Red teaming in this setting is not a one-time assessment. It is a loop that generates evidence for policy tuning, telemetry review, and governance decisions across planning, development, deployment, and monitoring. For identity teams, this aligns more closely with continuous access oversight than with classic application pen testing.

Practical implication: build repeated adversarial testing into the operating model, not a project milestone.

Threat narrative

Attacker objective: The attacker aims to turn legitimate agent permissions into unauthorized actions, data exposure, and workflow abuse at runtime.

1. Entry begins when an attacker manipulates the agent through prompt injection, a poisoned tool response, or malicious retrieval content that changes how the system interprets its next step.
2. Escalation follows when the agent uses legitimate permissions to call tools, chain decisions, or invoke connected systems in ways that expand the attacker’s reach across trust boundaries.
3. Impact occurs when the agent performs unauthorized data access, privilege escalation, or harmful downstream actions on behalf of the organisation without the intended oversight.

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

AI security has moved from output control to behavioural governance. The OWASP landscape captures a real shift: the risk is no longer only what the model says, but what the agent does when it can act across tools, memory, and workflows. That changes the identity question from prompt safety to execution-path assurance. Practitioners should treat agent behaviour as a governance object, not a secondary output problem.

Intent security is the right named concept for this category, because the failure is in the why, how, and what of agent action. When an AI agent can chain decisions across tools and contexts, conventional application controls no longer fully describe the attack surface. The important change is that attackers can steer intent, not just corrupt content. Security programmes should therefore measure whether the governance model can observe and constrain action sequencing, tool use, and runtime context together.

The lifecycle model only works if red teaming, monitoring, and enforcement share the same evidence stream. Fragmented tooling creates a false sense of validation because the thing that failed in testing is not the same thing that blocks action at runtime. OWASP’s framework is strongest where it forces continuity from planning to operation. Practitioners should use that continuity to reconcile testing findings with live controls, or the programme will remain reactive.

AI agent governance is now a cross-domain identity problem, not a model-only problem. Agentic systems behave like non-human identities with dynamic privileges, but they also create dependencies that traditional IAM review cycles were never built to inspect. That means the strongest programmes will connect NHI governance, zero trust assumptions, and AI risk oversight in one operating model. Security teams should expect agent identity to be governed more like an evolving workload than a static account.

The control gap is not just missing detection, it is missing decision-time containment. If a system can still complete harmful actions after detection, the governance model has already lost the timing race. This is why runtime enforcement, auditability, and escalation containment become central for agentic systems. Practitioners should assume that post-event review is necessary but insufficient when agents can act before humans can intervene.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, 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.
• Forward pivot: Read OWASP NHI Top 10 for the controls and abuse patterns that shape agentic AI governance.

What this signals

Intent security: the market is moving toward governance that inspects why an agent acts, not just whether the output looks safe. With 80% of current AI deployments already showing rogue behaviour, the operating assumption has shifted from rare abuse to expected drift. Teams that still rely on static review cycles will keep finding problems after the system has already acted.

NHI programmes should now treat AI agents as dynamic identities with runtime privileges, especially where tool access and external integrations are involved. The important signal is not deployment volume alone, but the widening gap between how quickly agents are added and how slowly control evidence is produced. That gap is where auditability, containment, and policy enforcement need to converge.

The governance lesson is broader than AI. Any identity that can change behaviour in session challenges the old model of fixed privilege plus periodic review. That is why security architecture, identity governance, and operational monitoring now need a shared control vocabulary, especially where agent decisions can trigger downstream business actions.

For practitioners

• Map agent decision paths end to end Document where each agent can select tools, chain actions, and cross trust boundaries so you can test the full execution path rather than only model outputs.
• Move enforcement into runtime Place policy enforcement, inspection, and blocking controls in the proxy or gateway layer so the agent cannot complete a risky action before the control evaluates it.
• Build continuous adversarial testing into operations Run repeated prompt injection, tool poisoning, and multi-turn abuse tests after deployment so red teaming remains aligned with live context changes.
• Tie governance evidence to one control plane Use a shared evidence stream for testing, telemetry, and audit so security, compliance, and identity teams can track the same failure from discovery to containment.

Key takeaways

• Agentic AI security is now a behavioural governance problem because attacks target decision paths, not just model outputs.
• The evidence from current deployments shows that rogue behaviour and blind spots are already common, so runtime controls matter now, not later.
• Teams that can connect red teaming, telemetry, and enforcement in one control loop will have a defensible model for AI agent access.

Key terms

• Agentic AI: AI systems that can select actions, call tools, and advance work with limited or no direct human prompting. In security governance, they must be treated as dynamic actors because their access patterns, execution paths, and downstream effects can change at runtime.
• Tool Poisoning: A manipulation technique where malicious instructions are embedded in tool responses, metadata, or connectors so an agent changes behaviour during execution. The risk is not only bad data, but bad action, because the agent may trust and act on the poisoned tool output immediately.
• Behavioral Attack Surface: The part of an AI system exposed through decisions, tool calls, memory, and orchestration rather than code alone. It matters because attackers can shape what the system does, not just what it says, which makes runtime governance a core security requirement.
• Intent Security: A governance approach that evaluates why an agent is acting, how it chooses actions, and what it is allowed to do across connected systems. It is especially relevant when agents can chain decisions across tools, because output review alone cannot control runtime intent.

Deepen your knowledge

Agentic AI governance and runtime control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to extend identity governance into AI agents and tool-using systems, this course provides the right starting point.

This post draws on content published by Lasso Security: The OWASP AI Red Teaming Landscape: Why Securing AI Requires a New Security Stack. Read the original.