MCP security risks and mitigations

Who this is for and what you will be able to do

If you are building or running an MCP server that other people, or AI agents, can reach, you need to know which risks are specific to MCP and which controls the specification requires. This guide groups the risks by type, lists the controls for each, and points to the current specification. By the end you will be able to review an MCP server for the most common failures ^[1].

What changed in the 2026-07-28 specification

This guide combines the established controls with the authorization guidance of MCP 2026-07-28, and it asks readers to check the current specification and security best practices before writing security-sensitive code ^[1][2]. Two changes matter most. Clients must validate the iss parameter on authorization responses (RFC 9207), and they must bind registered credentials to the authorization server that issued them. Dynamic Client Registration is deprecated, and new implementations should use Client ID Metadata Documents ^[1].

The model has also moved on. Early specifications had MCP servers act as OAuth 2.0 authorization servers that managed user authentication themselves. The current standard lets an MCP server delegate authentication to an external identity provider, such as Microsoft Entra ID ^[1].

Authentication and token passthrough

Authentication decides who may connect. The MCP authorization specification explicitly prohibits token passthrough, which means accepting a client's token and forwarding it to a downstream API. The rule is mandatory: MCP servers MUST NOT accept any token that was not explicitly issued for the MCP server ^[1].

Passthrough causes several problems. It bypasses the rate limiting, request validation and traffic monitoring that depend on proper token validation. Downstream logs show misleading request origins. Unvalidated token claims let an attacker who holds a stolen token use the MCP server as a proxy for data exfiltration. Tokens accepted by several services allow lateral movement across them ^[1].

The required controls are to validate that the token's audience matches the MCP server's identity, and to use short-lived access tokens with secure rotation ^[1].

Prompt injection and tool poisoning

Indirect prompt injection happens when an attacker places malicious instructions in content the AI system reads, such as documents, web pages, emails or data sources. The system then treats those instructions as legitimate commands ^[1].

Tool poisoning attacks the metadata that describes a tool, including descriptions, parameter definitions and usage examples. An LLM uses that metadata to decide what to run ^[1]. A rug pull is a tool that the user approved, but which is later changed to do something malicious. Remote servers carry more risk because tool definitions can be updated after approval ^[1]. Its advice is to validate tool metadata and watch for changes to tools ^[1].

Microsoft AI Prompt Shields are a defense against direct and indirect prompt injection. It uses detection and filtering, spotlighting, delimiters and datamarking, and it is part of Azure AI Content Safety ^[1].

Session hijacking

A session hijack happens when someone obtains a valid session ID. With it, they can inject events into servers that share session state, or call the MCP server directly and bypass authentication ^[1].

The rules are that an MCP server implementing authorization MUST verify every inbound request and MUST NOT rely on sessions for authentication. Session IDs should be cryptographically secure and non-deterministic, and bound to the user, for example as <user_id>:<session_id>. They need expiration, rotation and invalidation. All communication must use HTTPS ^[1].

The confused deputy problem

An MCP server can act as an authentication proxy between a client and a third-party service. If it uses static client IDs, attackers can exploit existing consent cookies with crafted redirect URIs, and the authorization server may skip the consent screen and send the code to an attacker's endpoint ^[1].

The mitigations are mandatory. The server MUST obtain user consent for each dynamically registered client. It should use OAuth 2.1 with PKCE for every authorization request, and it should strictly validate redirect URIs and client identifiers ^[1].

Supply chain and least privilege

For AI systems, the supply chain includes foundation models, embedding services, context providers, third-party APIs, model artifacts and training data sources. Each should be checked for provenance, licensing and integrity before use ^[1].

Least privilege applies to the server too. Grant only the permissions it needs, review them regularly to stop privilege creep, and scope roles tightly to specific resources and actions ^[1].

Where to practice and what to check

The OWASP MCP Top 10 risks are listed, from MCP01 (token mismanagement and secret exposure) to MCP10 (context injection and over-sharing) ^[1]. For hands-on work, it recommends the MCP Security Summit Workshop (Sherpa), which runs a vulnerable, exploit, fix, validate method on intentionally insecure servers ^[1].

The foundations include dedicated vaults for tokens and API keys, input validation, multi-factor authentication for administrative and service accounts, and detailed logging of MCP client-server interactions ^[1].

Limits and common questions

• This is a survey of risks and controls. It is not a complete threat model, so review your own deployment against the current specification ^[1][2].
• Some controls depend on your identity provider or cloud platform, such as Microsoft Entra ID. Check how they apply to your setup ^[1].

Next step

The current security best practices are in the MCP specification ^[2]. The next chapter is Getting Started ^[1].

Adapted from the security lesson of Microsoft's open-source course *mcp-for-beginners*^[1], released under the MIT License.