Tool permission design for agents, as Excessive Agency hits number 3

In the 2026 OWASP Top 10 for LLM Applications, published on 3 August 2026 according to the Cloud Security Alliance, Excessive Agency rose to third place from sixth. It is the largest upward move on the list. The cause is easy to guess: more teams now hand models real tools, and a model that can be talked into a bad call is only as dangerous as the tool behind it.

What's affected

Any agent, copilot or workflow where a model can trigger an action: sending email, writing files, opening pull requests, calling internal APIs, running shell commands. The risk is the gap between what the task needs and what the tool allows.

The MCP specification's 2026-07-28 revision describes the same gap for tokens. Its scope minimization section warns that publishing every scope up front, or using wildcards such as *, all or full-access, means a stolen token carries a wide blast radius. NIST's NCCoE concept paper on agent identity (February 2026) asks the open question directly: how do we establish least privilege for an agent whose required actions may not be fully predictable at deployment?

What to do now

1. Write one tool per task, not one tool per system. create_draft_reply is safer than gmail_api with a method argument. Narrow tools are easier to scope and to review.
2. Split read tools from write tools. Give the agent read access by default and add write tools only for workflows that need them.
3. Scope the credential, not just the prompt. An instruction saying "do not delete" is a request. A token without delete rights is a control.
4. Start with a minimal scope set and step up. The spec suggests a small baseline of low-risk read operations and targeted elevation when a privileged call is first attempted. Log each elevation.
5. Require a human decision for irreversible actions. Sending external messages, moving money, deleting data and changing permissions should wait for approval. The MCP tools page says there should always be a human in the loop with the ability to deny invocations.
6. Check permissions at call time. CSA's note recommends validating tool-permission scope at invocation time, using the identity of the person the agent acts for, not a shared service account.
7. Cap volume. Rate limit tool calls per run and per user so a loop cannot do damage at machine speed.
8. Treat tool metadata as untrusted. The spec says clients must consider tool annotations untrusted unless they come from trusted servers.

A quick review template for each tool: what it can read, what it can change, whose identity it runs as, what approval it needs, and what the worst call looks like. If the worst call is unacceptable, narrow the tool before you add a guardrail.

Quick check

Sources

• Cloud Security Alliance: OWASP's 2026 LLM Top 10 and the Agent Control Standard
• Help Net Security: OWASP 2026 LLM Top 10 released
• MCP specification: security best practices, scope minimization
• MCP specification: tools
• NIST NCCoE concept paper: software and AI agent identity and authorization (February 2026)