Excessive agency is a named, well-understood failure mode

The OWASP Top 10 for LLM Applications lists excessive agency as one of the core risks in systems that let a model call functions or interface with other systems through extensions. OWASP traces it to three root causes: excessive functionality, where a tool can do more than the workflow needs; excessive permissions, where a tool has broader access to downstream systems than the task requires; and excessive autonomy, where the system acts without enough human oversight for the impact of the action.

None of those three causes are about model quality. They are about how a team wired up the tools around the model. A workflow can use a strong model and still be exposed if the database credential behind it can delete rows, or the email tool can message any address instead of a scoped list, or the CRM integration can write to any account instead of the one tied to the current case.

Match each tool's access to the narrowest task it performs

OWASP's own example is direct: an agent that looks up product information only needs read access to a products table, not the ability to insert, update, or delete rows. The same logic applies to almost every integration in a business workflow. A tool that drafts a reply from a support ticket needs read access to the ticket and knowledge base, not write access to the ticketing system's status field.

Start by listing every tool the workflow can call, in plain language: what system it touches, what it can read, and what it can change. For each one, write down the smallest permission that still lets the workflow do its job. Where a broader credential already exists because it was convenient to reuse, replace it with a scoped one before the workflow goes live, not after an incident.

  • Name every tool and the system or API it calls.
  • Record what each tool can read, and separately, what it can write.
  • Replace shared or admin-level credentials with scoped ones per tool.
  • Document who owns each credential and how it gets rotated.

Separate read, draft, recommend, and write into distinct permission tiers

A workflow that can research a case should not automatically be able to close it. Treat retrieval, drafting, recommending an action, and writing that action back as four different permission tiers, and require an explicit design decision before a tool moves from one tier to the next.

This tiering is also what makes human review meaningful. If the review step sits between a recommendation and a write-back that uses its own scoped, time-limited credential, an approval failure or a bypassed check still cannot reach the underlying system with more authority than the reviewer intended. If the same broad credential is available earlier in the pipeline, the review step is easier to route around, whether by a bug, a bad prompt, or a tool call that gets triggered out of order.

Apply established access-control practice, not AI-specific improvisation

The idea of least privilege is not new. AWS's Well-Architected Framework defines it plainly for any system: identities should be permitted to perform only the smallest set of actions necessary to complete a specific task, using group and attribute-based policies rather than broad, standing access. The framework's implementation guidance, built for cloud infrastructure, transfers directly to AI tool design: base permissions on how a tool is actually used, remove access it does not exercise, and review the full set of grants on a schedule rather than only at initial setup.

The same discipline appears in the NIST AI Risk Management Framework, which asks organizations to build trustworthiness considerations, including access and use constraints, into the design and deployment of AI systems rather than treating them as controls added after a build is finished. Treating tool permissions as a governance artifact, reviewed on the same cadence as any other system account, keeps a workflow's actual access in line with what it was designed to do as the workflow itself changes.