| name | excessive-agency |
| description | Detects autonomous agents that take irreversible or high-impact actions without human approval. Use when building autonomous LLM agents, implementing multi-step agent pipelines, writing code where LLM output triggers real-world actions (file writes, API calls, emails, database changes, code execution), or designing agentic workflows with tool use. |
Excessive Agency (OWASP LLM08:2025)
What this checks
Prevents autonomous agents from taking irreversible or high-impact actions without
human oversight. When an LLM can directly write files, send emails, or modify databases,
a single compromised or hallucinated step can cause unrecoverable damage.
Vulnerable patterns
- Agent dispatches an irreversible action (send mail, delete record, deploy, drop table) immediately on LLM instruction with no human confirmation step
- Single LLM response authorizes a high-impact production action with no impact classification or approval gate
- Agent runs with write access to resources beyond what the task requires — no least-privilege scoping at the tool boundary
- No kill switch, pause mechanism, bounded iteration count, or audit trail for agent actions
- Tool that accepts a raw query string, shell command, or code blob built by the LLM rather than typed structured parameters
Fix immediately
Flag the vulnerable code and explain the risk. Then suggest a fix that establishes
these properties:
- Actions are classified by impact, and the classifier gates dispatch. Low-impact
(reversible, narrow scope) may proceed; high-impact (irreversible, broad scope,
external side effects) blocks on human approval. A classifier that's defined but
never branched on is the bug this skill prevents.
- Tool boundaries enforce an explicit allowlist of actions and resources —
path prefixes, API endpoints, table names. The LLM does not choose what's
allowed; the tool handler does, and rejects anything outside the list before
dispatch.
- Every executed action is audit-logged before dispatch, with enough context
to reconstruct what happened: the action name, its parameters, the prompt that
produced it, and the operator who approved it (if any). After-the-fact logging
is insufficient — if dispatch crashes, the log is gone.
- Irreversible actions cannot be invoked transitively through LLM-generated
parameters. A tool named
run_sql that accepts arbitrary queries violates
this; a tool named archive_record(id) that only issues a scoped update does not.
- When the task seems to require LLM-generated SQL, shell commands, or arbitrary
code strings, redesign the tool interface. Expose typed parameters (table
name, filter fields, numeric limits, path components) and reject raw strings
at the handler boundary. A regex/denylist over a raw query string is
bypassable through encoding, Unicode, or patterns the author didn't
anticipate — it is not a substitute for a structured parameter schema.
Translate these principles to the audited file's language, agent framework, and
tool-dispatch surface. Use the framework's documented approval / human-in-the-loop
hook — do not invent ad-hoc confirmation prompts inside the prompt template.
Verification
Confirm these properties hold regardless of language or framework:
References
