AI Agent Security Cheat Sheet: Excessive Agency, Tool Misuse & More

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.

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.

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.

Give every agent its own credential rather than sharing one across tools, so revoking a compromised key doesn't take the rest down with it. Prefixed, high-entropy keys make that practical — the prefix tells you at a glance which system a leaked key belongs to. A generator that emits prefixed random tokens is enough if you aren't already issuing them from a secrets manager.

Agent-specific risks: the OWASP Agentic Top 10

Excessive agency is the root. These are the ways it gets exploited once an agent has tools, memory and other systems to talk to. The OWASP Top 10 for Agentic Applications names them; here are the six you will meet first, each with what to watch for and what stops it.

• Indirect prompt injection and tool-output injection (ASI01, Agent Goal Hijack). Instructions hidden in content the agent reads — a web page, an email, a file, or the result a tool hands back — get treated as orders instead of data. Watch for: the agent’s plan changing right after it reads external content, or tool calls nobody asked for. Defend: treat every tool result and retrieved document as untrusted data, keep it clearly separated from instructions, and require approval before any action that follows from content the agent just fetched.
• Tool misuse (ASI02). The agent uses a legitimate tool in a way you never intended — wrong parameters, wrong scale, or harmless tools chained into a harmful outcome. Watch for: unusual argument values, bursts of calls, tool sequences that never appear in normal use. Defend: validate every tool argument in code against a schema and an allow-list, rate-limit each tool, and log every call with its arguments.
• Privilege escalation and identity abuse (ASI03). The agent runs with credentials broader than the task — often the user’s own or a shared service account — so a hijacked agent inherits all of it. Watch for: the agent touching resources outside its task, or admin-level scopes used for routine work. Defend: give the agent its own identity, scope tokens per tool and per task, keep them short-lived, and never pass the user’s full session through.
• Data exfiltration (ASI02, ASI05). Sensitive data leaves through a channel the agent controls — an outbound email, an HTTP request, or a link or image URL with data packed into it. Watch for: outbound requests to new domains, unusually large payloads, links built from internal data. Defend: allow-list outbound destinations, block auto-loading links and images in agent output, and filter outputs for secrets and personal data before they leave.
• Memory poisoning (ASI06). Bad information planted in an agent’s long-term memory or RAG store resurfaces in later sessions, sometimes for other users, long after the original conversation. Watch for: memory written from untrusted sources, or answers that suddenly lean on a new “fact”. Defend: record where every memory came from, don’t let untrusted content write to shared memory, isolate memory per user, and review and expire entries.
• Supply chain: MCP servers and plugins (ASI04). A third-party tool, MCP server or plugin can change its behaviour or its tool descriptions after you approved it. Watch for: descriptions, permissions or endpoints that change between versions. Defend: pin versions, review what each server can reach, sandbox anything you don’t control, and re-review after every update.

Watch for it in the logs

You can’t defend what you can’t see. Log every agent step as an event: the request, each tool call with its arguments, each tool result, and every approval or denial. Then alert on the signals above — new outbound domains, tool calls with no matching user request, and privilege used outside a task’s scope. If your SOC already collects application logs, agent events belong in the same SIEM, next to everything else they can be correlated with.

Test it

Don’t take an agent’s safety on faith. Point an automated scanner at an agent you own — promptfoo’s OWASP Agentic preset maps its checks to these same ASI categories — note the pass rate, add one defence from this page, and re-run. A number that climbs is the only proof a control works.

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.