MCP Threat Model: Clients, Servers, Tools, Tokens, and Trust Boundaries
An MCP threat model for teams connecting LLMs and AI agents to tools, OAuth tokens, APIs, local servers, SaaS systems, and production workflows.
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.
Follow one tool call across both systems
An MCP client asks a server to perform an operation, and the server may use a different credential to reach a downstream service:
User
-> AI client / agent runtime
-> MCP client
-> MCP server
-> tool implementation
-> SaaS API / local resource / internal system
For one representative call, record the initiating user and tenant, the MCP audience, the downstream identity and the resource being accessed. Mark where each component validates authority. Then follow the response back into model context; returned text may influence the next call.
This exposes the review's main question: can one component use broader authority than the user or workflow should have? A server-only code review can miss the client behavior, credential configuration or downstream policy that answers it.
1. Identify The MCP Actors
Start by identifying every actor in the system.
| Actor | Description | Threat Model Questions |
|---|---|---|
| Human user | Person asking the agent to perform a task. | What identity, role, tenant, and permissions apply? |
| AI client | The application or assistant invoking MCP. | Is it trusted? Is it enterprise-managed? |
| MCP client | The protocol-facing component that talks to servers. | How does it authenticate and authorize requests? |
| MCP server | The service exposing tools/resources. | What tools and data does it expose? |
| Tool implementation | The actual code/API call behind a tool. | Does it enforce authorization independently? |
| Authorization server | OAuth or identity provider. | Are scopes, redirect URIs, and consent enforced? |
| Downstream service | SaaS app, database, filesystem, internal API. | What business impact can actions have? |
| Attacker-controlled content | Webpage, email, PDF, RAG document, tool output. | Can it influence the agent or tool call? |
Include attackers who cannot authenticate to the MCP server but can influence content 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:
| Flow | Boundary Concern |
|---|---|
| User prompt | Untrusted input entering model context. |
| System/developer instructions | High-trust instructions that must not be overridden. |
| Retrieved content | Potentially untrusted data entering context. |
| Tool metadata | Model-facing tool descriptions and schemas. |
| Tool parameters | Model-generated structured action. |
| Tool output | Data that may influence the next model step. |
| OAuth tokens | Credentials crossing between systems. |
| Session identifiers | State that can be hijacked or replayed. |
| Logs | Artifacts that may contain sensitive material. |
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.
| Question | Why It Matters |
|---|---|
| Does each MCP client receive explicit user consent? | Prevents one client from riding another client's authorization. |
| Are redirect URIs exact-match validated? | Prevents authorization-code theft or redirection. |
| Is OAuth state random, bound, and validated? | Reduces CSRF and authorization-flow manipulation. |
| Are authorization decisions per-client and per-user? | Avoids shared authorization across untrusted clients. |
| Are scopes narrowly defined? | Reduces damage if authorization is abused. |
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.
| Token Pattern | Risk |
|---|---|
| Broad service token | Agent gets organization-wide authority. |
| User OAuth token passed downstream | Token may reach systems outside intended trust boundary. |
| Long-lived API key | Compromise creates durable access. |
| Token visible to model context | Secret may be leaked or reused. |
| Token shared across users | Actions lose attribution. |
| Token stored in local MCP config | Endpoint compromise becomes cloud compromise. |
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.
| Tool Capability | Review Question |
|---|---|
| Fetch URL | Can it access internal IPs, localhost, link-local metadata, or cloud metadata endpoints? |
| Query API | Are destination hosts allowlisted? |
| Browse webpage | Can attacker-controlled pages influence later tool calls? |
| Read file | Are filesystem paths constrained? |
| Proxy request | Can headers, methods, or redirects be abused? |
| Connect socket | Are internal services reachable? |
Treat URLs, hostnames, file paths, and remote content as untrusted inputs to the MCP server.
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.
| Control | Requirement |
|---|---|
| Session IDs | Secure, random, non-deterministic. |
| Authentication | Sessions must not replace authorization. |
| Binding | Session state should bind to authenticated user identity. |
| Expiration | Session IDs should rotate or expire. |
| Event queues | Events should bind to user/session and be validated. |
| Resumable streams | Resumed events must be authorized and integrity-checked. |
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.
| Local Risk | Example Control |
|---|---|
| Filesystem access | Path allowlists and deny access to secrets. |
| Shell execution | Disable by default or strict command allowlists. |
| Environment variables | Prevent exposure of tokens and .env content. |
| Startup commands | Review executable, arguments and working directory; pin and verify package origin and version. |
| Localhost exposure | Bind safely, authenticate, defend against DNS rebinding. |
| Developer credentials | Separate agent tools from privileged developer secrets. |
| Supply chain | Verify server origin, version, and integrity. |
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.
| Field | Risk |
|---|---|
| Tool name | Ambiguous or misleading names may cause wrong selection. |
| Tool description | Can steer the model toward unsafe use. |
| Parameter schema | Loose schema allows unsafe values. |
| Defaults | Dangerous default behavior may be invisible. |
| Return data | Tool output may contain sensitive or instructive text. |
| Error messages | May leak secrets, IDs, paths, or policies. |
Use narrow, typed tools with explicit effects and independent authorization checks.
Test the modeled boundaries
Pair each permitted operation with a neighboring denial. Change the tenant, remove a required scope, revoke the grant or alter the downstream target. Record which component rejects the request and confirm that no unauthorized effect occurs.
For a local stdio server, inspect the launched process's filesystem, network and credential access rather than assuming HTTP OAuth applies. Test any legacy session or event-resumption path only where the deployed protocol profile exposes it. A session identifier must not substitute for authorization.
Also test shutdown with queued work. Record whether disabling a client, server or tool stops new requests, what remains in flight and how an operator establishes the final state.
Keep the model usable after a change
Maintain one diagram linked to the tool and credential inventory, tested scenarios and open findings. Each finding should name the authority crossed, prerequisites, observed result and correction. Store safe request fields or protected references; never include live tokens in the report.
The MCP review checklist adds a credential-lifecycle walkthrough and local revoked-token check. Update the model when a server, tool schema, credential, downstream permission or protocol revision changes.