Table of Contents
The security question changes fundamentally the moment an AI system can act rather than only answer.
A chatbot that gets something wrong produces a bad sentence. An agent that gets something wrong issues a refund, sends an email, updates a record or runs code, and it may do so repeatedly before anyone notices. The vulnerability class is not new; the blast radius is.
OWASP formalised the distinction in December 2025 with the Top 10 for Agentic Applications for 2026, the first framework aimed specifically at autonomous AI security, developed with over 100 security experts across more than a year of review. This guide covers what makes agent security different, the ten categories, why prompt injection is contained rather than solved, and the control stack to put in place before an agent touches production.
What Makes Agent Security Different
Four properties turn a manageable model risk into a security problem.
| Property | Why it changes the risk |
| Tool access | The agent holds credentials and can write to real systems |
| Autonomy over multiple steps | One bad decision propagates through subsequent steps before review |
| Persistent memory | A malicious input can influence behaviour long after it is processed |
| Delegation | Agents invoke other agents, so authority spreads beyond the original scope |
The single most useful reframing for a board conversation: with a chatbot you are managing output risk; with an agent you are managing action risk. Output risk is mitigated by review. Action risk is mitigated by permissions.
The OWASP Top 10 for Agentic Applications
Published 9 December 2025. Categories are cited as ASI01 to ASI10.
| ID | Category | What it looks like in practice |
| ASI01 | Agent Goal Hijack | Content the agent reads redirects its objective, without touching code |
| ASI02 | Tool Misuse | Legitimate tools invoked for illegitimate ends, or with unsafe parameters |
| ASI03 | Identity and Privilege Abuse | The agent’s credentials exceed the task, or are reused across contexts |
| ASI04 | Memory Poisoning | Injected content persists in memory and shapes later decisions |
| ASI05 | Unsafe Code Execution | Generated code runs without sandboxing |
| ASI06 | Supply Chain risks | Compromised models, tools, plugins or dependencies |
| ASI07 | Insufficient Observability | Actions are not logged in a way that permits reconstruction |
| ASI08 | Cascading Failures | One faulty output becomes the next agent’s trusted input |
| ASI09 | Human Manipulation | The agent is used as a trusted channel to influence a person |
| ASI10 | Rogue Agents | Agents operating outside intended scope or oversight |
Category names follow OWASP’s published taxonomy. Confirm exact wording against the current OWASP document before publishing, since the project revises between releases.
Three of these are worth dwelling on because they are the ones most often missed in design reviews: ASI04 memory poisoning, because the payload and the effect are separated in time; ASI07 insufficient observability, because it is the one that determines whether you can answer “what did it do” after an incident; and ASI08 cascading failures, because multi-agent systems trust each other’s output by default unless designed not to.
Why Prompt Injection Is Contained, Not Solved
This is the most important thing on the page, and the thing most frequently misrepresented in vendor material.
An agent reads untrusted content: a customer message, a web page, a document, an email. It cannot reliably distinguish instructions embedded in that content from instructions given by its operator, because both arrive as text in the same channel. There is no parser separating code from data the way there is in SQL.
That means prompt injection has no complete fix at the input layer. Filters and classifiers raise the cost of an attack and are worth deploying, but treating them as a solution is the error. Anyone selling injection detection as prevention is overstating what it does.
The defensible posture is to assume injection succeeds and design so that it does not matter much:
- The agent’s credentials are scoped so tightly that hijacking it grants little.
- Irreversible actions require human approval regardless of how confident the agent is.
- Actions are logged so an incident is reconstructable.
- A kill switch exists and has been tested.
That is containment, and it is achievable. Prevention is not.
The Control Stack
Apply in roughly this order. The earlier controls do more work than the later ones.
| # | Control | What it prevents |
| 1 | Scoped agent identity | The agent has its own identity, never a shared service account or a human’s credentials. Prevents ASI03 |
| 2 | Least-privilege tools | Each tool exposes the narrowest possible operation. Prevents ASI02 |
| 3 | Approval gates | Irreversible or high-value actions pause for a human. Limits ASI01 and ASI02 impact |
| 4 | Sandboxed execution | Generated code runs isolated, with no network or credential access by default. Prevents ASI05 |
| 5 | Hard limits | Caps on steps, spend, and actions per session. Limits runaway behaviour |
| 6 | Comprehensive logging | Every prompt, tool call, parameter and result, attributable and immutable. Prevents ASI07 |
| 7 | Memory hygiene | Memory writes validated and scoped; ability to purge. Prevents ASI04 |
| 8 | Tested kill switch | Ability to stop all agent activity immediately, rehearsed. Bounds every category |
Identity is the control that carries the most weight, and the one most often skipped because it is unglamorous. An agent operating under a shared service account is indistinguishable in logs from every other process using it, which means you cannot attribute an action, revoke access narrowly, or scope permissions to the task. Fix identity before anything else on this list.
The kill switch must be tested. An untested kill switch is a design intention. Rehearse it, on a schedule, the way you would a backup restore.
Agent Identity and Access
Three questions decide whether your permission model holds.
Whose authority is the agent acting under? If it inherits the requesting user’s permissions, it can do anything that user can, which is usually far more than the task needs. If it has its own identity with its own narrow grants, the blast radius is bounded by design.
Is authority scoped per task or per session? An agent that holds refund permissions for an entire session can issue refunds long after the refund task ended. Per-task scoping, issued and revoked around the specific action, is materially safer.
What happens at delegation? When one agent invokes another, authority should narrow rather than persist. Systems where delegation preserves full privilege are how a limited compromise becomes a general one.
Multi-Agent Systems Multiply the Problem
Every property that makes agent security hard gets worse when agents talk to each other.
Agents trust each other’s output by default, so a single compromised agent becomes a trusted input source for the rest, which is ASI08 cascading failures. Authority tends to accumulate rather than narrow across hops. And observability degrades exactly when it matters most: reconstructing an incident across five agents requires correlated logging that most implementations do not have.
Three design rules help. Treat inter-agent messages as untrusted input, with the same validation applied to external content. Narrow authority at every hop. And correlate logs with a single trace identifier across the whole interaction, so an incident can be reconstructed as one story rather than five fragments.
If you are designing this, the business-level view of what agents should and should not be allowed to close is in our guide to agentic AI for customer service.
Pre-Launch Checklist
Before an agent touches production traffic.
- The agent has its own identity, not a shared service account or a human’s credentials.
- Every tool exposes the narrowest operation that satisfies the task.
- Irreversible and high-value actions require human approval.
- Generated code executes in a sandbox with no network or credential access by default.
- Hard caps exist on steps, spend and actions per session.
- Every prompt, tool call, parameter and result is logged, attributable and immutable.
- Memory writes are validated and scoped, and memory can be purged.
- A kill switch exists and has been tested, not merely designed.
- Inter-agent messages are treated as untrusted input.
- An incident runbook names who is paged and what they are authorised to do.
- Rollback has been rehearsed on a real action, not described in a document.
Conclusion
Agent security is not a harder version of chatbot security. It is a different discipline, because the failure mode changes from a wrong sentence to a wrong action taken with real credentials on real systems.
The framework exists: OWASP’s ASI01 to ASI10 gives a shared vocabulary that a board, a security team and an engineering team can use without translation. The controls are known and mostly unglamorous, and identity is the one that does the most work.
The mental shift that matters is accepting that prompt injection is contained rather than solved, and designing for a bounded blast radius instead of perfect detection.
If you are building agents and want the control stack designed in rather than retrofitted, our AI agent development services scope guardrails alongside capability, and AI consulting covers governance and risk tiering.
FAQ
Q: What is AI agent security?
The practice of containing what an autonomous AI agent can do when it is misled or malfunctions. Because an agent holds credentials, acts over multiple steps, retains memory and can delegate to other agents, the risk shifts from producing wrong output to taking wrong actions on real systems. The controls are therefore about permissions, approval gates, sandboxing, limits, logging and a tested kill switch.
Q: What is the OWASP Top 10 for Agentic Applications?
A framework published on 9 December 2025 by the OWASP GenAI Security Project, developed with over 100 security researchers and practitioners. It defines ten risk categories specific to autonomous agents, identified ASI01 to ASI10, running from Agent Goal Hijack through Tool Misuse, Identity and Privilege Abuse, Memory Poisoning, Unsafe Code Execution, Supply Chain risks, Insufficient Observability, Cascading Failures and Human Manipulation to Rogue Agents.
Q: Can prompt injection be prevented?
Not completely. An agent reading untrusted content cannot reliably distinguish instructions embedded in that content from operator instructions, because both arrive as text in the same channel. Filters and classifiers raise the cost of an attack and are worth deploying, but they are mitigation rather than prevention. The defensible approach is to assume injection succeeds and bound the blast radius through scoped credentials, approval gates on irreversible actions, logging and a tested kill switch.
Q: What controls should an AI agent have before production?
In order of weight: its own scoped identity rather than a shared service account, least-privilege tool access, approval gates on irreversible actions, sandboxed code execution, hard caps on steps and spend, comprehensive and attributable logging, memory hygiene with the ability to purge, and a kill switch that has been tested rather than merely designed.
Q: Why does agent identity matter so much?
An agent operating under a shared service account is indistinguishable in logs from every other process using that account, so you cannot attribute an action, revoke access narrowly, or scope permissions to the task. Giving the agent its own identity is what makes every other permission control possible, which is why it should be fixed first.
Q: Are multi-agent systems less secure?
They amplify the same risks. Agents trust each other’s output by default, so one compromised agent becomes a trusted input source for the rest. Authority tends to accumulate across delegation hops rather than narrow, and observability degrades because reconstructing an incident spanning several agents requires correlated logging most implementations lack. Treat inter-agent messages as untrusted, narrow authority at every hop, and use a single trace identifier across the interaction.
Q: What is memory poisoning?
Category ASI04. Injected content persists in an agent’s memory and influences decisions long after the original input was processed. It is particularly difficult to detect because the payload and its effect are separated in time, so the malicious input may be far outside the window anyone reviews when investigating a bad action.
Q: How is agent security different from chatbot security?
A chatbot failure produces a wrong sentence, mitigated by review. An agent failure produces a wrong action taken with real credentials, mitigated by permissions. The vulnerability classes overlap; the blast radius does not.
