What are the main security risks with MCP?

The risks sit in three places: the server (code that can act with real credentials), the text the model reads (tool descriptions and tool results, which can carry instructions) and the connection (authentication, tokens and local network exposure). The OWASP MCP Top 10 lists ten categories, including token mismanagement, privilege escalation through scope creep, tool poisoning, supply chain attacks, command injection, prompt injection through context, weak authentication, missing audit logs, shadow MCP servers and context over-sharing.

Does the MCP specification require authentication?

For remote servers over HTTP, the specification defines an authorization flow based on OAuth 2.1, and servers using Streamable HTTP should implement proper authentication for all connections. A server that holds sensitive data or can take actions should require it. For local stdio servers the specification says to take credentials from the environment instead of following that flow.

What is tool poisoning in MCP?

Tool poisoning is when a tool, or the text it supplies such as its description or output, is crafted to steer the model. It is item MCP03 in the OWASP MCP Top 10. The model reads tool descriptions but people rarely do, so a tool can carry instructions the user never sees. The specification tells clients to treat tool annotations as untrusted unless they come from a trusted server.

Is it safe to run a local MCP server?

Only if you trust the code, because a local server runs commands on your machine with your permissions. The specification says a client that offers one-click configuration must show the exact command and get explicit user approval, and that local servers should run sandboxed with minimal privileges. HTTP servers should bind to localhost (127.0.0.1) rather than all interfaces and must validate the Origin header to block DNS rebinding.

Should a human approve every MCP tool call?

The specification says there should always be a human in the loop with the ability to deny tool invocations, and that clients should ask for confirmation on sensitive operations. In practice, most teams let read-only calls run and require approval for anything that writes, deletes, sends or spends. Where you draw that line is a risk decision, not a protocol setting.

MCP Security: Best Practices and a Checklist (2026)

Securing an MCP deployment comes down to two facts. An MCP server is a program that acts with your credentials, and every tool description and tool result is text a model will read and may follow. The MCP specification is specific about several controls, and OWASP now maintains a Top 10 list of MCP risks. This guide pulls the two together into a checklist you can apply to a server you build or a server you connect to. It was checked on October 31, 2026 against the MCP specification revision 2026-07-28 and the OWASP MCP Top 10, which is still in beta.

Where MCP risk actually comes from

It helps to separate three places where things go wrong, because the fixes are different.

The server. It is code with access to real systems. If it accepts the wrong tokens, runs unsanitized input or holds more permission than it needs, anyone who can reach it inherits that power.
The text the model reads. Tool names, descriptions and results all go into the model's context. A malicious or compromised tool can use them to steer the model, and a legitimate tool can return content an attacker wrote. This is prompt injection arriving through the tool channel.
The connection. Authentication, token handling and, for local servers, what else on the machine can reach the port.

What the MCP specification requires

The specification uses MUST for hard requirements and SHOULD for strong recommendations. The points below are the ones that matter most for security, taken from its security best practices, authorization, tools and Streamable HTTP pages.

Tokens and authorization (remote servers)

Authorization servers must implement OAuth 2.1, and MCP servers must implement OAuth 2.0 Protected Resource Metadata (RFC 9728). A server must validate that an access token was issued specifically for it, and must not accept or pass on any other token. Clients must include the resource parameter (RFC 8707) in authorization and token requests, must not send a server tokens issued for something else, and must never put an access token in the URI query string. Invalid or expired tokens must receive an HTTP 401. Clients should request the least privilege they need, and servers should avoid publishing wildcard or catch-all scopes.

Token passthrough and the confused deputy problem

Token passthrough is when a server accepts a token meant for another service and forwards it downstream. The specification forbids it: a server must not accept tokens that were not explicitly issued for it. The confused deputy problem applies to proxy servers that sit in front of a third-party API: they must implement per-client consent, keep the consent record per user and match redirect URIs exactly.

Local servers and DNS rebinding

For servers using Streamable HTTP, the specification says servers must validate the Origin header on all incoming connections and respond with HTTP 403 if it is present and invalid, to prevent DNS rebinding. Without that protection, a remote website could talk to an MCP server running on your machine. When running locally, servers should bind only to localhost (127.0.0.1) rather than all interfaces (0.0.0.0), and should implement proper authentication for all connections. On the client side, anything that offers one-click setup for a local server must show the exact command, require explicit approval and allow cancellation. Clients should run such servers sandboxed with minimal privileges.

Tools

Servers must validate all tool inputs, implement access controls, rate-limit tool invocations and sanitize tool outputs. Clients must treat tool annotations as untrusted unless they come from a trusted server. The specification also says there should always be a human in the loop with the ability to deny tool invocations. Clients should show tool inputs to the user before calling the server, validate results before passing them to the model, set timeouts and log tool usage for audit.

URLs and SSRF

Clients must sanitize and validate every URL they receive from an MCP server, must allow only http and https, and must reject schemes such as javascript:, data: and file:. They must consider server-side request forgery risks when fetching OAuth URLs and should block requests to private address ranges.

The OWASP MCP Top 10

OWASP maintains a Top 10 for MCP as a living document. It is currently in its beta and pilot phase, so expect the wording and order to change. The ten categories, as titled on the project page:

MCP01: Token Mismanagement and Secret Exposure
MCP02: Privilege Escalation via Scope Creep
MCP03: Tool Poisoning
MCP04: Software Supply Chain Attacks and Dependency Tampering
MCP05: Command Injection and Execution
MCP06: Prompt Injection via Contextual Payloads
MCP07: Insufficient Authentication and Authorization
MCP08: Lack of Audit and Telemetry
MCP09: Shadow MCP Servers
MCP10: Context Injection and Over-Sharing

The checklist below is organized so that each item maps to at least one of these.

A practical checklist

Items marked (spec) come from the MCP specification text above. Items marked (ours) are our own engineering recommendations, not requirements of the protocol.

If you build an MCP server

Validate that every token was issued for your server, and reject all others. (spec)
Never forward a client's token to another service. Use a separate credential or a proper token exchange. (spec)
Validate tool inputs against a strict schema and check authorization on the server for every call. Do not rely on the model to decide whether an action is allowed. (spec, ours)
Request and publish the narrowest scopes that work. Avoid wildcard scopes. (spec)
Rate-limit tool calls and sanitize what tools return, because results go straight into the model's context. (spec)
Keep write and destructive actions in separate tools from read-only ones so they can be approved and permissioned separately. (ours)
Keep secrets out of tool results, error messages and logs. (ours)
Pin and review dependencies, and run the server with minimal operating-system privileges. (ours)
For a local HTTP server: validate Origin, bind to 127.0.0.1 and require authentication. (spec)

If you connect to or host MCP servers

Keep an inventory of approved servers, so a server someone installed on their own is visible. (ours)
Read the exact command before running any local server, and prefer sandboxed execution. (spec)
Treat tool descriptions and annotations as untrusted unless the server is one you trust. (spec)
Re-review a server when its tool definitions change, since a description is part of the attack surface. (ours)
Require human approval for anything that writes, deletes, sends or spends, and show the tool's inputs before the call runs. (spec, ours)
Keep an agent that reads untrusted content (web pages, emails, tickets) away from write-capable tools, or put an approval step between them. (ours)

Operations

Log every tool call with who or what made it, the inputs and the outcome. (spec: log tool usage; ours: caller identity)
Know how to revoke a token or disable a server quickly, and practice it. (ours)
Test what the agent should refuse, not only what it should do. Our post on MCP in production covers why.

What this does not solve

None of these controls stops a model from being talked into misusing a tool it legitimately has. A model cannot always tell an instruction from the user from an instruction hidden in a web page or a tool result. That is why least privilege, human approval for risky actions and separating untrusted content from write-capable tools matter more than any single setting. For the wider picture, see our AI agent security checklist and our explainer on identity and access management for AI agents.

How we approach this

In MCP work we start from the access model: which caller may use which tool, with which scope, and what needs a person's approval. Then we test what the agent should decline, and we review the deployment against this kind of checklist before it is widened to more teams. If you want an outside review of an MCP deployment, that is part of our MCP and agent tooling and AI governance and security work.

Sources: MCP specification, security best practices, MCP specification, authorization, MCP specification, tools, MCP specification, Streamable HTTP transport, OWASP MCP Top 10. All read October 31, 2026; the specification pages are the revision dated 2026-07-28.

MCP security: best practices and a checklist