The defining line in this field: the threat is not what the agent says. It is what the agent does.
Content filters, toxicity scanners, and output guardrails were built for a model that receives input and produces text. An agent has goals, credentials, tools, memory, and the autonomy to chain actions across systems. The damage arrives through the tools it invokes and the systems it reaches, and a scanner watching the output never sees the tool call.
That gap is what AI agent security addresses. Here is the threat landscape, the architectural reason it is hard, and what actually works.
Two Different Problems
OWASP now maintains separate lists, and the split is instructive.
The Top 10 for LLM Applications covers model-level risks — prompt injection, training data poisoning, output handling. It treats the model as something that takes input and returns output.
The Top 10 for Agentic Applications, published in 2026, covers what happens once the model becomes an actor. Different risks, because the failure modes only exist when the system can act.
Notably, the 2026 revision of the LLM list moved Excessive Agency up to third place, on the reasoning that agentic deployments are where damage is now landing. System Prompt Leakage was broadened and renamed to Hidden Context Exposure, and Unbounded Consumption rose four positions.
The Architectural Root Cause
Prompt injection maps to six of the ten agentic risk categories. Understanding why it is so pervasive matters more than memorising the list.
Large language models process the system prompt, the user’s request, and any text retrieved from external sources as a single stream of tokens. There is no reliable mechanism to mark some tokens as commands and others as inert data.
The consequence: hostile text placed in a document, a calendar invite, a web page, or a retrieved record can carry the same authority as an instruction from the operator. The agent has no principled way to tell them apart.
This is architectural rather than a defect to be patched. Any defence is therefore mitigation and containment, not elimination — which is why the industry framing that prompt injection is “the new SQL injection, and guardrails aren’t enough” has gained traction.
The OWASP Agentic Top 10
| ID | Risk | What it means |
|---|---|---|
| ASI01 | Agent Goal Hijack | An attacker redirects the agent’s objective, compromising the whole action chain |
| ASI02 | Tool Misuse & Exploitation | The agent is manipulated into the wrong function, wrong parameters, or an unauthorised action |
| ASI03 | Identity & Privilege Abuse | Over-broad or inherited credentials exploited through the agent |
| ASI04 | Agentic Supply Chain | Compromised frameworks, packages, skills, or tool interfaces |
| ASI05 | Unexpected Code Execution | The agent executes code it should not |
| ASI06 | Memory & Context Poisoning | Persistent corruption of what the agent believes |
| ASI07 | Insecure Inter-Agent Communication | Messages between agents treated as trusted |
| ASI08 | Cascading Failures | One compromised agent propagating errors through a workflow |
| ASI09 | Human-Agent Trust Exploitation | Operators approving actions they have stopped scrutinising |
| ASI10 | Rogue Agents | Agents operating outside intended scope or oversight |
ASI01 sits at the top for a structural reason: goal hijacking does not corrupt one output, it corrupts every subsequent action in the plan.
ASI06 deserves particular attention because it persists. An agent that absorbs a malicious instruction into memory can continue acting on it long after the originating input is gone.
What the Incident Data Shows
Three findings from the 2026 reporting worth carrying into your own risk assessment.
Coding agents dominate. Of 53 agentic projects tracked by OWASP’s surveying effort, 28 are coding agents, and they generate most of the new attack data. If you deploy agents that write or execute code, you are in the highest-risk category.
Containment can be inverted. A disclosed vulnerability against a major coding tool showed that an allowlist of permitted commands could itself become the attack vector — the auto-approval of “safe” commands removed the friction an attacker would otherwise have faced. Another showed an agent’s own output could redefine its sandbox boundary.
The defensive lesson generalises: a control that automatically approves anything creates a target. Allowlists reduce friction for legitimate operation and for anything that manages to look legitimate.
Supply chain is real, not theoretical. Security research identified dozens of agent framework components carrying embedded supply chain vulnerabilities, and broader breach reporting shows supply chain compromise rising sharply as a vector.
The Finding That Should Change Your Testing
The most important published result in this area concerns how defences behave under persistence.
Testing of indirect prompt injection in agentic coding environments, published in a frontier model system card, found attack success rates rising from roughly 5% at one attempt, to around a third at ten attempts, to over 60% at a hundred attempts.
Read that carefully. Defences that look strong against a single attempt degrade substantially against a determined attacker who simply keeps trying.
The practical implication: “we tested it and it held” is not evidence of safety. Single-shot red teaming produces a misleadingly reassuring number. Test with repeated attempts, and design assuming that a sufficiently persistent attacker eventually gets through — which means the question becomes what they can reach when they do.
Five Control Families
Current best practice organises defence into five layers across the agent lifecycle.
1. Constrain goals and distrust retrieved content. Treat everything the agent reads from external sources as untrusted data rather than potential instruction. Narrow objectives are harder to hijack than broad ones.
2. Per-agent identity with short-lived credentials. Distinct cryptographic identity per agent, ephemeral per-run credentials, no shared keys. This is where agent security and identity governance meet.
3. Supply chain provenance. Know what is in your agent stack — frameworks, packages, tools, skills, MCP servers — with an AI bill of materials and signed capability manifests.
4. Sandboxed execution with blast-radius isolation. Assume compromise and limit what a compromised agent can reach. This is the control that determines whether an incident is contained or systemic.
5. Continuous behavioural monitoring with kill switches. Watch what agents actually do, not just what they output. Tamper-proof logs for actions and inter-agent messages, with fast containment: revocation, sandboxing, termination.
The Principle of Least Agency
OWASP’s foundational defensive principle, and the agentic equivalent of least privilege.
Give an agent the minimum autonomy, tool access, and credential scope required for its task, and no more.
In practice that means scoping tools to the task rather than the system, avoiding write access where read access suffices, requiring human approval for irreversible or high-value actions, and separating agents by function rather than giving one agent everything it might conceivably need.
The gap between “what it needs” and “what it can reach” is your blast radius, and it is the single most controllable variable in the whole architecture.
Where Guardrails Fall Short
Worth being explicit, because many organisations believe this problem is already solved by tooling they have bought.
Content filters and PII scanners inspect text. They do not inspect tool calls. An agent can produce entirely innocuous output while invoking a tool with parameters it should never have been given, and an output-layer guardrail will report nothing.
Agent security requires runtime controls at the action layer — tool permissions, parameter validation, execution sandboxing, and system prompt protection — not only at the text layer.
Test It, Because Most Organisations Do Not
Reporting suggests fewer than 40% of organisations conduct regular security testing on AI agent workflows, which is a striking figure for systems holding live credentials.
A minimum programme:
- Adversarial testing with repeated attempts, not single-shot
- Tool-call evaluation covering selection, argument extraction, result use, and error recovery — most testing grades only the first
- Indirect injection scenarios through documents, retrieved content, and inter-agent messages
- Containment verification — confirm the sandbox and kill switch work under realistic conditions
- Supply chain review on a defined cadence
Final Thoughts
AI agent security is not LLM security with more steps. It is the security of a system that holds credentials, calls tools, retains memory, and acts across services with delegated authority.
The root problem is architectural and will not be patched away. What you control is scope, isolation, and observability — how little an agent can reach, how far a compromise spreads, and how quickly you notice.
Start with least agency and blast-radius isolation. Those two do more than any filter you can put in front of the model.