MCP Security: Why Tool Allowlists Prevent the Confused Deputy Problem

The Incident

Your AI assistant has access to your filesystem, GitHub, Postgres, Slack, and AWS.

You ask:

Generate a weekly engineering report.

Ten seconds later it has also read your `.env`, cloned another repository, queried production, and uploaded secrets to an external endpoint.

Nothing was “hacked.”

Your AI simply used the permissions you gave it.

(Composite scene drawn from documented confused-deputy cases not a single CVE or named vendor breach.)

That is the confused deputy problem and it is how a large class of AI production failures actually start. The agent (or the MCP bridge behind it) holds privileged credentials. The model proposes tools. If the platform never decides which tools are allowed, “summarize this week” and “exfiltrate secrets” travel the same path.

Why existing thinking failed

For a year the industry’s default comfort story sounded like this:

- It’s only local stdio.

- We trusted the repo / the IDE prompt.

- The model usually refuses dangerous stuff.

- MCP will harden this in the next protocol revision.

That thinking fails for a structural reason: trusting the deputy is not the same as authorizing the act. Prompt policy is not an allowlist. A protocol handshake is not per-tool authorization. A human clicking “trust this folder” is not least privilege.

When teams bind an entire MCP tool catalog into a production agent (“filesystem + fetch + git + whatever else was in the sample JSON”) they create a privileged proxy that will happily do anything in its catalog that the model asks for. Attackers do not need to break cryptography. They need the deputy to stay helpful.

Research proves it

This week’s piece is a deep-dive, not a single named vendor breach but the evidence is no longer theoretical.

Wiz Research found MCP across a large share of cloud environments, with about one in six of those environments exposing at least one MCP server often still on a pre-auth protocol vintage, often returning full tool catalogs to anonymous callers, sometimes returning real data, and in a confirmed minority enabling SSRF toward cloud metadata credentials. A malicious tool call can look like a legitimate one: same embedded backend credential, no failed-login spike, no brute-force signature.

Endpoint-focused analysis (Backslash) cites the same archetype via AuthZed’s timeline: an agent asked to write a usage report also reads hundreds of unrelated files including secrets and exfiltrates them. Not because it was compromised. Because agency had no enforced allowlist.

And the calendar pressure is real. MCP 2026-07-28 moves the protocol toward enterprise, cloud-native, stateless operation. SecurityWeek, summarizing Akamai, reports that while some older session-hijack classes shrink, new surfaces appear where “security depends heavily on implementation quality”: portable handles, MCP-specific headers, MCP Apps UI, long-running tasks. Maxim Zavodchik of Akamai told SecurityWeek that critical boundaries are “entirely dependent on how developers implement them.”

Federal design baseline lands in the same place. The NSA Artificial Intelligence Security Center CSI (May 20, 2026), Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation, flags trust boundaries, dynamic tool invocation, and the need for authentication/authorization that traditional controls alone do not cover—the same AUTHN-M2 / TOL-M1 direction this article maps.

In other words: the latest MCP changes do not invent confused deputies. They make proper tool authorization non-optional because the protocol will not quietly paper over missing host gates.

Confirmed: Widespread exposed/unauthenticated MCP in the wild (Wiz); MCP 2026-07-28 enterprise/stateless framing and implementer-owned security (SecurityWeek / Akamai); NSA AISC MCP security design CSI (May 2026).

Reported: Handle/HTML/scope-gap narratives and vignettes (Backslash; AuthZed timeline as cited there).

Speculated: How any one reader’s host is configured—unknown without their inventory.

Engineering takeaway

If your model can call tools, you need a rule that predates LLMs: the model proposes; the platform disposes. Per-agent tool allowlists, server-side authz independent of model output, pinned MCP installs, and identity on every production MCP link. That is the rest of this article and the APRF Core map.

Why this matters

Anyone owning an agent host, IDE agent, or internal “chat with tools” gateway platform engineers, app security, and the team that pastes MCP JSON into Claude Desktop / Cursor and calls it done.

What class of systems: Agents + MCP + Tools. If your model can call tools, you are in scope. RAG systems that only retrieve documents are less directly hit unless retrieval is exposed as an MCP tool with write or broad SQL powers. Memory servers that persist graphs amplify blast radius when combined with open tool sets.

Can a startup ignore it? No, if you ship any agent with filesystem, fetch, DB, CRM, or shell-adjacent MCP. Maybe, if you have zero tool-calling agents and even then, inventory quarterly so a “temporary” MCP does not become prod by accident.

Wiz’s point lands hardest for startups: MCP describes itself (`tools/list`), speaks a generic client dialect, and often wraps privileged backends with baked-in credentials. That is confused-deputy architecture by default.

Timeline

Root Cause

The failure class is not “MCP is insecure.” It is agency without a platform disposal layer.

Classic confused deputy: the MCP server (or the agent host that forwards tool calls) holds powerful credentials or filesystem rights. The model proposes tool names and arguments. If there is no server-side authorization independent of model output, no per-agent tool allowlist, and no pin/review of which MCP servers are installed, then prompt injection, malicious tool descriptions, leaked handles, or simple over-broad configuration turn “help me summarize” into “read `.env` and POST it.”

MCP 2026-07-28 intensifies the lesson: when session affinity and Roots-style structural boundaries weaken or move, hosts that never built TOL-M1/TOL-M2 gates discover that the protocol will not save them.

APRF Lens

Under APRF 0.11.0 Core, this story sits primarily in Tool Safety, with Authentication, Supply Chain, and Observability in support. Relevant Check families:

- TOL-M1 / TOL-M2 / TOL-M3 / TOL-M4: authorize every invocation server-side; allowlist tools per agent; gate high-impact tools; schema-validate args

- AUTHN-M2: MCP/S2S machine identity; no anonymous production MCP

- SCI-M2: inventory, pin, and review MCP servers/plugins

- OBS-M1: request → model → tool → outcome linkage (the only place some abuses show up)

Standing caveat: APRF assessments can miss evidence. A repository is not the only source of truth. Runtime MCP host JSON, cloud IAM, secrets backends, vendor consoles, CI variables, production prompts, deployed MCP package versions, and human “just install this server” habits often never appear in git. Absence of a finding is not proof of readiness.

Abuse Path Analysis

- Path 1–2 (intended): same agent host + MCP catalog → `docs.read` / `search` → OK.

- Path 3 (abused): prompt inject rides the same host/MCP with no TOL-M2 deny → secrets/env → exfil.

- FloatingInstall → MCP: getting-started installs that float on `npx -y` / unpinned tags leave SCI-M2 evidence incomplete for any production host that copies that habit.

- Spec728 → AgentHost: implementer-owned handle/UI/scope controls; without gates, new surfaces expand the same deputy problem.

Abuse path confidence -> Medium: path shape is well supported by Wiz + spec commentary; any specific enterprise’s edges need their runtime inventory.

Standing caveat (again): APRF and this graph can miss runtime-only evidence. Repo scans do not see your internet-exposed MCP, your IDE trust prompts, or your production handle-binding rules.

Relevant Controls

Patterns from the MCP reference servers (not a production victim)

What we looked at: the official MCP reference servers repo @ `76d64c822f5125032f89eb71dbdb94e42b434821` (2026-07-29) steering-group educational examples for filesystem, fetch, memory, and related tools. This is protocol/reference tooling, not an affected customer AI product and not a claim that “MCP failed APRF.”

How we looked: a manual code/docs pattern review aligned to APRF 0.11.0 Check language. This was not a full APRF Auditor collect → score → `assessment.json` / HTML run.

Upstream README Confirmed: reference implementations, not production-ready. The fair question is only: if teams copy these patterns into a production agent host, which APRF evidence would still be missing?

Signals that map to this failure class (pattern evidence):

- TOL-M2 — partial pattern observed: The filesystem server implements real path allowlisting (`src/filesystem/path-validation.ts`, CLI allowed directories + MCP roots updates)—useful blast-radius control. That is still not a per-agent tool-name allowlist at the host.

- TOL-M1 / AUTHN-M2 — Not Demonstrated (for a prod host copying stdio demos): No independent tool-gateway authz layer or production MCP machine-identity inventory in-repo; stdio trusts the client process. Expected for a reference demo; blocking if mirrored as-is into prod.

- SCI-M2 — Not Demonstrated / needs further review (for production copy-paste): Getting-started docs illustrate `npx -y @modelcontextprotocol/server-`. Fine for local education. A production host still needs pinned versions, named owners, and recurring review—evidence that educational path does not supply. We are not asserting the upstream project “fails” SCI-M2 as a product.

- Demo footgun to quarantine in prod: `src/everything/tools/get-env.ts` returns `JSON.stringify(process.env)`—appropriate for teaching configuration, dangerous beside real secrets.

What would improve or protect a production agent host using these patterns: enforce TOL-M1+M2 at the agent host before binding any server; pin packages and complete SCI-M2 inventory; require AUTHN-M2 before any HTTP MCP; never ship `get-env`-class tools; gate filesystem writes (TOL-M3).

Limits / blind spots: We did not probe live internet MCP, customer OAuth, or IDE auto-exec configs. Runtime IAM, secrets stores, and deployed forks are outside this SHA. Review confidence: Medium — useful pattern evidence; reference servers ≠ production estate.

APRF may still miss critical evidence outside any repo. For this class, likely blind spots include: cloud IMDS exposure from fetch tools, gateway policies not in git, conversation-logged handles after 2026-07-28, and human-approved “trust this folder” MCP auto-start.

How to Prevent It

Immediate (24–72h)

- Inventory every MCP server (local + remote): owner, version pin, network exposure, auth mode, tool list, backend credential scope.

- Disable anonymous HTTP MCP; bind localhost-only where possible.

- Strip high-impact tools from prod agents (env dump, arbitrary SQL, shell, unrestricted write).

- Replace `npx -y` / `@latest` with pinned versions or vetted images.

30 days

- Deploy a tool gateway: TOL-M1 authz on 100% of invocation paths; TOL-M2 allowlists per agent; automated unknown-tool deny tests.

- Impact-tier tools (TOL-M3) with human approval or dual control.

- Egress allowlists for fetch-like tools; block link-local/metadata ranges.

- Turn on OBS-M1-style traces for tool calls; alert on new tool names and deny spikes.

Longer term

- Signed tool catalogs (TOL-M5) and recurring SCI-M2 reviews.

- Handle binding: handle + caller identity + expiry (post–2026-07-28).

- Policy for MCP Apps HTML (treat like third-party scripts).

- Contract tests that fail CI when a server widens tools without review (“rug pull” / tool shadowing).

Engineering Lessons

1. The model proposes; the platform disposes—prompt text is not an allowlist (TOL-M1).

2. Path allowlists ≠ tool allowlists—filesystem roots help; open tool catalogs still confuse the deputy (TOL-M2).

3. MCP that describes itself is wonderful for DX and terrible for unauthenticated internet exposure (Wiz + AUTHN-M2).

4. Floating MCP installs leave supply-chain evidence incomplete—pin, own, review (SCI-M2).

5. When the protocol goes stateless, security debt becomes visible—implementers own handles, scope, and UI (2026-07-28).

Could this happen to you?

You should read this if…

- ✓ You have agents

- ✓ You use MCP

- ✓ You expose tools to models

- ✓ You install MCP via `npx` / unpinned packages

- ✓ You store secrets in env vars on the same host as MCP

- ✓ You run fetch/SQL/filesystem MCP beside production credentials

If two or more apply, treat the Relevant Controls table as a gate checklist this week.

Continues in the APRF Incident Corpus

Related in this series:

- OpenAI / Hugging Face sandbox-escape — agency / containment

- AI API protection playbook — API / tool abuse

Map these Checks into a gated Core review with the APRF self-attest (questionnaire only—not evidence-backed certification), or run the open APRF Auditor skill against your own agent host for artifact-backed findings.

FAQ

Is inspecting the public MCP reference servers the same as assessing a breached product? No. That repo is official educational MCP server tooling, not a victim system. A manual pattern review can only show what hosts still owe under APRF if they copy those demos into production—it does not mean MCP “failed” a Core gate, and it was not a full APRF Auditor collect/score run.

Would a full APRF Auditor run on those reference servers “catch” confused-deputy risk in the wild? It could still surface missing host-level TOL-M1/M2 evidence and incomplete SCI-M2 habits for floating installs—while the README already says “not production-ready.” It would not prove your cloud estate is exposed (that needs runtime discovery such as Wiz’s). Prefer running the APRF Auditor skill against your agent host, not against the protocol examples alone.

What can APRF miss because evidence lives outside the repo? Live MCP reachability, OAuth bindings, IDE trust/auto-exec settings, conversation-stored handles, IMDS/egress reality, and whether humans pasted secrets into server env. Repo outcomes ≠ production readiness.

Is MCP 2026-07-28 “less secure”? Speculated framing we reject: blaming the spec alone. Better framing (SecurityWeek/Akamai): enterprise features move security decisions to implementers—hosts without allowlists and authz get hurt more visibly.

How is this different from the OpenAI/Hugging Face sandbox-escape story in our corpus? Related agency theme, different failure class: that entry centers sandbox/eval containment; this one centers tool allowlists / MCP deputy. See the sandbox-escape analysis and the API protection playbook.

Do gateways solve handle hijacking and MCP Apps? Not fully—Backslash’s architectural point is that some risks live on the endpoint/conversation. Pair gateway TOL controls with endpoint inventory and UI policy.

References

1. Kevin Townsend, New Enterprise-Ready MCP Specification Brings New Security Challenges, SecurityWeek.

2. Wiz Research, The Security Risks Hiding Behind Exposed MCP Servers.

3. Maya (Mayo) Pik, New MCP Spec Opens Three New Attack Surfaces, Backslash (May 28, 2026).

4. NSA Artificial Intelligence Security Center, Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation (CSI press release, May 20, 2026).

5. modelcontextprotocol/servers — reference MCP servers (Apache-2.0 / MIT); README production warning; SHA `76d64c8…`.

6. APRF 0.11.0 Check catalog — TOL-M1–M4, AUTHN-M2, SCI-M2, OBS-M1 (/aprf/spec/).