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.
The Boundary
The Model Context Protocol is not just an integration convenience. It is a new trust boundary between AI systems and the tools, data, identities, APIs, files, and workflows they can reach.
An MCP threat model should answer one central question:
If an MCP client, server, tool description, token, session, local runtime, or model context is manipulated, what can the agent read, write, delete, send, execute, or leak?
Official MCP security guidance calls for review around authorization flows, confused deputy risks, token passthrough, SSRF, session hijacking, local MCP server compromise, and scope minimization.
Why MCP Needs Its Own Threat Model
Traditional application threat models usually start with users, APIs, databases, trust zones, and authentication boundaries.
MCP adds a new layer:
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:
| Asset | Why It Matters |
|---|---|
| MCP clients | They mediate the agent's access to tools and servers. |
| MCP servers | They expose capabilities and data to the AI system. |
| Tools | They define what the agent can actually do. |
| Tokens and credentials | They determine the real blast radius. |
| Tool output and context | They can feed back into future model behavior. |
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.
| 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? |
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:
| 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
Token passthrough is dangerous because it moves credentials into places they may not belong.
| 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? |
A safe MCP server should assume that URLs, hostnames, file paths, and remote content are attacker-controlled unless proven otherwise.
6. Threat Model Session Hijacking And Event Injection
MCP security guidance describes session hijacking as a scenario where an unauthorized party obtains a session ID and uses it to impersonate the original client. It also describes risks in stateful HTTP servers where malicious events can be associated with an existing session and later delivered to a legitimate client.
| 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 | Require signed/trusted configs. |
| 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. |
The safest tools are narrow, typed, explicit, and independently authorized.
MCP Threat-Model Checklist
| Area | Question |
|---|---|
| Inventory | Do we know every MCP client, server, tool, token, and downstream system? |
| Trust boundaries | Do we know where untrusted content enters model or tool context? |
| Authorization | Is authorization server-side, scoped, and per-user/per-client? |
| Tokens | Are credentials short-lived, least-privilege, and not model-visible? |
| Tools | Are tool schemas narrow, validated, and action-specific? |
| SSRF | Are fetch/connect tools constrained by allowlists and network controls? |
| Sessions | Are sessions non-authenticating, bound, random, and expiring? |
| Local servers | Are local filesystem, shell, and secret exposures constrained? |
| Logging | Can prompt, retrieval, tool, token, authorization, and action traces be reconstructed? |
| Kill switch | Can risky MCP servers or tools be disabled quickly? |
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.
| Deliverable | Description |
|---|---|
| MCP Architecture Diagram | Shows clients, servers, tools, auth flows, sessions, and downstream systems. |
| Trust-Boundary Map | Identifies where untrusted content, tokens, and tool outputs cross boundaries. |
| Tool Inventory Matrix | Lists tool capabilities, actions, permissions, and data touched. |
| Token Scope Review | Identifies overbroad OAuth scopes, service accounts, and token passthrough risks. |
| Local MCP Server Risk Review | Assesses endpoint, filesystem, command, and configuration risk. |
| Blast-Radius Reduction Plan | Prioritizes least privilege, sandboxing, auth hardening, and logging. |
Final Thought
MCP makes AI systems more useful because it makes tools easier to expose. That is exactly why MCP needs threat modeling.
Before deploying MCP into production, teams should be able to answer:
Which client can call which server, using which token, to invoke which tool, against which data, with which authorization, and with what audit trail?
If that answer is unclear, the system is not ready.
What TKOResearch Reviews
TKOResearch performs MCP & Tool-Use Blast-Radius Reviews for teams connecting LLMs and AI agents to production tools, SaaS systems, local resources, APIs, and sensitive workflows.