Executive Summary
An MCP threat model describes the assets, actors, trust boundaries, abuse paths, and controls in a specific Model Context Protocol deployment. Its purpose is not to label every MCP server dangerous. It identifies where content or identity crosses a boundary and how an attacker could turn that crossing into data access or action.
What is MCP threat model?
An MCP threat model describes the assets, actors, trust boundaries, abuse paths, and controls in a specific Model Context Protocol deployment. Its purpose is not to label every MCP server dangerous. It identifies where content or identity crosses a boundary and how an attacker could turn that crossing into data access or action.
Start with a diagram showing the user, host application, MCP client, each server, authorization service, tool implementation, downstream APIs, data stores, and administrative channel. Mark who operates each component and where credentials exist. Separate instructions set by the application from descriptions and results supplied by a server. Include installation and updates, because a legitimate server or package can later be compromised.
Concrete risks
Risk depends on the deployment, its data, its authority, and the consequences of failure. These scenarios are practical starting points for a system-specific assessment, not a claim that every implementation has the same exposure.
- 01A deceptive tool name or description can steer selection while concealing the true effect.
- 02Returned documents may contain indirect prompt injection that asks the model to reveal data or invoke another tool.
- 03OAuth redirection or client registration mistakes can support consent phishing or credential interception.
- 04A server can become a confused deputy if it accepts a token for one audience and uses it against another service.
- 05A compromised update, dependency, container, or publishing account can change a previously reviewed server.
Security controls
Controls should be layered so one model error, compromised component, or operator mistake does not directly become a material incident. Each control needs an owner and evidence that it works in the deployed configuration.
- 01Establish server provenance and protect publishing, signing, deployment, and update channels.
- 02Treat tool metadata and returned content as untrusted data, never as higher-priority policy.
- 03Bind authorization requests to the expected server and validate redirect URIs, state, PKCE, audience, and scopes.
- 04Require explicit confirmation when a tool sends sensitive data or causes an external side effect.
- 05Validate schemas and business rules at the tool boundary rather than relying on model-generated arguments.
- 06Create detections for new servers, scope changes, unusual tool sequences, repeated denials, and abnormal data volume.
Enterprise application
Threat modeling works best as a short, evidence-producing design activity. Engineers bring the actual flow, identity specialists review authorization, data owners identify sensitive fields, and security challenges attacker paths. Rank scenarios by plausible preconditions and business effect. Link mitigations to tests or operational evidence. Revisit the model when adding a server, tool, scope, data source, authentication method, or high-impact use case.
Alexa Cybersecurity editorial checklist
The following framework is an original editorial synthesis by the Alexa Cybersecurity Editorial Team. It is intended to help teams structure a review. It is not a standard, certification, benchmark, or field-tested research result, and organizations should adapt it to their systems, obligations, and risk appetite.
- 01Identify protected data, credentials, actions, sessions, and configuration.
- 02List external, insider, supplier, and compromised-component actors.
- 03Mark every content, identity, network, and approval boundary.
- 04Write abuse paths with precondition, action, consequence, and observable signal.
- 05Assign preventive, detective, and recovery controls to material paths.
- 06Validate controls and retain unresolved assumptions as explicit risk.
Frequently Asked Questions
Q.Is tool poisoning the same as prompt injection?
A.They can overlap. Tool poisoning manipulates tool metadata or behavior, while prompt injection uses hostile instructions in content. A poisoned tool can deliver prompt injection, misrepresent its action, or behave maliciously without relying on prompt text.
Q.What is the most important MCP trust boundary?
A.There is no universal single boundary. Authorization between user, client, and server and execution between server and downstream tool are commonly critical, but the answer depends on the data and action authority in the deployment.