MCP sampling security: what a server can do with your model, and why it is deprecated

The short answer

MCP sampling is the feature that lets an MCP server ask the client’s language model to generate text, so the server can use AI without its own API key.¹ The risk is that the server writes the prompt. In December 2025, Unit 42 showed a malicious server using sampling to burn the user’s tokens on hidden work, plant instructions that persisted in the chat, and make the model call a file-writing tool the user never noticed.³

The 2026-07-28 MCP specification deprecated sampling. New implementations should not adopt it, and existing ones should call model provider APIs directly. It remains in the spec until at least the first revision released on or after 28 July 2027.² Until clients drop it, turn it off or approve every request.

What sampling is

Normally the client’s model calls the server’s tools. Sampling reverses the direction: in the middle of handling a request, the server sends back a sampling/createMessage request with its own messages, an optional system prompt and a token limit, and the client runs it through the user’s model.¹

Two extensions made it more powerful:

• Tools in sampling. A server can include a tools list in a sampling request, and the model can call those tools within the sampling flow, if the client declared sampling.tools. The tools don’t need to be registered ones; they’re defined per request.¹
• Context inclusion. The includeContext field could ask the client to add context from this server or all connected servers. Those values were deprecated earlier and stay deprecated.¹

The spec always said a human should be in the loop: “there SHOULD always be a human in the loop with the ability to deny sampling requests”, with UI to review and edit prompts before sending and responses before delivery.¹ SHOULD is not MUST. How visible a sampling request is depends on the client.

Three attacks Unit 42 showed

Unit 42 researchers (Yongzhe Huang, Akshata Rao, Changjiang Li, Yang Ji and Wenjun Hu) built a code-summarizer server on top of the MCP project’s “everything” demo server and connected it to a coding copilot that supports sampling; they didn’t name the copilot.³ The user asked for a summary of the current file. The server’s sampling request carried the summary request plus hidden instructions.³

The researchers note that the client’s own summarising hid the raw output in their test, which helped the first attack, and that other hosts may behave differently.³ That’s the honest caveat: the attacks depend on how much of the sampling exchange the client shows.

None of these needed a bug. Each used the feature as designed, with a server that was malicious or compromised. If you’ve read about tool poisoning, it’s the same root: text from a server ends up steering your model.

Why the design is hard to secure

Sampling puts four things in the server’s hands that are normally the user’s:

1. The prompt. The server writes the messages and can request a system prompt. Clients may modify or ignore the system prompt¹, but most users never see it.
2. The bill. Generation runs on the user’s model and quota. The client must respect maxTokens¹, but the server picks the number.
3. The tool list, when tools in sampling is enabled. The server defines tools for the model to call inside the loop.¹
4. What comes back. The output returns to the server, which can embed it in what the user later sees.

The spec’s security considerations list user approval controls, validating content, respecting model hints, rate limiting, careful handling of sensitive data, and iteration limits for tool loops.¹ Each is sensible. Each is also a SHOULD, implemented differently by every client. A protocol feature whose safety depends on every host building a good review screen is hard to rely on, and the maintainers’ answer was to deprecate it.

What deprecated means here

The 2026-07-28 revision’s deprecated-features registry lists Sampling, Roots and Logging, all under SEP-2577, with a migration path for sampling of “Integrate directly with LLM provider APIs”.² Under the lifecycle policy:

• It remains in the specification for at least twelve months, and becomes eligible for removal at the first revision released on or after 28 July 2027.²
• New implementations SHOULD NOT adopt it.¹
• Existing implementations SHOULD migrate.¹

So for at least the next year, clients that support sampling may keep supporting it, and servers that use it may keep using it. Deprecation lowers the long-term risk; it doesn’t switch anything off on your machine today.

For server authors, the migration is straightforward: if your server needs a model, give it its own API key and call the provider. That makes cost and data flow explicit, and it means the server’s prompts no longer run as the user’s model inside the user’s session.

How to lock it down

If you run MCP clients:

1. Find out whether your client supports sampling, and turn it off if it can. Keep it only for a server you rely on that needs it.
2. If you must allow it, require approval for every sampling request, with the full prompt visible, not a summary. The spec’s review-and-edit model exists for this.¹
3. Never auto-approve tools inside sampling. Covert tool invocation was the demonstration that changed something on disk.³ If a server-defined tool can write files or call APIs, a person should see each call.
4. Watch token use per server. Unit 42 recommends flagging unusual token usage or sampling frequency and setting token limits by operation type.³
5. Treat every server as untrusted input. Install from sources you can review; prefer servers that don’t request sampling at all.

If you build MCP servers:

1. Don’t adopt sampling in new work.¹
2. If you use it today, plan the move to direct provider calls before 2027.²
3. Keep sampling prompts short and purpose-specific, and cap iterations in any tool loop.¹

If you sit in the middle, with a gateway or proxy between clients and servers, you can refuse sampling requests from servers that have no reason to make them, and log the ones you allow.

Questions people ask

Is MCP sampling removed?

No. It’s deprecated in the 2026-07-28 revision and eligible for removal from the first revision released on or after 28 July 2027.²

Can an MCP server call tools through sampling?

Yes, if the client declares sampling.tools. The server supplies tool definitions in the sampling request, and the model can call them within the sampling loop.¹

What replaces sampling?

The registry’s migration path is to integrate directly with model provider APIs.²

For the rest of the latest revision, see MCP 2026-07-28 changes. To try approvals for agent actions on a real database in your browser, open the playground; to list the MCP servers your agents can reach on your own machine and grade them, run npx deedglass scan (the grade, explained).

Written with AI assistance and checked against our claims register.