MCP Security Guide: Model Context Protocol Risks

The Model Context Protocol (MCP) has become the standard way to connect AI agents to tools and data. Every connection it creates is also an identity and trust decision. An MCP server exposes tools an agent can call, often holding credentials to the systems behind them. An MCP client decides which servers to trust and passes tokens to them. Get either side wrong and an agent can be steered into misusing tools, credentials can leak or be replayed, and a single malicious server can reach everything the agent can. This guide is a practitioner's view of MCP security: how the protocol handles authorisation, where the real risks sit, and the controls to put in place for local servers, remote servers and the credentials between them.

Key takeaways

MCP connects hosts (AI applications), clients (connectors inside the host) and servers (which expose tools, resources and prompts). Security depends on all three.
For remote servers over HTTP, the MCP authorisation specification builds on OAuth 2.1: servers act as OAuth resource servers, publish Protected Resource Metadata (RFC 9728), and must only accept tokens issued for them. Token passthrough is forbidden.
Authorisation is optional in the specification, and local (STDIO) servers take credentials from the environment. Many real deployments therefore rely on static API keys in configuration files, which is where most exposure starts.
Treat tool descriptions and server metadata as untrusted input. They are read by the model and can carry instructions.
Govern MCP servers like any third-party integration: an approved list, a named owner, least-privilege credentials, and monitoring.

How MCP works, briefly

MCP uses JSON-RPC 2.0 messages between three roles:

Host: the AI application the user works in, such as an IDE, a desktop assistant or an agent platform.
Client: a connector inside the host that maintains a connection to one server.
Server: a service that offers tools (functions the model can call), resources (data and context) and prompts (templated workflows). Clients can also offer features back to servers, such as elicitation, where a server asks the user for more information.

Servers run either locally, launched by the host and communicating over standard input and output (STDIO), or remotely, over HTTP. The two have very different security models.

MCP was created by Anthropic and was contributed to the Linux Foundation's Agentic AI Foundation (AAIF) in December 2025. The specification is versioned by date; at the time of writing the current revision is dated 28 July 2026. Check the latest specification before relying on specific requirements, as details change between revisions.

The MCP authorisation model

For HTTP-based servers, the MCP authorisation specification defines how a client obtains and uses access tokens. The key requirements in the current revision are:

OAuth 2.1 roles. A protected MCP server is an OAuth 2.1 resource server; the MCP client is an OAuth client; a separate (or co-located) authorisation server issues tokens.
Discovery. MCP servers must publish OAuth 2.0 Protected Resource Metadata (RFC 9728) pointing to their authorisation server, and clients must use it. When a client calls without a token, the server returns HTTP 401 with a WWW-Authenticate header that points to that metadata and, ideally, the scopes needed.
Client registration. Clients obtain a client ID through OAuth Client ID Metadata Documents (recommended), pre-registration, or Dynamic Client Registration (RFC 7591), which the current revision marks as deprecated and kept for backwards compatibility.
PKCE and issuer validation. The authorisation code flow uses PKCE, and clients validate the iss parameter in the authorisation response (RFC 9207) to prevent mix-up attacks.
Resource indicators. Clients must include the resource parameter (RFC 8707) naming the specific MCP server in both authorisation and token requests, so tokens are bound to that server.
Audience validation. Servers must validate that tokens were issued specifically for them. They must not accept, or pass on, any other tokens.
Token handling. Tokens go in the Authorization header on every request, never in the URL query string.
Least privilege and step-up. Servers should advertise the minimum scopes needed. When a call needs more, the server returns HTTP 403 with insufficient_scope and the required scopes, and the client can ask for them through a step-up flow.

Two points are easy to miss. First, authorisation is optional: a server can be deployed with none. Second, STDIO servers should not use this flow and instead read credentials from the environment, which in practice usually means API keys or personal access tokens in a configuration file on the developer's machine.

The main MCP risks

1. Credentials in local server configuration

Local MCP servers commonly receive a GitHub token, cloud key or database password through an environment variable or a JSON configuration file. These credentials are long-lived, often broadly scoped, sit in plain text on endpoints and are copied between machines and repositories. This is secret sprawl with a new entry point, and it maps to OWASP NHI2 Secret Leakage and NHI7 Long-Lived Secrets.

2. Token passthrough and confused deputy

A server that accepts a token meant for another service, or forwards the client's token to an upstream API, breaks audience restriction and accountability. An attacker who obtains one token can use it wherever it is accepted, and the upstream API cannot tell which server or client acted. A related confused-deputy problem arises when an MCP server acting as an OAuth client to a third-party API reuses consent obtained for one client to serve another. The specification's security considerations address both; implementations must follow them.

3. Tool poisoning and malicious descriptions

The model reads each tool's name, description and parameter schema to decide how to use it. A malicious or compromised server can hide instructions there, for example telling the model to read a file and include it in a parameter. The specification itself says tool descriptions and annotations should be treated as untrusted unless they come from a trusted server.

4. Rug pulls and silent changes

A server can change its tool definitions after a user has approved it. A tool that was harmless at install time can later request broader data or send it elsewhere. Clients should detect and surface changes to tool definitions and require re-approval.

5. Malicious and look-alike servers

Public MCP registries and package ecosystems make it easy to install a server with a convincing name. The OWASP agentic supply chain risk (ASI04) cites a malicious MCP server that impersonated the Postmark email service and secretly forwarded messages. Supply chain attacks on AI packages, such as the Mastra npm backdoor campaign and the LiteLLM PyPI breach, show the same ecosystems being targeted for credentials.

6. Cross-server data flow

An agent connected to several servers can read data through one and send it out through another. Each server may be secure on its own, while the combination leaks data. This is the agentic version of lateral movement.

7. Over-privileged server identities

A remote MCP server often holds its own credentials to the backend it wraps. If that identity is broad (an admin API key, a database superuser), every client of the server effectively shares that privilege.

8. Local server execution

A local server is code running on the user's machine with the user's permissions. Installing one is equivalent to installing software, and a server launched through a one-line command in a configuration file may pull and run unvetted code.

Controls for local (STDIO) servers

Allow only approved servers, pinned to specific versions from trusted sources; block ad hoc installs through endpoint policy where possible.
Keep credentials out of configuration files. Inject them at runtime from a secrets manager or the operating system keychain, and prefer short-lived tokens obtained by a helper over static personal access tokens.
Scope every credential to the minimum: read-only where possible, a single repository or project, and an expiry.
Run servers in a sandbox or container with restricted filesystem and network access.
Scan developer machines and repositories for MCP configuration files containing secrets. See the AI Coding Agents Security Guide.

Controls for remote (HTTP) servers

Require authorisation. An unauthenticated remote server exposing internal tools is an open API.
Implement the specification in full: Protected Resource Metadata, audience validation, PKCE, resource indicators, issuer validation and no token passthrough.
When the server calls upstream APIs, obtain separate tokens for those APIs, preferably by OAuth 2.0 Token Exchange (RFC 8693), so each hop has its own audience-bound token that records the user and the calling client.
Give the server's own backend identity least privilege, and prefer per-user delegated access over a shared admin key.
Design scopes around tools, with narrow defaults and step-up for sensitive tools, rather than one scope that grants everything.
Validate tool arguments server-side and never pass model-generated input straight to shells, queries or file paths.
Log the client identity, user, tool, arguments (redacted where needed) and result for every call.

Controls at the host and client

Show users which server and tool will be called, with what arguments, and require consent for tool invocation, as the specification requires hosts to do. Require explicit confirmation for destructive tools.
Detect changes to tool definitions and ask for re-approval.
Store tokens securely (operating system keychain or secrets manager, never plain files), and keep refresh tokens confidential.
Limit which servers can be combined in one session when one reads sensitive data and another can send data externally.

MCP gateways and registries

Many organisations now place an MCP gateway between agents and servers. A gateway can enforce the approved server list, broker authentication so agents never hold backend credentials, apply per-tool authorisation policy, inspect tool definitions for changes and injection patterns, and centralise logging. An internal registry of approved servers, with owners, versions, scopes and risk ratings, gives the gateway its source of truth. Neither is required by the specification, but both reduce the number of places credentials and policy decisions live.

Common failure patterns

A GitHub personal access token with full repository scope pasted into an MCP configuration file and committed to a repository.
A remote MCP server deployed internally with no authorisation because "it is only on the internal network".
A server that forwards the user's identity provider token to downstream APIs.
A community MCP server installed from a public registry with no review, running with the developer's full permissions.
An agent connected to both an email server and a file server, steered by a malicious message into sending internal files externally.

Practitioner checklist

Maintain an inventory and approved list of MCP servers, with an owner, version, scopes and data classification for each.
Require authorisation on every remote MCP server and implement the specification's token validation in full.
Prohibit token passthrough; use token exchange for upstream calls.
Remove static secrets from local MCP configuration; inject short-lived, scoped credentials at runtime.
Treat tool descriptions as untrusted; detect definition changes and require re-approval.
Sandbox local servers and validate tool arguments on remote ones.
Require confirmation for destructive tools, and restrict risky server combinations.
Log every tool call with client, user, tool and outcome; monitor for unusual tool use.
Consider an MCP gateway to centralise authentication, policy and logging.

MCP Security Guide: Securing the Model Context Protocol