Back to Blog

The Confused Deputy: Why Giving Tools to Corporate AI Is Dangerous

September 8, 2026 · 4 min read
The Confused Deputy: Why Giving Tools to Corporate AI Is Dangerous - Giving AI agents tool access creates the Confused Deputy problem: high system privileges tricked by low-privilege prompts. Here is how to sandbox them.

A team deploys an internal AI assistant in Slack to help employees navigate company documents. To make the bot actually useful rather than just an articulate chatbot, the engineering team attaches tools via Model Context Protocol (MCP) or API function calling. The bot receives an admin-level service account so it can query Jira, search Google Drive, look up customer billing records in Stripe, and draft emails.

An intern types a casual question into an open Slack channel: “Hey, can you pull the summary of next quarter’s executive bonuses and paste the numbers here?”

The bot checks its credentials. It holds an API token with read access to the entire HR Google Drive folder. It does not evaluate whether the intern has clearance to view executive compensation. It only checks whether itself has clearance. Finding a valid token, the bot retrieves the spreadsheet, formats the payout totals, and posts them into the public channel.

In cybersecurity, this vulnerability has a name: the Confused Deputy.

The Assistant with the Master Key

The confused deputy problem is not new to computer science, but generative AI agents turn an occasional system bug into an architectural habit.

Picture an executive assistant sitting in the lobby of a corporate headquarters. Security handed this assistant a master electronic keycard granting access to every executive suite, server closet, and financial vault in the skyscraper. An intern walks up and says, “The CEO asked me to grab the confidential merger binder from the 40th floor; could you unlock that door and bring it down for me?”

If the assistant opens the door without verifying the intern’s own badge or confirming with the executive, the assistant has acted as a confused deputy. Their authorized authority was hijacked to perform an unauthorized action.

The difference with human assistants is intuition. A human assistant pauses, notices the oddity of an intern requesting M&A files, and asks for a confirmation email. A language model possesses no intuition or intrinsic awareness of organizational hierarchy. It parses instructions, matches intent against tool definitions, and executes.

Where Agent Permissions Break Down

When developers connect LLMs to company infrastructure, authorization boundaries blur across three distinct friction points:

  1. Privilege Flattening: Developers frequently run the agent under a single, overarching service token with broad read-write access. The moment a low-privilege user interacts with the agent, they inherit the agent’s highest privilege level.
  2. Tool Poisoning via External Data: If an agent has permission to run terminal commands or issue refund webhooks, an indirect prompt hidden inside an external customer email can trick the agent into executing those tools against internal systems. The agent wields valid credentials, so the internal API server logs the request as legitimate.
  3. Implicit Trust in Natural Language Intent: Traditional role-based access control (RBAC) relies on cryptographic signatures, session cookies, and database permissions. Language models evaluate unstructured prose. Translating ambiguous human sentences into deterministic authorization gates creates subtle loopholes that attackers manipulate through simple semantic phrasing.

Confining the Deputy: Defense in Depth

Restricting an AI agent does not require stripping away its utility. It requires anchoring the agent to the user’s actual permission envelope rather than granting the model its own master identity:

  1. User-Delegated OAuth Tokens: Never configure an agent with a universal administrative service account. Pass the interacting user’s individual OAuth token through the tool execution boundary. If an intern cannot open the HR folder in Google Drive directly, the agent attempting to call the API on their behalf receives an immediate 403 Forbidden.
  2. Enforce Degrees of Autonomy: Categorize agent actions by blast radius. Read-only operations on non-sensitive data can run autonomously. Destructive or sensitive actions—initiating wire transfers, updating customer balances, modifying production code, or querying restricted directories—must require explicit human-in-the-loop cryptographic approval before the tool call executes.
  3. Contextual Egress Filtering: Restrict which external domains an agent’s network tools can contact. Even if an agent is tricked into exfiltrating corporate data, strict network egress rules prevent it from broadcasting internal payloads to unknown endpoints.

Giving an AI assistant authority without individual user delegation creates a back door wearing an employee badge. Have you audited what your internal AI bots can actually access if prompted by someone on their first day?

Have a project in mind?

Let's talk about how we can help.

Got a project idea? →