MCP security best practices: how to use MCP servers without leaking data

MCP makes your coding agent far more useful, because it can now read your database, your tickets and your repos. It also gives anyone who can put text in front of that agent a new way to reach those systems. MCP security is mostly about closing that gap without giving up the convenience.

This guide covers MCP security best practices for people who use MCP servers, not only people who build them: the main risks, what the MCP specification requires, and a checklist you can apply today. Everything is sourced from the MCP specification and from the docs of the tools you probably use.

Why MCP security is different

A normal integration does one fixed thing. An MCP server hands a language model a set of tools, and the model decides when to call them based on everything in its context. The spec says tools are "model-controlled", which is exactly why it asks for a human in the loop (MCP tools spec).

Three facts follow from that:

1. The server acts with your permissions. Supabase says its MCP server runs with your developer permissions and should only be used as an internal tool, never handed to customers (Supabase MCP).
2. Anything the agent reads can carry instructions. A support ticket, a web page, a code comment or a database row can contain text written to steer the agent.
3. Tool descriptions are claims, not guarantees. The spec says clients "MUST consider tool annotations to be untrusted unless they come from trusted servers."

The biggest MCP risk: prompt injection through data

Supabase's docs walk through a realistic attack. A customer writes instructions into a support ticket. A developer later asks their agent to summarize open tickets. The agent reads the hidden instructions, follows them and uses its database access to leak data (Supabase MCP). Claude Code's docs give the same warning: servers that fetch external content "can expose you to prompt injection risk" (Claude Code MCP).

Nothing in that attack needs a bug in MCP itself. It needs three things together: access to private data, exposure to untrusted content, and a way to send data out. Remove any one and the attack gets much harder. That's the logic behind most of the checklist below.

What the MCP spec requires

The specification's security best practices are written mainly for people who build servers and clients, but they tell users what to expect and what to avoid (MCP security best practices):

• No token passthrough. "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server." A server that simply forwards your token to another API is a red flag.
• No sessions as authentication. "MCP Servers MUST NOT use sessions for authentication", and session IDs must be secure and non-deterministic.
• Consent before running local servers. When a client offers one-click setup of a local server, it "MUST" show the exact command that will run, without truncation, flag it as potentially dangerous and require your explicit approval.
• Confused deputy, SSRF and OAuth URL validation. The spec covers proxy servers that can be tricked into acting for the wrong client, servers that can be induced to request internal addresses, and malicious authorization URLs.
• Scope minimization. Ask for the narrowest permissions a task needs, not everything a token can do.

On the client side, the tools spec says applications SHOULD show which tools are exposed, indicate clearly when a tool is invoked, ask for confirmation on sensitive operations and show tool inputs to the user before calling the server (MCP tools spec).

MCP security checklist for vibe coders

Before you connect a server

• [ ] It comes from a source you trust: the vendor's official docs or repository. Cursor's guidance is to verify the source, review permissions, use restricted API keys and audit code for critical integrations (Cursor MCP).
• [ ] You know whether it runs locally (a command on your machine) or remotely (a URL), and you've read the exact command for a local server.
• [ ] Its token is scoped to the minimum: one project, read-only where possible, short-lived where the provider allows it.

When you configure it

• [ ] Tokens are referenced from environment variables, never pasted into a committed file. Cursor uses ${env:NAME}, Claude Code uses ${VAR} and Codex uses bearer_token_env_var. Our guide to adding an MCP server to Cursor, Claude Code and Codex shows each one.
• [ ] Supabase servers use project_ref and read_only=true, and only the feature groups you need, for example features=database,docs (Supabase MCP).
• [ ] In Codex, risky servers use default_tools_approval_mode = "writes" or "prompt", and disabled_tools blocks tools you never need (Codex MCP).

While you work

• [ ] Tool approvals stay on. Cursor asks before using MCP tools by default. Read the arguments before approving anything that writes.
• [ ] You don't point an agent with write access at untrusted content (tickets, emails, scraped pages) in the same session.
• [ ] Production data stays out of reach unless the task needs it. Develop against a separate project.

Afterwards

• [ ] Remove servers you no longer use. Fewer tools means less for an attacker to steer and less context for the agent to wade through.
• [ ] Rotate any token that was ever pasted into a chat, a config file or a log.

Where MCP fits with the rest of your agent safety

MCP is one layer. Permission modes, sandboxes and deny rules decide what the agent can do on your machine. Our guide to running coding agents safely covers those settings for Claude Code and Codex. Together they let you give an agent real access without giving it the keys to everything.

Keep reading

• What is MCP? The Model Context Protocol explained for vibe coders
• MCP config starter with a safety checklist
• Claude Code hooks starter: block risky commands

FAQ

Is MCP secure?

MCP can be used securely, but a connected server acts with your permissions. Security depends on trusted servers, narrowly scoped tokens, tool approvals and keeping untrusted content away from agents with write access.

What is prompt injection in MCP?

Prompt injection is when text the agent reads, such as a support ticket or web page, contains instructions that steer the agent into misusing its tools, for example leaking database data.

What is token passthrough?

Token passthrough is when an MCP server accepts a token issued for another service and forwards it. The MCP spec forbids it: servers must not accept tokens that were not explicitly issued for them.

Should I connect MCP servers to production data?

Only when the task needs it. Develop against a separate project, use read-only access where possible, and keep approvals on for any tool that writes.