Excessive agency is functionality, permission or autonomy an agent holds beyond what its task requires. OWASP lists it as LLM06:2025 and describes it as the vulnerability that turns an unexpected or ambiguous model output into a damaging action, with three named causes: excessive functionality, excessive permissions and excessive autonomy (OWASP LLM06:2025). The important word is holds. Excessive agency is a property of the system you built, measurable before any attack, and it is what decides how bad a wrong output can get.
What are the three kinds of excess?
Excessive functionality. The agent can call operations its job never needs. A summarisation assistant given a file tool that can also delete. A tool designed for one operation that exposes a whole API surface. A general shell or code execution tool, which is every operation at once. The test: list the operations the agent can invoke, then strike every one its task does not require. Whatever is left over is functionality you are betting on.
Excessive permissions. The credentials behind the tools are wider than the task. A read-only report agent connected with a write-capable database role. A ticketing integration holding administrative rights because that was the account available. Least privilege is the oldest answer to this and it is still the right one: every program should operate "using the least set of privileges necessary to complete the job" (Saltzer and Schroeder, section I.A; the same control is AC-6 in NIST SP 800-53 Rev. 5).
Excessive autonomy. The agent decides alone when to use what it holds. No gate on irreversible actions, no rate bound, no scope check between the plan and the effect. This is the axis that is usually left widest, because it costs nothing on the day of deployment and it is the reason the other two matter.
Why is this an authorization problem rather than a prompt problem?
Because the trigger is interchangeable and the agency is not. A wrong action can come from a prompt injection, a misread document, an ambiguous instruction, a tool returning something unexpected, or a plain bug in a chain of reasoning. OWASP's own text on injection is explicit that prevention is not settled: "it is unclear if there are fool-proof methods of prevention" (OWASP LLM01:2025).
So the durable variable is what the agent can do when the trigger fires. MITRE ATLAS catalogues the step as a technique in its own right, the adversary causing an agent to invoke tools it already holds (AML.T0053), and a separate one for changing the agent's own configuration to widen what it may do (AML.T0081). Neither requires a new credential. Both are cheap when agency is wide and useless when it is narrow.
What do the recommended mitigations actually achieve?
| Mitigation | Real effect | What it leaves open |
|---|---|---|
| Remove unused tools and extensions | Removes whole classes of effect permanently | The remaining tools, which are the ones with business value |
| Replace open-ended tools with specific ones | Turns a shell into a short list of named operations | Each named operation, at full strength, on any target |
| Narrow the credential behind each tool | Caps damage per system | Everything inside the scope, including deletes |
| Act with the end user's identity, not the agent's | Restores attribution and inherits real limits | The user's own privileges, which may be broad |
| Approve high-impact actions | Stops the irreversible ones on a person's decision | The volume problem, and approving a summary the agent wrote |
| Rate limit and bound per hour | Converts a runaway into a small incident | A single well-chosen action, which needs no volume |
| Log and monitor | Detects after the fact, enables recovery | Nothing at the moment of the action |
OWASP's own recommendation for the high-impact case is to "utilise human-in-the-loop control to require a human to approve high-impact actions" (LLM06:2025). The design of that gate, and how it fails, is in human-in-the-loop for AI agents.
How do you measure the agency you have already granted?
Four questions, answerable on paper, per agent.
- Enumerate the effects. Not the tools, the effects. One tool can carry several. What can change, in which system, as a result of this agent running?
- Sort them by reversibility. What can you undo within an hour, within a day, and never?
- Bound the blast radius. For each irreversible effect, how many records, accounts or hosts can one invocation touch, and how many invocations per hour are possible?
- Find the transitive paths. Agency inherits. An agent whose tool is another agent holds that agent's effects. A tool that writes a file a pipeline later executes holds the pipeline's effects.
The answer to question one is usually larger than the team expects, and the answer to question four is usually unmapped.
Where does agency creep back in?
- Integration convenience. Permissions are widened to unblock a demo. Nothing fails when they stay wide, so they stay wide.
- Inherited human sessions. An agent driving a logged-in browser holds a person's entitlements. See AI agent credentials.
- Sub-agents and tool chains. Each hop adds effects nobody enumerated.
- Memory and configuration. What the agent may do is often data, and data can be written.
- Self-extension. An agent that can install a package, write a script or register a tool grants itself functionality between reviews.
- The catalogue that is open by default. If an unknown operation is attempted and something permissive happens, the catalogue is not a catalogue. Refusal has to be the default, which is the subject of agent authorization.
What does ZIFFER constrain, and what does it not?
ZIFFER narrows the autonomy axis at the point of effect: every proposed action is graded against your signed policy, an action with no risk function is refused rather than graded, an unknown resource is treated as the highest tier, and an irreversible one is held for a quorum of two named humans. The credential stays with your executor, so functionality the agent appears to hold produces no effect without a verified receipt. The limits are published rather than implied: the SDK verifies and does not intervene, so the line that stops the action is a line of your code; the development-time MCP server routes and does not enforce; and an agent holding its own API key is outside the boundary until that key is revoked. The full list is what ZIFFER does not do yet. The attack side of the same problem is in prompt injection in AI agents.