AI Agent Security Cheat Sheet: Excessive Agency & How to Contain It
A chatbot that gets jailbroken is a content problem. An agent — a model wired to tools that send email, run queries, call APIs, move money — that gets jailbroken is an incident. Excessive agency (OWASP LLM03) is the gap between what an agent is allowed to do and what it actually needs to. This is how to close it.
Test your own agents only. Probing an agent's tool permissions is security work on systems you own or are authorized to assess. Manipulating someone else's agent into taking actions is an attack on whatever it's connected to.
The gap that bites
Every LLM app is vulnerable to prompt injection and jailbreaks — assume the model will be talked into something eventually. Excessive agency is what decides whether that's a shrug or a breach. If a compromised model can only produce text, you have a bad answer. If it can act, you have an attacker acting with your agent's permissions. So the whole game is limiting what it can do.
The three excesses
OWASP breaks LLM03 into three, and every real agent bug is one of them. Audit yours against all three.
| Excess | What it looks like | The fix |
|---|---|---|
| Excessive functionality | The agent has tools it doesn't need for the task — a support bot that can also delete accounts. | Give it only the tools the job requires. Remove the rest; don't just tell it not to use them. |
| Excessive permissions | A tool runs with broader scope than needed — read-write database access when read-only would do. | Scope each tool's credentials to the minimum. The agent's rights should be narrower than the developer's. |
| Excessive autonomy | The agent acts with no human check — it sends the email, moves the money, ships the change on its own say-so. | Put a human in the loop for anything irreversible or high-impact. Approve the action, not just the plan. |
The confused deputy
The pattern underneath most agent attacks. The agent is a trusted deputy — it holds real permissions. The attacker doesn't, but if they can get the agent to act on their behalf (via injection in a document it reads, say), the agent's authority becomes theirs. They never touched your systems; your own agent did the work for them. That's why authenticating the user isn't enough — you have to constrain what the agent will do regardless of who asked.
Design an agent that can't hurt you
Assume the model is untrusted and build the guardrails around it, in code.
- Deny by default. The agent gets no tool until you deliberately grant it. Every capability is a decision, not a default.
- Least privilege, per tool. Scope each tool's credentials to exactly what it needs — read-only where possible, one mailbox not the domain, one table not the database.
- Human-in-the-loop for the irreversible. Payments, deletes, outbound messages, production changes — require a person to approve the specific action, with the details in front of them.
- Treat tool output as untrusted too. Data the agent fetches can carry injection. Don't feed it straight back into the next tool call without checks.
- Isolate and sandbox. Run tools with their own limited identity, in an environment where a rogue call can't reach beyond its box.
- Log every action, not just every chat. You want a record of what the agent did — that's your detection and your audit trail when something goes wrong.
- Rate-limit actions. A cap on how many high-impact calls an agent can make turns a runaway loop or an attack into something bounded and visible.
Go deeper
- OWASP LLM Top 10 — where LLM03 sits among the other AI risks.
- Prompt injection — the usual way an agent gets told to misbehave.
- LLM security lab — its LLM03 challenge (“Keys to the Kingdom”) is exactly this, hands-on.
Aligned to OWASP LLM03:2026 Excessive Agency; guidance is a plain-language distillation of current agent-security practice. Building agents and want a control added here? Tell me.