Excessive agency

It appears in the OWASP Top 10 for LLM applications and grows with the shift to agents. An assistant that can only draft an email is annoying when compromised. One that can send it, or move money, is an incident.

The useful thing about the concept is that it locates the problem in the design rather than the model. Nothing about excessive agency requires the model to malfunction. A perfectly well-behaved system that has been handed broad permissions will faithfully execute a harmful instruction that reached it through prompt injection, and the resulting damage is bounded by what you granted, not by how good the model was. That reframing matters because it makes the risk tractable: you cannot guarantee model behavior, but you can absolutely constrain permissions.

OWASP splits it into three practical failure modes. Excessive functionality is the tool that does more than the task needs, such as connecting a read-only reporting assistant through a database account that can also write. Excessive permissions are the entitlements behind the tool, typically inherited from a service account nobody scoped down. Excessive autonomy is the absence of a human gate on actions that are hard to undo.

The remedies are ordinary access control, applied somewhere new. Scope tools to the narrowest capability that completes the job, give the system its own identity rather than borrowing a human’s or a shared service account’s, prefer read-only by default, and require approval for irreversible steps. Least privilege was always the answer; agents simply made ignoring it expensive.