Learn
What is excessive agency?
Excessive agency is the risk that an AI agent holds more capability than its task requires – more tools, broader permissions, more autonomy – so that when something goes wrong (a hallucination, an injection, a plain bug), the agent has the power to turn the error into damage. It is risk LLM06 in the OWASP Top 10 for LLM Applications, and it is the defining security problem of the agent era.
The concept matters because it reframes the question. “Will the model behave?” is unanswerable – models are probabilistic and inputs are adversarial. “What is the worst thing this agent can do if it misbehaves?” is an engineering question with an engineering answer: exactly as much as you let it.
OWASP decomposes the risk into three gaps, and they are worth keeping separate because the fixes differ:
Excessive functionality
The agent has tools it doesn’t need – a support bot that can also issue refunds, an email summarizer that can also send. Every surplus tool is attack surface. Fix: per-agent tool allowlists; deny by default.
Excessive permissions
The tools it does need are scoped too broadly – read-write credentials for a read-only job, admin database access for a lookup. Fix: least-privilege credentials per tool, plus risk tiers so write/delete/payment-class calls face stricter policy than reads.
Excessive autonomy
Consequential actions execute without confirmation – payments, deletions, external emails fire on the model’s say-so alone. Fix: designated tiers require human approval, and budgets cap what any single run can spend or do regardless.
Excessive agency is a multiplier, not a standalone failure. A prompt injection against a chatbot yields a bad paragraph; the same injection against an over-privileged agent yields a wire transfer. A hallucinated account number in prose is embarrassing; in a payment tool call it is fraud. This is why agency limits are the layer that still holds when detection fails – the injected instruction may fool the model, but it cannot raise the agent’s permissions, cross its budget, or skip an approval tier.
The inverse also holds: tight agency limits make every other guardrail cheaper. If payments always require approval and always must be grounded in the run’s sources, your injection detector no longer has to be perfect for payments to be safe.
Agency limits only bind if they are enforced somewhere the agent cannot reach. In-process rules share the process with the thing they police; enforcement on the wire – between the agent and its model, between the agent and its tools – does not. The proxy implements the full set:
Tool policy
Per-API-key allow/deny lists with JSON-schema validation of arguments – the functionality gap, closed by default-deny.
Permission tiers
Every tool carries a risk tier (read < network < write < exec < delete < payment); escalation across the run and dangerous argument patterns are flagged or blocked.
Approval gates
Designated tiers return require-approval instead of executing – a human sign-off in the loop exactly where policy demands it, via the checkpoint API.
Run budgets & loop guard
Hard per-run ceilings on cost, steps, and tool calls, plus fingerprinting of repeated calls – the autonomy gap, capped even when everything else looks fine.
What is excessive agency in the OWASP Top 10?
Risk LLM06: an LLM-based system granted more functionality, permissions, or autonomy than its task needs, so that model errors or successful attacks produce real-world damage instead of just wrong text.
What is the difference between excessive agency and prompt injection?
Injection is how an attacker steers the model; excessive agency is why the steering matters. Limiting agency does not stop the injection – it caps what a successfully injected agent can actually do.
How do I decide which tools need human approval?
Tier by consequence and reversibility: reads flow freely; writes and external sends deserve scrutiny; payments, deletions, and anything irreversible justify an approval gate. Risk tiers plus per-tier approval policy express exactly this.
Doesn’t limiting agency defeat the point of agents?
No – it is what makes deploying them defensible. An agent that does 95% of the work and pauses for sign-off on the payment step still eliminates most of the toil, without betting the account balance on a language model’s judgment.
See the checks run on your own traffic.
One base-URL change puts every request behind the guardrail pipeline. We’re running a limited demo – sign up and we’ll get you in as soon as we can.