Excessive Agency Is a Permissions Problem Wearing an AI Costume

Excessive Agency sits at LLM03 in the OWASP Top 10 for LLM Applications 2026 [1]. It is the entry that matters most to anyone running infrastructure, because unlike most of the list it is mostly about what you connected the model to, and only a little about the model itself.

That matters because it decides who fixes it. A hallucination is a model problem. A hallucination that drops a database table is a permissions problem.

The problem

An operations assistant is asked to clear disk space on a staging node. It has a shell tool, because that was the fastest way to make it useful. The credentials it runs under are the ones the platform team already had, because provisioning a new identity meant a ticket. It runs unattended, because a human approving every step defeated the purpose.

It interprets "clear space" generously and removes a directory that staging shared with something else. Nothing about the model malfunctioned. It did exactly what a shell tool with broad credentials and no confirmation step allows.

Every element of that outcome was decided before the model ran: what tools exist, what those tools can reach, and whether anything pauses before execution.

Why it's different with AI

Traditional software fails in ways you can enumerate. A script with rm -rf in it will run rm -rf when its conditions are met, and you can read those conditions. A model chooses at runtime from whatever you exposed, and the choice depends on text that may have arrived from outside your system.

OWASP separates that combination into three root causes, and each has a different fix.

The first is excessive functionality, where the model can call tools the task does not need: a summarising assistant with a shell tool, or a support bot with a delete endpoint because the API client happened to include one. Often nobody chose this; the tool list grew from what was convenient to wire up.

The second is excessive permission. The tools exist for good reasons but run with more rights than required, and this is where infrastructure teams find their own fingerprints. The agent inherits a service account built for a human operator, or runs on a node whose instance role can reach the whole account. The model asks for one table and the credential opens the database.

The third is excessive autonomy, where the action executes with nothing in the loop. Sometimes that is correct. Sometimes it means an irreversible operation happens because a probabilistic system reached a plausible conclusion.

The 2026 edition also connects this to agent-specific risks, where the same failure appears as Tool Misuse and as Identity and Privilege Abuse in the OWASP Top 10 for Agentic Applications [2]. The framing differs, but the underlying question is the same: what can this thing reach, and with whose rights?

What actually works

Take the fixes in order of how deterministic they are, because that is also the order of how much you can rely on them.

Give the agent its own identity. That means a dedicated principal instead of the platform team's account or the node's ambient role, so that what it did is attributable and what it may do is bounded independently of any human. On Kubernetes this is a dedicated ServiceAccount with its own RoleBinding rather than a namespace default. In a cloud account it is a role assumed explicitly, rather than an instance profile that everything on the box inherits.

Concretely, on Kubernetes the agent's pod should not run under the namespace's default ServiceAccount, which is the path of least resistance and the reason so many workloads hold more rights than anyone intended. It gets its own ServiceAccount, bound to a Role that names the verbs and resources it needs, in the namespace it needs them. If the agent talks to a cloud provider, it assumes a role explicitly rather than inheriting the node's instance profile, because an instance profile is shared with every other pod on that node.

The test is simple: if you cannot answer "which credential did the agent use, and what exactly does that credential permit" in under a minute, the identity is wrong regardless of how the tools are configured.

Default to read-only, and make write an exception with a name. Most agent tasks are retrieval. Where writes are genuinely needed, scope them to the specific resource rather than the service: this bucket prefix, this table, this namespace.

Restrict egress. An agent that can reach arbitrary hosts can exfiltrate whatever it can read, and prompt injection makes that a realistic path rather than a theoretical one. A network policy with an allow-list is deterministic and enforced regardless of what the model decides.

Require confirmation for the irreversible: deletion, payment, credential rotation, anything that leaves your boundary. Enforce it at the tool layer instead of in the system prompt. A prompt instruction is a request, and the same text channel that carries it can carry an instruction to ignore it.

Give it a stop, meaning something that suspends the workload and revokes the credential without a deploy. Scaling a deployment to zero stops new work but does not invalidate a token already in flight, so the stop has to include revocation to be real. Test it before you need it, and write down who is allowed to pull it, because a kill switch that requires finding the one person who understands it is not available at 3am.

The first four are infrastructure configuration. None require the model's cooperation, which is why they are worth doing first.

What doesn't work

Telling the model to be careful doesn't hold up. "Do not delete anything without asking" is an instruction competing with every other instruction in the context window, including any that arrived from a document the model was asked to read. At best it is a preference, and nothing enforces it.

One service account for the agent fleet makes every agent as privileged as the most privileged task any of them performs, and it destroys attribution when something goes wrong.

Approval workflows nobody reads are another weak spot. A confirmation step that fires forty times a day trains people to approve reflexively. The control works when it is scarce; if it fires constantly, the functionality scope is wrong.

Assuming read-only is safe is a mistake too. Read-only access against a store holding credentials, personal data or customer records is an exfiltration path. Least privilege applies to reads as well.

Treating the tool list as fixed lets it drift. Agent frameworks make adding a tool trivial, which means the surface grows without a decision being recorded anywhere. Whatever review you apply to new API endpoints should apply here.

Finally, don't confuse sandboxing with permission scoping. A container limits what the process can touch on the host. It does nothing about a credential inside that container which is valid against your production database. Both controls are worth having and neither substitutes for the other.

Where to start

• Write down every tool your agents can call, and who granted each one. The list is usually longer than anyone expects and the second column is often blank.
• Check what identity they run as. If it is shared with a human or inherited from a node, that is the highest-value thing to fix this quarter.
• Find the irreversible actions in that tool list and put a confirmation in front of them at the tool layer.
• Add an egress allow-list for anything running inference or agent workloads.
• Rehearse the stop. Suspend one agent, revoke its credential, and confirm it is dead. It takes ten minutes and turns an assumption into a fact.

Excessive Agency ranks where it does because agents moved into production. Infrastructure teams have been applying these controls for years. What is new is that the thing being constrained decides at runtime, which is exactly why the constraints have to sit outside it.

Sources

1. OWASP Top 10 for LLM Applications 2026, OWASP GenAI Security Project, published 3 August 2026: https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
2. OWASP Top 10 for Agentic Applications 2026, OWASP GenAI Security Project, published 9 December 2025: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/