Security · owasp, ai-agents, appsec, governance
OWASP moved agency to third place: the checklist an AI agent must pass before approval
Excessive agency climbed three places and unbounded consumption four in OWASP's 2026 LLM list. An approval now has to test identity, tool scope and spend as three separate controls.
Security
Key points
- OWASP's 2026 LLM list keeps prompt injection first but moves excessive agency from sixth to third and unbounded consumption from tenth to sixth.
- The ranking weighted a community vote at 75 percent and a corpus of 7,714 documented incidents, 6,639 of them classifiable, at 25 percent.
- Approve an agent only when tool scope, the agent's own workload identity and per-workflow spend limits are enforced outside the model.
What the 2026 list actually changed
OWASP published its GenAI LLM Top 10 for 2026 on 3 August 2026. The ten risk areas are the ones the 2025 edition carried, but the order and the scope moved, and the movement is the signal. Excessive agency rose from sixth to third, unbounded consumption climbed four places from tenth to sixth, system prompt leakage was renamed hidden context exposure and broadened to cover tool schemas, policy logic and workflow rules, and improper output handling fell from fifth to tenth while its scope expanded.
The three that gained ground share a property: they are consequences of giving a model reach rather than failures of its conversation. A manipulated chatbot produces a bad answer. A manipulated agent reaches private data, invokes an overprivileged tool or takes an irreversible action. That widening blast radius is the reason the ranking moved, and it is the reason an agent approval should not be the same review as a chatbot approval.
The three risks that decide an agent approval
A workable approval checklist can start from the three risks that moved, because each one maps to a control that either exists outside the model or does not exist at all. The grid below is the part of the list a security lead can put in front of an architecture review without translating it first.
| Prompt injection, LLM01 | Excessive agency, LLM03 | Unbounded consumption, LLM06 | |
|---|---|---|---|
| 2026 rank | First, unchanged | Third, up from sixth | Sixth, up from tenth |
| What fails | Untrusted content enters the model's context | Model output can trigger a privileged action | One request becomes many calls and tool runs |
| Control that holds | Authorisation outside the model | Narrow downstream permissions per action | Limits across the workflow, attributed to an identity |
| Approval test | Does any tool read content the user did not write | Does the agent hold long-lived administrator rights | Is there a per-workflow token and tool budget |
Advertisement
The method behind the ranking is worth arguing with
Previous editions rested on practitioner judgment. For 2026, OWASP compared that judgment with a corpus of 7,714 publicly documented incidents, 6,639 of which carried enough information to classify, and weighted the community vote at 75 percent and the incident data at 25 percent. The comparison exposed a gap between what practitioners fear and what gets written down: prompt injection ranked first in the vote but fell outside the top ten on the incident record alone, which the methodology describes as a defence effect, because teams invest heavily in containing it and public records understate a risk that mature organisations already spend money on.
Misinformation ran the other way, near the bottom of the vote and near the top of the incident record, and OWASP moved it from ninth to seventh. The useful reading is that the list is a prioritised threat model, not a likelihood score. Public incident data is incomplete, reporting practice varies between organisations and the categories overlap, so a control that exists is worth more than a ranking that agrees with you.
Agency is the risk that spends money
OWASP traces excessive agency to three causes: too much functionality, permissions broader than the task, and more autonomy than the workflow needs. The recommended control is not a better prompt. It is narrowing the tools available to the application, narrowing the downstream permissions those tools run with, and passing each action through authorisation logic that does not depend on the model's judgment. That last clause is the one that changes a design review, because it rules out the common pattern where the agent decides whether it is allowed to act.
Unbounded consumption is the same argument applied to the bill. Extended reasoning can consume a large token budget from a short prompt, and an agentic workflow can turn one request into repeated model calls and tool activity, which is why the category now covers denial of wallet alongside service disruption and model extraction. Traditional request limits do not measure the full cost of a workflow. The control has to account for the resources consumed across the workflow and stop activity when it exceeds a defined limit, which also means knowing which agent, user or workload generated the activity before the limit can be applied without breaking something else.
Advertisement
Where the approval checklist should draw the line
The design rule that follows from the 2026 list is to assume the model will fail and to constrain what happens next. Credentials and security decisions stay outside the model, each agent receives only the access its current task requires, and when an agent acts for a person the user's identity and authority inform the decision as well. Unattended agents and scheduled workflows should run under their own narrowly scoped workload identities rather than a service account with standing privilege.
Two more items belong on the checklist because they are cheap to test. Retrieval authorisation should happen before information enters the model's context, not after the search returns, because an application that retrieves a document the user cannot open is working as designed and leaking anyway. And every destination that receives model output needs its own deterministic safeguard: generated SQL passed to a database, generated code passed to a shell and generated markup rendered in a browser are three different problems with three different fixes.
What this costs, and where the budget goes
OWASP publishes no cost figures for these controls, and the list is not a spending plan. What it does do is name where an unbudgeted item appears. Denial of wallet is a budget line before it is a security incident, so a token and tool-call ceiling per workflow is a finance control as much as a security one. Tool-scoped workload identities and a policy layer that authorises each tool call are engineering work on the agent platform rather than a product purchase, and audit records that show who acted, which policy applied and what decision followed are the evidence that the controls ran.
For agents that use tools, act across systems or hold memory, OWASP recommends reading the LLM list alongside its Top 10 for Agentic Applications, and the project has also published an Agent Control Standard. The decision rule for an approval is therefore blunt. If the agent can act, approve on the identity and policy layer first and treat the prompt as documentation; if it cannot act, the LLM list alone is enough. An approval that lists prompt-injection defences and skips the tool permissions has tested the wrong thing.
Advertisement
Sources 2


