The OWASP Agentic Top 10, in five questions
OWASP published a separate Top 10 for agentic applications in December 2025. Read as ten defects, it is a checklist someone works through once and files. Read as a map of amplified trust, it collapses into five questions you can put to any architecture review without the document open in front of you.
Why it needed its own list
A chatbot can be wrong. An agent can be wrong, use a credential, call a tool, change a record, and ask another agent to continue the work.
That sentence is the whole of the difference, and it is why OWASP wrote a separate list rather than adding entries to the existing one for LLM applications. The weaknesses are not new. What is new is that each one now arrives attached to a badge, keys, memory, tools and permission to delegate.
The brilliant, gullible intern has been promoted. It still cannot reliably tell a real instruction from a forged one.
One. Can the agent's goal be redirected?
Protecting the prompt is not enough once instructions can arrive through documents, web pages, retrieved context, memory and tool output. An agent does not merely answer. It plans — and a redirected plan persists across every step that follows.
A chatbot recovers from a bad instruction at the end of the turn. An agent carries it forward.
The bad answer: "We've got prompt injection covered." Ask what reaches the model that a person did not type.
Two. What authority can it exercise?
Redirection only becomes material when it meets a capable identity and a permissive tool. Most organisations can describe what their agent is for. Far fewer can produce the list of what it is permitted to do — under whose identity, with what credential lifetime, and who can revoke it mid-task.
The bad answer: an architecture diagram instead of a permission set.
Three. Which dependencies can be poisoned?
Models, tools, plug-ins, MCP servers, agent registries, retrieved knowledge.
Traditional supply chain assurance assumes a manifest fixed at build time. Agentic systems compose capability at runtime, which moves the problem from inventory to live verification. A dependency list that was true at deployment tells you very little about what the agent is calling this afternoon.
The bad answer: an SBOM, offered as though it settles the question.
Four. How far can one failure propagate?
Autonomy changes both the blast radius and the speed. One faulty decision fans out through downstream agents faster than a human review cycle can run.
The failure mode worth designing against is not the one where something breaks. It is the one where every component behaves exactly as specified and the outcome is still wrong.
The bad answer: a runbook that assumes somebody notices.
Five. Can humans stop, explain and recover?
This is the question that separates a deployment from an experiment.
The useful measures are not prompt counts or adoption rates. They are: time to detect, time to contain, time to stop, time to explain, time to reverse, time to recover — and the maximum unauthorised consequence possible before anyone intervenes.
The bad answer: "there's a human in the loop," without saying what the human is shown, or how long they have.
What I would actually do
Answer all five for one system this week. Not the whole estate. One assistant that is already live. The exercise takes an afternoon and it will tell you more than a quarter of policy work.
Write the permission set down, separately from the architecture. What it can do, under whose identity, for how long, and who revokes it. If that document does not exist, question two has no answer, and questions four and five inherit the problem.
Measure the six times. Detect, contain, stop, explain, reverse, recover. You do not need good numbers to start. You need the numbers to exist, because the first time you measure them is the last time you will be surprised by them.
Treat an unclear answer as the finding. If one of the five cannot be answered clearly for a system already in production, that is not a gap in the review. It is the result of the review: the agent's autonomy is ahead of the organisation's assurance.
Three questions for a vendor
- Under which identity does the agent act, and what is the credential lifetime?
- What can a person do mid-task, and what are they shown before they decide?
- What is the maximum unauthorised consequence possible before anyone intervenes?
None of these are gotchas. A serious product has answers. The absence of an answer is itself informative.
Sources
- OWASP Top 10 for Agentic Applications 2026 (ASI01–ASI10), OWASP GenAI Security Project, December 2025. CC BY-SA 4.0. genai.owasp.org
Five questions. If one of them cannot be answered clearly for a system already in production, the finding writes itself.
This is not an argument against deploying agents. It is an argument for knowing which of the five you cannot yet answer, and closing that one first.