MCP Threat Model: Clients, Servers, Tools, Tokens, and Trust Boundaries

An MCP connection joins at least two authority models: the client's decision to invoke a tool and the server's permission to reach a downstream system. The threat model needs to follow both. A narrowly worded tool description does not help if the implementation forwards requests with an unrestricted service credential.

This review is pinned to MCP 2026-07-28, the current revision listed by the official versioning page on September 9, 2026. Record the versions your deployment actually supports. Older handshake and session behavior remains relevant only where the implementation supports those earlier revisions.

Why MCP Needs Its Own Threat Model

Traditional application threat models usually start with users, APIs, databases, trust zones, and authentication boundaries.

MCP introduces a protocol client and server into the path:

User
  -> AI client / agent runtime
  -> MCP client
  -> MCP server
  -> tool implementation
  -> SaaS API / local resource / internal system

That chain matters because natural-language reasoning can now influence tool selection, parameter generation, authorization flow, and downstream business actions.

MCP threat modeling should focus on five assets:

If you only review the MCP server code and ignore the agent, tokens, tool descriptions, and downstream systems, the threat model is incomplete.

1. Identify The MCP Actors

Start by identifying every actor in the system.

The most important threat-model shift is this: the attacker may never authenticate to the MCP server directly. They may instead influence content that the AI system later ingests.

2. Draw Trust Boundaries

Every MCP deployment should have a trust-boundary diagram.

[User / tenant]
    -> [AI application]
    -> [MCP client]
    -> [MCP server]
    -> [Tool runtime]
    -> [External API / internal service / local machine]

Then mark the flows:

The failure mode usually happens at a boundary where the system treats untrusted content as trusted instruction or allows model output to become action without deterministic controls.

3. Threat Model Confused Deputy Behavior

A confused deputy problem occurs when one component is tricked into using its authority on behalf of an entity that should not have that authority.

MCP security guidance specifically identifies confused deputy risk in MCP authorization flows and discusses conditions involving proxy servers, authorization servers, static client IDs, and missing per-client consent.

The model should never be the party deciding whether a tool call is authorized. The model can request an action. The server must authorize it.

4. Threat Model Token Passthrough

For protected HTTP servers, distinguish the token issued for the MCP server from credentials the server uses with a downstream API. The 2026-07-28 authorization specification requires intended-audience validation and forbids accepting or forwarding unrelated tokens. OAuth scope still does not establish access to a particular tenant document.

A safer design uses short-lived, narrowly scoped, user-attributable credentials and keeps secrets out of model-visible context.

5. Threat Model SSRF And Network Reachability

MCP security guidance includes SSRF as a risk area and points implementers toward allowlist strategies, input validation, and network-level controls.

Review every tool that can fetch URLs, connect to hosts, inspect metadata endpoints, query APIs, or retrieve remote content.

A safe MCP server should assume that URLs, hostnames, file paths, and remote content are attacker-controlled unless proven otherwise.

6. Separate current request handling from legacy sessions

The 2026-07-28 transport overview defines a request-oriented protocol and describes backward compatibility with earlier connection-scoped sessions. Do not apply an old session diagram to a new deployment without checking its supported revisions.

The following checks apply to application session state and to legacy MCP session/event paths that the deployment still exposes. An application session or resumable event must never substitute for current authorization.

If a malicious event can alter tools, context, or model-visible state, session handling becomes part of the AI security boundary.

7. Threat Model Local MCP Servers

Local MCP servers are especially risky because they run near developer workstations, IDEs, local files, environment variables, browser sessions, source code, and secrets.

Official MCP security guidance warns that local MCP servers are binaries downloaded and executed on the same machine as the MCP client, and that attacks may include malicious startup commands, malicious payloads inside the server, or insecure local servers left running on localhost.

For enterprise use, local MCP servers should be treated like privileged endpoint software.

8. Threat Model Tool Descriptions And Schemas

Tool metadata is model-facing control surface.

The safest tools are narrow, typed, explicit, and independently authorized.

MCP Threat-Model Checklist

What A Useful MCP Threat Model Leaves Behind

The threat model should be concrete enough that an engineer can tighten permissions and an executive can understand residual risk without reading every line of code.

Turn each trust boundary into a test

Choose one representative call and trace the authenticated user, MCP audience, downstream identity, resource policy and returned fields. Repeat it with the wrong tenant, insufficient scope and revoked authorization. For a local stdio server, inspect the launched process's filesystem, network and credential access instead of assuming the HTTP OAuth flow applies.

The MCP review checklist adds a credential-lifecycle walkthrough and a local revoked-token check. Keep the threat model beside that inventory and update both when a server, tool schema, credential or protocol revision changes.

Sources

• Model Context Protocol Security Best Practices
• Model Context Protocol Authorization Guidance
• OWASP AI Agent Security Cheat Sheet