The OWASP Top 10 for LLM Applications ranks the risks in systems built on language models, and the 2025 edition is the current one (PDF). Eight of its entries describe things that go wrong inside the application. Two of them decide whether an agent is safe to give authority to, and they are best read as a pair: LLM01 Prompt Injection, and LLM06 Excessive Agency.
What does LLM01 actually say?
Verbatim, it defines the vulnerability: "A Prompt Injection Vulnerability occurs when user prompts alter the LLM's behavior or output in unintended ways" (LLM01). It splits into direct injection, where the attacker submits the text, and indirect injection, where the malicious content sits in external data the model reads.
The sentence that matters most is the one about prevention: "Given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection."
Read that as a standards body declining to promise a filter can close the top entry on its own list. The mitigations LLM01 does offer are real and worth building: constrain model behaviour, define and validate expected output formats, filter input and output, enforce privilege control and least privilege, require approval for high-risk actions, segregate and identify external content, and test adversarially. They are a stack that reduces the attack, offered under an explicit statement that the attack is not closed.
What does LLM06 actually say?
LLM06:2025 Excessive Agency covers the damage half. Its opening, verbatim: "An LLM-based system is often granted a degree of agency by its developer, the ability to call functions or interface with other systems via extensions, to undertake actions in response to a prompt" (LLM06).
It names three root causes, exactly these:
| Root cause | What it means in a deployment |
|---|---|
| Excessive functionality | The agent can call tools the task never needed |
| Excessive permissions | Its credentials reach records and systems outside the task |
| Excessive autonomy | It takes consequential actions with nobody deciding |
And a headline mitigation, verbatim: "Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken. This may be implemented in a downstream system (outside the scope of the LLM application) or within the LLM extension itself."
The parenthesis is the part most readers skip. OWASP explicitly contemplates the approval living outside the LLM application, which is the difference between a prompt that asks nicely and a system that will not proceed.
Why is the pair the whole argument?
Put the two sentences next to each other.
- LLM01: fool-proof prevention is unclear.
- LLM06: cut functionality, permissions and autonomy, and put a person in front of high-impact actions.
The top-ranked authority on LLM risk says the injection cannot be reliably filtered, and then says the fix is to reduce what the compromised system is allowed to do. That is a threat model, not a product category. Everything in this pillar is downstream of it.
OWASP's agentic work extends the same logic. Its threat-and-mitigation reference adds the failure modes that only appear once agents act, including T8 Repudiation and Untraceability, where actions cannot be traced back because logging is insufficient, and T10 Overwhelming Human in the Loop, where the approval surface itself becomes the attack (OWASP). T10 is the standing objection to any approval design, and the answer to it is fewer holds on things that matter, not a prompt on everything.
How does MITRE ATLAS say the same thing?
ATLAS is a techniques catalogue rather than a risk ranking, and it places the same attack in an attacker's workflow.
| Technique | Name | Why it matters here |
|---|---|---|
| AML.T0051 | LLM Prompt Injection | Filed under Initial Access. Injection is entry, not content quality |
| AML.T0051.000 / .001 / .002 | Direct / Indirect / Triggered | The delivery variants, including a payload that fires on a condition |
| AML.T0053 | AI Agent Tool Invocation | Reaching the tools is the objective |
| AML.T0080 | AI Agent Context Poisoning | Sub-techniques for memory and for the thread: the payload persists |
| AML.T0081 | Modify AI Agent Configuration | The agent's own instructions as the target |
Together the two frameworks give a reviewer the vocabulary and the ranking: ATLAS for how the attacker moves, OWASP for which risk to fix first.
How do you use this in a sign-off review?
Four questions, in LLM06's own terms.
- Functionality. List the tools the agent can call. Which does this task not need?
- Permissions. Whose credential does each call run on, and what else does that credential reach?
- Autonomy. Which actions run with nobody deciding, and which of those cannot be undone?
- Evidence. If one of them ran wrongly, what could you show a party who was not there?
Related: prompt injection defences and their limits, prompt injection in AI agents, and containing a successful injection.
Where does the downstream approval OWASP describes actually live?
In an authorization layer, and that is what ZIFFER is.
The agent holds no credential, so LLM06's permissions question has a short answer: none of yours. It proposes an action, and the credential that performs it sits with an executor on your side of the line. An injected proposal is graded against the same signed policy as a clean one, since the risk, the reversibility and the owner of the target are recomputed from your policy rather than read from the proposal. Irreversible actions are held for a quorum of two named humans who sign the exact bytes that will run, which is LLM06's high-impact approval implemented downstream, outside the LLM application. Every outcome, refusals included, leaves a signed receipt, which is the answer to T8.
ZIFFER is not a guardrail. It does not inspect text and it detects no injection, so it addresses no part of LLM01. It decides whether a proposed action is entitled to run. See agent authorization, the agent audit trail and every refusal.