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).
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.