Cybersecurity glossary
What is Excessive Agency?
Learn what excessive agency is, how LLM agents get more tools and permissions than the task needs, why hijacked models then cause real damage, and how to apply least privilege to AI actions.
Definition
Excessive agency is an LLM application design flaw in which the model can invoke tools, write data, or take external actions with more power than the user’s task requires—so prompt injection, mistakes, or jailbreaks produce real-world side effects instead of a wrong sentence.
Why excessive agency matters
A chatbot that only returns text can embarrass you. An agent that can open PRs, refund orders, or query a data warehouse can change the business. Excessive agency is giving that agent a bigger toolbox and hotter credentials than the job needs.
OWASP calls this out because teams copy plugin demos into production: one MCP bundle with filesystem, shell, browser, and corporate SaaS. The demo looks magical. The blast radius looks like a compromised intern with admin SSO.
How over-privileged agents get built
Start from a demo toolbox
Generic ‘browse, code, email, database’ kits are enabled to make the agent feel capable.
Reuse a powerful identity
Tools run as a service account that can see every tenant or production cluster.
Skip confirmation
Writes execute as soon as the model emits a function call, to reduce friction.
Hijack or hallucinate
Injection, a poisoned tool, or a confident mistake selects a harmful action.
The tool actually runs
APIs fire with real side effects; the chat UI may still show a friendly summary.
Discover too late
Logs are incomplete, or the agent had permission to hide its tracks in the same systems.
Dimensions of too much power
Too many tools
Shell plus production DB plus mail is several products glued together, not one assistant.
Too much permission
A user who can view a ticket should not grant the agent rights to export the whole CRM.
Too much autonomy
Multi-step loops keep calling tools until a budget is gone or damage is done.
Too little identity
Acting as a shared bot user erases attribution and breaks per-user ACLs.
Shrink agency on purpose
| Pattern | Example | Safer default |
|---|---|---|
| Read versus write | Agent can create refunds | Propose a refund; finance tool requires a human click |
| Scope | SQL tool accepts any query | Parameterized views per tenant; no DDL |
| Identity | Shared ‘llm-prod’ token | On-behalf-of the user with the user’s scopes |
| Blast radius | One agent has shell on the app host | No shell; isolated worker with no secrets |
| Stop conditions | Loop until the model says done | Hard caps on steps, tokens, and spend |
- List every tool, credential, and network path the model can reach; delete anything not required.
- Run tools as the user where possible; never as a global admin ‘for convenience.’
- Default to read-only; treat writes as a separate, reviewed capability.
- Require human-in-the-loop for money, identity, deletion, and external messaging.
- Cap autonomous steps, runtime, and cost per session.
- Log tool name, arguments (redacted), actor, and result for every invocation.
- Red-team with injection that tries to send data off-box or escalate in SaaS APIs.
- Review new MCP servers like new OAuth apps: scope, publisher, and data classification.
The practical takeaway
Excessive agency is least privilege ignored for AI. The model will be injected, jailbroken, or simply wrong. The question is whether that error can move money, mail, or production data.
Give agents the smallest toolbox that still completes the task, bind actions to the user’s identity, and keep irreversible calls behind a human. Capability is a product choice, not a property of the LLM.
Related security terms
Agentic AI Security
The broader discipline of securing systems that plan and act.
Human-in-the-Loop
Approval gates that offset agency the model should not have alone.
Tool Poisoning
Malicious tools that become more dangerous when agency is broad.
Model Context Protocol (MCP)
A common way agents gain tools and resources.
Guardrail
Policy layers that should constrain which tools may run.
Frequently asked questions
What is excessive agency in simple terms?
The assistant can do too much: delete data, send email, spend money, or call production APIs when a read-only answer would have been enough.
Is this a model bug or an app bug?
It is an application design bug. The model proposes actions; your product chooses which tools exist, which credentials they use, and whether a human must confirm.
Why is this dangerous with prompt injection?
Injection changes what the model wants to do. Excessive agency decides whether that want can become a wire transfer, a mail blast, or a database drop.
Does ‘the user asked for it’ make broad tools OK?
Only if the tool cannot exceed that user’s own permissions and high-impact actions are confirmed. An agent should not be a superuser because the chat UI is convenient.
How is this different from insecure output handling?
Output handling is about interpreting a string unsafely. Excessive agency is about which actions exist at all. You can have safe encoding and still let the model call a god-mode API.
What does least privilege look like for agents?
Scoped OAuth, read-only by default, allowlisted recipients and resources, per-tool rate limits, and step-up approval for writes.
Can you fix excessive agency with a better system prompt?
No. ‘Be careful’ is not an authorization layer. Remove the tool or wrap it in deterministic policy.
References
Explore authoritative guidance and frameworks related to excessive agency.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.