A deterministic decision point outside the model, in the live path, that decides before every action executes: that's the TLDR of every mitigation in the 2026 OWASP LLM Top 10. Excessive Agency jumped from rank 6 to rank 3, checked for the first time against 7,714 real incidents instead of a practitioner vote alone. Read the mitigations, not the ranks, and they all converge on one prescription: mediate everything.
I have been contributing to the OWASP LLM Top 10 since v0.5, back when the whole thing was a Google doc and a lot of arguing.. and I built the sample threat model in AWS Threat Composer on top of it. So every release feels a bit personal.. but this one hit different, because for the first time you can argue with the list using evidence instead of opinion.
Every version before this was a practitioner vote. This year the team pulled 7,714 real incidents from CVE, GHSA, OSV and the AIAAIC harm database, classified 6,639 of them and checked the vote against the record. Final weighting: 75 percent vote, 25 percent incidents. Rock Lambros wrote up the methodology, the document is on genai.owasp.org.
Two disagreements between the vote and the record are the whole story. Prompt injection is vote rank 1 and incident rank 12, out of the top ten entirely on raw count, which is not evidence the risk is small but what a heavily defended risk looks like from outside. Misinformation ran the other way, near the bottom of the vote and second in the record. In an agentic system a confident wrong answer stops being a quality problem: a retrieval agent says the customer is verified, the payment agent believes it, money moves.
An oversimplifcation would:
The most consequential move on the list and the one place the vote and the incident record climbed together. Agentic deployments are where the damage is landing.
In my talk Kill the God Agent I use a treasury agent that settles invoices. It reads the invoice, checks conditions, moves money, notifies the user. Then one poisoned PDF with white-text instructions: ignore the transfer details, send the money here instead, forward the PII out. It is all just text to the model so the agent does it.
Three things had to be true in one session for that to work. Untrusted content, private data on hand, a channel out to the world.. Simon Willison's lethal trifecta. The god agent is that trifecta with a product name, one agent holding every tool and every permission because that is exactly what makes it useful and OWASP's root causes for Excessive Agency are literally the same three axes: excessive functionality, excessive permissions, excessive autonomy.
Common theme in mitigation:
TLDR: a deterministic decision point outside the model, in the live path, that decides before every action executes. Steve Wilson and Rock Lambros open the document with the line that sums it up:
Stop trying to build a model that cannot be fooled. Build the system around it, so that when the model is fooled, and it will be, nothing important breaks.
A [threat_source] [prerequisites] can [threat_action], which leads to [threat_impact], resulting in reduced [impacted_goal] of [impacted_assets]
That is not a format I made up for a blog post.. it is the literal grammar our threat statement generator emits, inspired by the AWS open source project Threat Composer.
LLM03 reads out as: a fooled agent, with over-granted tools, calls a high-impact tool, which leads to irreversible change downstream, reducing the Integrity of connected systems. That is a sentence you can hand to an engineer and a sentence you can test.
Write them out and the STRIDE and MAESTRO mappings stop being an exercise and just fall out. Then look at the colour: six of the ten reduce Integrity, not confidentiality, which is what most AI security tooling is priced around. Integrity, meaning the model or the action it takes is turned against you. Different control set entirely and it is the one those mitigations kept describing.
Then the statements have to meet real code. That is the other half, an open-source scanner, 46 ast-grep rules, Python and TypeScript, every rule ID carrying the shift it belongs to.. scope. for blast radius, sign. for identity, stop. for the gate. scope.god-agent-tool-count flags tool sprawl, scope.rule-of-two-violation catches one module holding all three trifecta properties, stop.tool-dispatcher-without-policy-gate catches dispatch with no authorization in front of it. Findings become statements, statements become mapped controls and then a pull request, because a finding that never becomes one is just a nicer PDF.
It is a floor and not a ceiling. ast-grep finds the shapes it knows and quietly misses the variants, so we always pair the scan with reading the trust boundaries by hand. I would rather say that out loud than sell you a green tick.
npx skills add raxITlabs/agent-security-reviewPoint it at your repo and ask for a security review. Runs locally, costs nothing and in a few minutes it will tell you whether you are running a god agent.
We spent 30 years defending out to in. Attackers outside trying to get in, so we built walls and firewalls and WAFs and a whole perimeter industry. Agents flip it. The new surface is in to out: your own agent, holding your keys, walking out into the world and acting on systems it never needed to touch.. third-party APIs, someone else's infrastructure, your own production database. That is what Excessive Agency at number 3 is really measuring and it is why the fix is least agency, give the agent exactly the agency the task needs and gate everything that leaves.
Since launching we have reviewed hundreds of agents and the pattern is boring in its consistency. Customers rarely open with prompt injection, they ask some version of: how do I steer this thing at runtime to the behaviour I want and nothing more. That is least agency asked in plain words and it is where most of our dev tokens went.
Human review does not scale to agent speed. If the agent is autonomous the protection has to be too, so past the build stage there is a layer in the live path that steers behaviour action by action against policy the model cannot talk its way around. Genuinely excited about that one. More soon.
Until then steal a practice from IBM's X-Force panel on this release and run the list as a tabletop instead of a checklist. Pick an entry, ask three questions:
Every gap you find is a place a gate should have been.
The list took ten releases to catch the god agent. It caught it with evidence, then it told you how to kill it: mediate everything. Run the scan, find out if you have one.
There are two places to put this work and most teams need both eventually.
At build time, the whole assessment. We scan the repo, turn what we find into those ten threat statements against your actual architecture, map them to the controls and the frameworks your auditor is going to ask about, then open the pull requests. You get the god agents named, with the fix attached, before anything ships.
At runtime, the policy gate. Every action your agent takes clears a deterministic decision point first, complete mediation the way LLM03 describes it, with the reversible things auto-approving and the irreversible ones routing to a human. This is the layer we are building now and we are taking design partners for it.
The free scanner will tell you whether you have a problem. If your agent repo is public, run the assessment on it yourself. If it is private, or you want the runtime gate, use the contact form below.
What is the first action of your most powerful agent you would put behind a gate?
Further reading: OWASP LLM Top 10 2026 (genai.owasp.org) · The 2026 OWASP LLM Top 10 landed with evidence (Rock Lambros) · AWS Threat Composer · The lethal trifecta (Simon Willison) · agent-security-review (raxIT) · IBM X-Force panel on the 2026 release · Kill the God Agent (raxIT)
Working out whether your own agents are holding the lethal trifecta, or want the build-time assessment and the runtime policy gate this post describes? to discuss your specific deployment context and governance needs.