Your Agent Has a Confused Deputy Problem

The demo that should scare you isn't the one where the agent fails. It's the one where it succeeds — books the meeting, queries the database, files the ticket, all flawlessly — and you realize it did all of that holding its credentials, not the user's. That gap, between who asked and whose authority got used, is the oldest bug in security wearing a brand-new outfit. It's called the confused deputy, and in 2026 it's the thing I'd lose sleep over before I'd worry about which model is smartest.

We spent the last year teaching agents to call tools. Most of us spent roughly none of that year teaching them to call tools safely. Now the bill is coming due, and the numbers are not subtle. The MCPTox benchmark tested 45 live MCP servers and 353 real tools against poisoned descriptions and found attack success rates above 60% on many popular agents, topping out at 72% (ITECS). The Coalition for Secure AI published an MCP security whitepaper in January mapping 12 threat categories and nearly 40 distinct threats (cyberdesserts). This is not a theoretical frontier anymore. It's a documented attack surface with a body count.

Two failure modes worth naming

I want to be concrete, because "AI security" as a phrase is so broad it's useless. Two specific things are happening.

The first is tool poisoning. An MCP tool advertises itself with a description the model reads to decide when and how to use it. Poison that description — through a compromised server, a malicious third-party tool, a supply-chain swap — and the model believes it's calling search_documents while the tool quietly exfiltrates whatever it can reach (Checkmarx). The model isn't hacked. It's lied to, and it has no way to tell. The instruction lives in data the model was told to trust.

The second is the confused deputy proper. Your MCP server connects to your CRM, your file store, your internal APIs, and it holds the credentials to do so. A user — or a prompt-injection payload riding in on a document that user pasted — asks the agent to do something it shouldn't. The server executes with its own elevated privileges, not the requesting user's scoped permissions (Aptible). The agent becomes a deputy that can be talked into using a badge that was never meant for the person doing the asking.

Both have the same root cause. We built agents that treat the instruction stream and the data stream as one thing. Everything the model reads — your prompt, the tool's description, the contents of the email it's summarizing — arrives as text it's inclined to act on. Decades of security engineering went into separating code from data. Agents quietly merged them again.

What actually reduces the blast radius

The good news is that the highest-leverage controls are boring, enforceable, and don't depend on the model getting smarter. None of this requires a frontier model or a research team. It requires treating an agent like the privileged service it is.

Start with a per-agent tool allowlist. Each agent runs only against the specific MCP servers and tools it has been explicitly approved to use, and a new tool requires review before it reaches production (ITECS). This single control breaks most tool-poisoning attacks, because the poisoned tool never makes the list. It's the firewall rule of the agent era, and most teams haven't written theirs.

Next, kill the confused deputy by scoping down, not up. The agent should act with the requesting user's permissions, not a fat service account that can read everything. If the user can't see the salary table, the agent acting on their behalf can't either. Token exchange, on-behalf-of flows, per-request scoping — this plumbing is unglamorous and it's most of the actual security work. The platforms have started shipping the building blocks; the discipline to use them is on you.

Then treat tool descriptions and retrieved content as untrusted input, because they are. Pin tool definitions so they can't change underneath you without review. Sandbox what tools can reach. Assume any document an agent ingests may contain instructions aimed at the agent, and design so that a malicious instruction in a PDF can't escalate into an action with real authority.

Finally, log every tool call and make the log someone's job. Invocations, arguments, which credential was used, what came back. When an agent does something wrong — and it will — an audit trail is the difference between a contained incident and a forensic mystery. This is also exactly what gets your security team to say yes in the first place.

The takeaway

If you're putting agents into production this year, the question that matters isn't "is the model good enough." It's "what can this thing do when something it reads tells it to misbehave, and whose authority does it use to do it." Write the per-agent allowlist. Scope agents to the user, not to a god-mode service account. Treat every tool description and ingested document as hostile until proven otherwise. The model will keep getting smarter; the confused deputy will keep being confused. Design for the deputy.

This is a security topic — if you're hardening real systems, treat the controls here as a starting point and bring your security team in early, not at launch review.

Sources: AI Agent Security Risks 2026 — cyberdesserts · MCP Tool Poisoning — ITECS · MCP Security Risks & Controls — Checkmarx · MCP Prompt Injection — Aptible