Executive Summary
MCP security is the protection of Model Context Protocol clients, servers, resources, prompts, tools, credentials, and users from unauthorized access or unsafe action. Because MCP connects AI applications to external capabilities, security must preserve the boundary between untrusted content, model reasoning, user authority, and tool execution.
What is MCP security?
MCP security is the protection of Model Context Protocol clients, servers, resources, prompts, tools, credentials, and users from unauthorized access or unsafe action. Because MCP connects AI applications to external capabilities, security must preserve the boundary between untrusted content, model reasoning, user authority, and tool execution.
An MCP deployment has several distinct trust decisions. A client chooses which server to connect to, a server authenticates and authorizes requests, tools act on downstream systems, and users may be asked to approve actions. Tool descriptions and returned content can influence model behavior, but they are not trusted policy. The official specification's security guidance highlights authorization risks including confused-deputy behavior, token passthrough, and session hijacking.
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 malicious or compromised server can provide deceptive tool descriptions or hostile returned content.
- 02Token passthrough can send credentials to a resource that was not their intended audience.
- 03Overbroad scopes can let a useful tool read or change far more than the task requires.
- 04Session identifiers exposed in logs, URLs, or weak transport can enable session hijacking.
- 05A client may present an action poorly, causing a user to approve something materially different from their intent.
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.
- 01Allowlist or verify servers and pin reviewed configuration where the operating model permits.
- 02Implement the MCP authorization flow correctly and validate token audience, issuer, signature, expiry, and scope.
- 03Do not accept or forward tokens that were not explicitly issued for the MCP server.
- 04Give tools narrow workload identities and enforce authorization again at the downstream resource.
- 05Show users the target, important parameters, data disclosure, and effect before consequential execution.
- 06Log connection, authorization, tool selection, approval, result, and security error without exposing secrets.
Enterprise application
Enterprises should treat MCP as an integration surface, not a trusted internal shortcut. Register server owners, deployment locations, tools, data classes, downstream identities, and approved clients. Separate development from production and tenants from one another. Review server code and dependencies, but also test runtime behavior and authorization. Central gateways can help with policy and visibility, provided they do not become an all-powerful token broker.
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.
- 01Inventory servers, clients, tools, owners, and downstream systems.
- 02Draw authorization, token, data, and user-consent flows.
- 03Threat-model confused deputy, token theft, malicious tools, and poisoned content.
- 04Constrain scopes, identities, networks, inputs, outputs, and action effects.
- 05Test denied paths, consent clarity, revocation, rotation, and failure handling.
- 06Monitor changes and maintain containment and credential-response procedures.
Frequently Asked Questions
Q.Is MCP itself insecure?
A.No protocol removes implementation and deployment risk. MCP defines interoperable behavior and includes security guidance; safety depends on correct authorization, constrained tools, trusted distribution, clear consent, and secure operations.
Q.Should an MCP server receive a user's existing access token?
A.Only through the protocol's intended authorization design and for the correct audience. The official guidance explicitly warns against token passthrough, which can bypass important controls and create confused-deputy risk.