Otto Support - Excessive Agency and Tool Privileges

TL;DR: AI agents handed more tools than the task requires have already wiped production environments, mass-deleted mailboxes, and dropped customer databases. This entry walks through what excessive agency looks like in practice and how per-session, role-aware tool registration can limit the blast radius when using agentic frameworks.

Our blog series opener introduced otto-support, the vulnerable Model Context Protocol (MCP) server we built as a CTF and laid out why local agents influence attack surface. This blog post focuses on what happens when we give modern AI agents too much power. As agents are increasingly connected to tools, services, and production environments, the real risk isn’t whether a single tool is vulnerable, but whether those capabilities can be combined in unintended ways.

What is Excessive Agency?

Excessive agency occurs when tools are accessible by default and agents can perform actions beyond what was intended. Every additional tool registered to a MCP server adds to the mesh of capabilities the agent can execute and increases the attack surface. The tool is there to accept input, and it functions as intended. The vulnerability is usually not in the tool's implementation but in the decision to make a series of tools available in the context of other capabilities that can result in unanticipated failure modes.

The problem extends beyond MCP servers. AI agents with broad tool access and production-level permissions have already caused significant damage in real environments. When an agent is given more capability than the task requires, the blast radius turns out to be larger than expected.

Case Studies

With the number of examples in this category, this is clearly a difficult problem to address.

Claude Code Deletes Club's Infrastructure (March 2026)

On March 6, 2026, Claude Code was configured with permissions to manage infrastructure at a cloud service provider through Terraform. During a session, the agent executed a Terraform command that took down the organization's infrastructure. The organization lost 2.5 years of data and automated snapshots were also destroyed by the actions the agent took.

AI Alignment Director's Email Agent (February 2026)

On February 24, 2026, an AI Alignment director was using an OpenClaw agent connected to her inbox. The agent began planning to mass-delete older emails and ignored her attempts to stop it from her phone. The system had lost sight of the prompt that required confirmation before destructive actions.

Internal AI Tool Causes 13-Hour Provider Outage (December 2025)

An AI development tool with production-level permissions caused a 13-hour outage. The tool determined that the best fix for a bug was to delete and recreate an entire live environment. The provider attributed both to "user error, not AI" but quietly added mandatory peer review for all production access afterward.

Major Online Retail Outage (March 2026)

A major retail site went down for approximately six hours and was described as a "software code deployment" error. An internal SVP later acknowledged that "GenAI tools supplementing or accelerating production change instructions" were "leading to unsafe practices." The company's own internal assessment stated that their GenAI safeguards "are not yet fully established."

Misconfigured Agents Deleting User Content (July 2025)

In July 2025, an AI agent lost control and deleted a company's entire database. In both cases, the agents had write access to production data and no guardrails preventing bulk destructive operations.

Exploitation

We built otto-support capture-the-flag (CTF) as a set of hands-on AI security challenges that simulate how modern AI agents interact with tools, internal services, and local environments.

In otto-support, excessive agency manifests through the tiered permission model and misconfigured tools. There are four different permission levels, all with different sets of tooling. The challenge begins from the perspective of an unauthenticated user with limited tools available which will grant authenticated access when invoked properly. Once authenticated, additional tools become available. Each of the tools has configured permissions and uses the SDK’s ability to perform per-call filtering that re-decides which tools are visible based on the session's current role.

Mitigations

Agents should receive the minimum set of tools required for the task at hand. Tool registration should be per-session and role-aware, not global. Frameworks like mcp-go provide WithToolFilter and per-session AddTool for this purpose. Vulnerabilities can manifest as a result of skipping those controls because it is easier to register everything at once.

Privileged tools need role checks in their handlers, not just in the tool filter. If a tool can mint tokens, change account ownership, execute system commands, or take other sensitive actions, it should require explicit human confirmation before proceeding. The confirmation mechanism needs to be separate from the agent's conversation context, because an agent that controls the confirmation prompt can confirm its own actions.

Production-level permissions should never be granted to an AI agent without a peer review requirement. The case studies demonstrate what happens when an agent has the same access as a senior engineer. Approval gates for destructive operations are not optional safeguards if security is top of mind.

Conclusion

Excessive agency is often invisible until something breaks. The systems still behave as designed, the tools execute as expected, and yet the outcome is far outside what anyone intended. As AI agents continue to take on more responsibility inside real environments, these kinds of failures become less about edge cases and more about systemic risk. In the next post, we’ll move from overexposure to direct exploitation by examining how vulnerabilities like SSRF and token passthrough allow agents to extend their reach into internal systems and operate with unintended authority.