Excessive Agency in the OWASP 2026 Top 10: what it means for AI agents

On 1 September 2026 the OWASP GenAI Security Project announced the 2026 edition of its Top 10 for LLM Applications, with Excessive Agency ranked third. In the same announcement it said the Agent Control Standard, an open standard for transparency and control of enterprise AI agents, had been donated to the project to extend its guidance toward runtime enforcement. This note covers Excessive Agency as it applies to agents on employee devices; read OWASP's own text for the full list.

The risk is usually described through three roots. Excessive functionality: the agent can call tools it does not need, such as a shell when it only needs to read files. Excessive permissions: the tools it calls run with broader access than the task needs, such as a developer's full cloud profile. Excessive autonomy: it takes high-impact actions without anyone confirming them. Any one of the three turns a wrong or manipulated decision into a real action.

Excessive Agency and prompt injection are separate entries, but they compound each other. Injection is how an attacker gets an agent to want something; excessive agency is what lets the agent do it. Reducing agency is the part a security team controls directly, because it does not depend on the model recognizing an attack. Our lesson on indirect prompt injection covers the other half.

A coding agent on a laptop inherits the developer's access: source code, local credentials, cloud CLI profiles and every MCP server configured for it. Each MCP server adds tools, and the MCP security best practices page notes that a local server runs with the same privileges as the client. On a typical developer machine, all three roots are present unless someone removes them. Bay's research on indirect prompt injection sums the conditions up as "broad tools, broad credentials, weak approval".

• Functionality: an allow list of MCP servers and tools per team, and managed settings that stop users adding their own. See managed settings and hooks.
• Permissions: scope minimization for MCP clients, which the MCP specification recommends, and keeping production credentials out of reach of agents that do not need them.
• Autonomy: an ask answer for high-impact actions, such as package installs and cloud CLI commands, so a person confirms them. The MCP tools specification says there should always be a human in the loop with the ability to deny tool invocations.
• Across all three: a record of each action that separates the agent from the person, so overreach can be seen and rules tuned. See the agent activity record.

Three of our seven criteria line up with these controls. Tool-call control, weighted 20%, measures whether a product can evaluate and stop an individual action before it runs. Policy granularity, weighted 15%, measures whether rules use context and offer answers such as ask, warn or mask. Identity and audit, weighted 12%, measures whether the record separates agents from people. On tool-call control the highest score in this guide belongs to Bay (9 out of 10). See the rankings, or change the weights in the score calculator.

• Can we restrict which MCP servers and tools each team's agents may load?
• Can a rule ask the user before a high-impact action, and show the exact command?
• Can we run rules in simulation before enforcing them?
• Does the record show whether a person or the agent chose each action?
• Do you plan to support the Agent Control Standard?

• Allow, ask or deny policies
• Lesson: indirect prompt injection
• Buyer's checklist
• Glossary

• OWASP GenAI Security Project announcement, 1 Sep 2026 · Reviewed Sep 2026
• OWASP Agent Control Standard · Reviewed Sep 2026
• MCP Security Best Practices · Reviewed Sep 2026
• MCP tools specification · Reviewed Sep 2026
• Bay, Ghostjacking · Reviewed Sep 2026