What are the security risks of MCP, and how do you reduce them?

The main security risks of MCP are prompt injection through tool output, tools that can do more than they should, token mishandling in remote servers, and untrusted local servers that run code on a user's machine. The MCP specification says plainly that it cannot enforce its own safety principles at the protocol level, so the controls have to be built into your host, your servers, and your approval flow.

What does the MCP spec say about security?

The specification lists three key principles. Users must consent to and understand data access and operations. Hosts must obtain explicit consent before exposing user data to servers. And tools should be treated as arbitrary code execution, with tool descriptions and annotations considered untrusted unless they come from a trusted server.

It then adds the caveat that matters most for planning: MCP cannot enforce these principles itself. Implementers are expected to build consent and authorization flows, document security implications, and apply access controls. Buying or adopting MCP does not give you a security posture. You still have to design one.

How does prompt injection reach an MCP-connected agent?

Prompt injection is when content the model reads changes what the model does. OWASP's description separates direct injection, where the user's own input alters behavior, from indirect injection, where external content such as a website or file carries instructions the model then follows.

MCP widens the indirect path. Every tool result is text that goes back into the model's context. A support ticket, a web page, a shared document, or a row in a database can contain instructions. If the same agent can also send email or write records, the injected text has a route to an action.

OWASP's mitigations are practical.

1. Constrain the model's role and limits in the system prompt.
2. Validate expected output formats.
3. Filter inputs and outputs.
4. Enforce least privilege on API access.
5. Require human approval for high-risk actions.
6. Segregate and clearly mark untrusted external content.
7. Run adversarial testing regularly.

OWASP also states that foolproof prevention methods remain unclear because of how these models work. So plan on a model that will occasionally be fooled, and limit what a fooled model can do.

Why does giving a model too much power matter for tools?

LLM06:2025 describes systems that take damaging actions based on unexpected or manipulated model output when they have been given tools. OWASP names three root causes.

This is the section to read with your security team. Most real incidents with agents are not clever exploits of the protocol. They are a model with broad permissions following a bad instruction.

What are the MCP-specific attack classes?

The spec's security best practices page documents several. The ones most relevant to a mid-size company building servers are below.

• Confused deputy. An MCP proxy server that fronts a third-party API with a static client ID can be tricked into skipping user consent. The spec requires per-client consent before forwarding to the third-party authorization flow.
• Token passthrough. A server accepts a token from a client without checking it was issued to the server, then forwards it downstream. The spec forbids this. Servers must not accept tokens that were not explicitly issued for them.
• Server-side request forgery. A malicious server can point a client at internal URLs, including cloud metadata endpoints. Clients should enforce HTTPS, block private and link-local ranges, and consider an egress proxy.
• State handle hijacking. If your tools return handles, such as a cart or workflow ID, a guessed handle must not grant access. Bind handles to the authenticated user and use unpredictable values.
• Local server compromise. A local server is code running with the client's privileges. The spec requires clients to show the exact command and get approval before one-click installs, and recommends sandboxing.
• Scope inflation. Broad scopes granted up front enlarge the damage of a stolen token. Start minimal and elevate on demand.

What controls should be in place before launch?

Use this as a pre-launch checklist.

1. Inventory the tools. For each one, record whether it reads, writes, or is irreversible.
2. Apply least privilege. Give each server its own credentials with the narrowest access that works.
3. Gate writes. Require approval for irreversible or external-facing actions.
4. Validate inputs and sanitize outputs. The spec says servers must validate all tool inputs, apply access controls, rate limit, and sanitize outputs.
5. Log usage. Keep an audit trail of tool calls on the server and the client.
6. Vet third-party servers. Read the code, pin versions, and run them sandboxed.
7. Test adversarially. Include prompt-injection cases in your evals, such as a document that tells the agent to email a file elsewhere.

How do you test for these risks?

Treat security cases as part of your eval set, not a separate exercise. Write tasks where the data contains an instruction the agent should ignore, where a tool returns an unexpectedly large or malformed result, and where the agent is asked to do something outside its remit. Score whether it refused, asked for approval, or acted. Run the set on every change to prompts or tools. Our post on evals before production explains how to build one, and tool calling design for agents covers the design side.

Frequently asked questions

Takeaway

Assume the model can be misled, then make sure a misled model cannot do much harm. Want this built for your team? Book a free 30-minute call.