Excessive agency is the new top LLM risk: what the OWASP 2026 update means for your AI governance

The 2026 OWASP update moved excessive agency to the top of the list.

The OWASP Top 10 for Large Language Model Applications is the closest thing the industry has to a shared threat model for AI systems. The 2026 edition, flagged by ReversingLabs and others, reorders the risks. Excessive agency is now number one, overtaking prompt injection. That is not a cosmetic change. It reflects a real shift in how LLM attacks are playing out in production.

Excessive agency is the risk that an LLM has too much power to act on its own. The model can call tools, access data, send messages, trigger workflows, or modify records. When that power is granted too broadly, a single bad output or a manipulated prompt can cause real damage. The classic failure is a chatbot that can place orders or delete files because it was given API access without guardrails. The model does not need to be malicious. It just needs to be wrong, or tricked, and the system acts on that wrongness.

The mechanism: why this is not just another prompt injection problem.

Prompt injection is the attack. Excessive agency is the vulnerability that makes the attack dangerous. In 2023 and 2024, most teams focused on stopping the injection itself, filtering inputs, or blocking known malicious patterns. That approach is incomplete. The 2026 update reflects that even perfectly sanitised inputs fail when the model has broad tool access.

The mechanism is straightforward. An LLM receives a prompt, generates a response, and that response is passed to a tool or an API. If the tool call is not scoped, the model can take actions nobody authorised. For example, a customer-support bot with access to a refund system might issue a refund it was never asked to give. A coding assistant with write access to a repository might commit changes based on a hallucinated library. The failure is not in the model's reasoning. It is in the system design that lets a probabilistic output trigger a deterministic action.

The OWASP guidance is clear: the model should only have the minimum tools it needs, and every tool call should be scoped, rate-limited, and logged. That is the same principle as least privilege in traditional security, applied to an AI agent.

The governance failure mode: hallucination meets unconstrained action.

This is where the risk pattern connects to the broader AI governance problem. The two most cited LLM incidents in recent years are both grounding failures, not security breaches. In 2024, Air Canada's support chatbot invented a bereavement-refund policy that did not exist. The tribunal held the airline liable for what the AI told a customer. In 2023, a law firm used an LLM that fabricated court cases, which were filed and led to sanctions. In both cases, the model produced confident, false output. The difference is what happened next. Air Canada's bot could not act on the policy it invented, but it could state it. The law firm's tool could not file the cases itself, but a human did.

Now imagine those same grounding failures with excessive agency. The chatbot does not just state a false refund policy, it issues the refund. The legal tool does not just draft a brief with fake citations, it files it. The harm moves from reputational to financial and legal in a single step.

The failure mode your risk team should track is not "the model hallucinated." It is "the model hallucinated and the system acted on it." That is a different control problem. Grounding alone is not enough. You need both grounding and action scoping.

What the EU AI Act and OWASP actually require.

Under the EU AI Act, high-risk AI systems must have human oversight, as set out in Article 14. In plain words, that means a human must be able to intervene, override, or stop the system. If your LLM can initiate a refund, send an email, or modify a record without a human in the loop, you are likely out of compliance for high-risk use cases. The rules for high-risk systems apply from December 2027, so there is time, but the design decisions you make now determine whether you can meet that bar.

OWASP's guidance is more technical but aligns. For excessive agency, the recommended controls are: limit the tools the model can call, require human approval for irreversible actions, and log every tool call so you can trace what happened. That is not just security hygiene. It is the operational implementation of human oversight.

Key risk indicators you should be tracking.

If you want to measure this risk class, do not just track model accuracy. Track the following, on a sample of production output, monthly:

• Unsupported-claim rate: the percentage of generated statements that cannot be traced to a source in your approved knowledge base.
• Citation coverage: for factual answers, the share that include a valid, verifiable citation.
• Confirmed false statements reaching customers: the count of wrong outputs that were not caught before they reached a user or triggered an action.

Those three numbers give you a window into both grounding quality and the blast radius of a failure. If the unsupported-claim rate is low but the confirmed-false-statements number is high, your review process is the weak link. If the claim rate is high, your grounding is weak.

What to do

• Map every tool your LLM can call and ask one question for each: what is the worst thing this tool could do if the model output is wrong? If the answer is "significant harm," add a human approval step.
• Scope tool access to the minimum the model needs. A refund tool should not be able to issue refunds above a threshold without a second check. A code tool should not push to production.
• Run a monthly grounding audit on a sample of production responses. Measure the unsupported-claim rate and citation coverage, and review any confirmed false statements that reached customers.
• Add a human-in-the-loop gate for irreversible actions. This is not just good practice, it is what Article 14 of the EU AI Act asks for.
• Log every tool call with the prompt, the output, and the action taken. When something goes wrong, you need to be able to replay exactly what happened.

A governance program, whether built in-house or with a tool like autogovern.io, should make this audit repeatable. The point is not to eliminate all risk, it is to know where it sits and to keep a human in control of the actions that matter.

More from our platforms

These sister platforms cover the parts of this problem that sit outside governance.

• Argus (argus.threatclaw.ai) records every trace an AI application produces and scans it for prompt injection, jailbreaks and data leaks, including the attacks hidden inside retrieved documents and tool results rather than in what the user typed. Governance decides what an AI agent is allowed to do. Argus shows what it actually did.
• ThreatClaw (www.threatclaw.ai) tracks the threat side of the same systems: 22 live intelligence feeds, exploitation predicted before it is officially confirmed, threat actor profiles, and detection rules you can deploy straight away. A control is only as good as the threat it is sized against.