Haxoris Wiki

LLM03: Excessive Agency (Agentic Tool Chains, Delegated Authority)

How LLM03: Excessive Agency (Agentic Tool Chains, Delegated Authority) works

Excessive agency is the gap between what an agent is asked to do and what its tooling permits it to do. OWASP splits it three ways: excessive functionality (tools exposing operations the task never needs), excessive permissions (a tool holding broader mailbox, database or cloud rights than the caller), and excessive autonomy (irreversible actions taken with no independent verification). Each is an integration flaw, and each turns a text-level manipulation - usually the indirect injection covered in the LLM01 pages - into a real state change: a sent email, a merged pull request, a paid invoice.

The surface is the tool layer: MCP servers, OpenAPI plugin manifests, LangChain and LlamaIndex wrappers, IDE and desktop agents with shell access, browser and computer-use loops, and orchestrators handing tasks between agents holding different OAuth connector tokens. The 2026 edition promoted this category from LLM06:2025 to LLM03, the largest climb in the list, on agentic deployment and incident data. The retired LLM07:2023 Insecure Plugin Design entry was folded into this category by the 2025 edition, so tool schema design, parameter validation and per-tool authorization are tested here.

Keywords: excessive agency, agent tool permissions, insecure plugin design, human approval bypass, multi-agent delegation, confused deputy

Examples/Proof

  • Overbroad tool schema
    • Call tools/list and count state-changing tools. A run_shell, http_request or execute_sql tool with a free-text parameter proves excessive functionality regardless of prompt-level guardrails.
  • Tool permission exceeds caller permission
    • Have a read-only user drive a tool that writes. If the write lands, the tool is using an ambient service credential, not the caller’s identity.
  • Approval gate covering only one call
    • Induce two tool calls in one turn where only one name is on the interrupt list. If the unlisted sibling executes, the gate is per-name, not per-turn.
  • Delegation across a privilege boundary
    • Submit a task as a low-privilege agent and see whether a higher-privilege sub-agent runs it. A canary written under the orchestrator’s service principal proves a confused deputy.

Detection and Monitoring

  • Tool-call audit trail with identity
    • Log tool name, arguments, end-user identity, the credential used and the approval decision. Alert when credential subject differs from session subject.
  • Tool inventory diffing
    • Snapshot tools/list and plugin manifests per release; alert on new or renamed tools, widened schemas and duplicate names.
  • Approval telemetry
    • Compare approvals granted against write actions executed; a persistent deficit means consent is reused or skipped.

How to fix and prevent LLM03: Excessive Agency (Agentic Tool Chains, Delegated Authority)

  1. Least functionality per tool
    • Replace open-ended tools with narrow ones: write_invoice_note instead of run_sql. Remove unused operations.
  2. Enforce authorization at the tool server
    • Propagate end-user identity into every call and re-check it server-side. Scope OAuth connectors read-only where possible.
  3. Bind approvals to the action, not the session
    • Gate on resolved arguments and expire consent per call.
  4. Preserve caller scope across hand-offs
    • Carry a signed authorization context through sub-agent and A2A delegation; intersect rather than union privileges.
  5. Contain what gets through
    • Sandbox file and shell tools, allowlist egress hosts, rate limit per tool, and stage destructive operations.

Prevention Checklist

  • Every declared tool has a least-privilege scope and no free-text execution parameter
  • State-changing tools re-authorize the end user server-side, not just at the chat layer
  • Approval prompts show resolved arguments and cannot be satisfied by the agent itself
  • Sub-agent and peer hand-offs never widen the caller’s privileges
  • Tool arguments and approval decisions are logged with the acting identity

In this section

Last updated

References