Least-Privilege Tool Use for AI Agents

Advanced

Give the agent a scalpel, not the master key

01 The Concept

When an LLM can call tools — read files, hit APIs, run code, send emails — a successful prompt injection stops being an embarrassing text output and becomes a real action with real consequences. "Excessive agency" is significant enough as a risk that it made OWASP's LLM Top 10 as its own named category: granting an agent more autonomy, tool access, or permission than its actual task requires. Least privilege is the core mitigation: each tool the agent can call should have the narrowest possible scope, and the agent's overall permission set should be the minimum needed for its actual job, not the maximum available in the underlying system.

Concretely: a customer-support agent that can look up order status doesn't need write access to the orders table. A coding agent that can read a repo to answer questions doesn't need push access to production branches. Scope tools narrowly, and require a separate, non-LLM-controlled confirmation step for any action with real-world consequences (refunds, deletions, sending money).

02 Case Study

CASE"Excessive Agency" (LLM06), OWASP Top 10 for LLM Applications working-group rationale

The OWASP working group gave this failure mode its own named category specifically because it kept showing up across unrelated real deployments in the same shape: a team wires an LLM agent up to a tool — a database, a file system, an email sender, a code repository — and grants it broader access than the actual feature needs, usually because it's more convenient during development to reuse an existing broad credential than to provision a narrow one. The category's write-up frames it plainly: the risk isn't that the model will maliciously decide to misuse that access, it's that once a successful prompt injection occurs, the blast radius is defined by the permissions the agent was already holding, not by anything the injection itself has to additionally unlock.

→ Why it matters

OWASP's framing makes the fix obvious once it's named: excessive agency isn't a model behavior problem to train away, it's a permissioning decision made at design time — scope every tool to the narrowest access the actual task requires, before a single line of the agent's prompt is even written.

03 Key Points

01"Excessive agency" is its own named risk category in the OWASP LLM Top 10

02Tool access should match the agent's actual job, not the maximum available system permission

03A successful injection against an agent with broad tool access becomes a real-world action, not just bad text

04High-consequence actions need a non-LLM-controlled confirmation gate, not just a well-worded prompt

Next: Sandboxing Code Execution and Tool Calls →