MCP Security: What to Check Before You Connect a Server (2026)

MCP security means controlling what a Model Context Protocol server can see and do once it is connected to an AI agent, because by default that server can read every tool description the model sees, touch whatever data source it is wired to, and act under the same credentials as the agent itself. The protocol has no built-in concept of least privilege. You have to add it.

That gap stopped being theoretical the moment MCP started showing up in production stacks instead of side projects. When a protocol moves from "developer tries it on a Saturday" to "agency connects it to a production database," the security question stops being academic and starts being a procurement blocker.

This is specifically about the MCP layer: the server you connect, the permissions it inherits, and the data that flows through it. For the broader problem of an agent following instructions it shouldn't, see our prompt injection attacks on AI agents guide. For agent-level controls beyond MCP, see AI agent security best practices. If you haven't read what MCP actually is yet, start with the MCP protocol explained.

What attack surface does MCP actually add?

MCP adds three things an agent didn't have before: a channel for untrusted text to reach the model disguised as a tool description, a set of credentials the server holds on the agent's behalf, and a plugin ecosystem where anyone can publish a server with no vetting. Each is a real, documented category of attack, not a hypothetical.

Tool description poisoning. In April 2025, security firm Invariant Labs disclosed what they named Tool Poisoning Attacks: an MCP server can embed instructions inside a tool's description field that the model reads but the user's UI never shows. The user sees a clean, simplified tool name. The model sees the full text, including hidden instructions telling it to read SSH keys, config files, or other servers' data and exfiltrate them through a parameter the server controls. Because MCP's security model currently treats tool descriptions as trustworthy by default, this works even against agents that would otherwise resist a suspicious instruction. Invariant followed up by publishing MCP-Scan, an open source scanner that checks connected servers for exactly this pattern.

Over-privileged servers. Most MCP servers are built to be useful, not minimal. A database server built for "query anything" convenience often runs under a service role or admin credential, because scoping it down takes extra engineering the server author usually skips. The agent then inherits whatever that credential can do, whether the current task needs it or not.

Unvetted third-party servers. MCP servers are not reviewed the way apps in an app store are. Anyone can publish a server, and a developer connecting it in five minutes has no reliable way to know what it does with the data it touches, what it logs, or whether it phones home. Treat every third-party MCP server the way you'd treat a browser extension asking for full page access: convenient, and a real trust decision.

A documented incident: how a Supabase MCP setup leaked data in testing

In July 2025, the AI security firm General Analysis ran a controlled demonstration (not a report of an actual customer breach) showing how these pieces combine. They built a test support application on Supabase, populated it with dummy data, and connected a developer's Cursor IDE to the project through the Supabase MCP server using service_role credentials, which bypass Row-Level Security by design.

An attacker opened a normal support ticket and wrote a message with two parts: a plausible question for the human support agent, and a block of hidden instructions addressed directly at "CURSOR CLAUDE," telling it to read a sensitive integration_tokens table and post the contents back into the same ticket thread. The support agent, who only had restricted access, never saw anything unusual and replied normally.

The leak happened later, when a developer asked Cursor to "show me the latest open support ticket." The MCP-connected assistant pulled the ticket, read the attacker's message as part of the data, and treated the embedded instructions as commands. It queried the integration_tokens table under the elevated service_role credential and wrote the results into the public ticket thread, where the original attacker could read them by refreshing the page. No permission was technically violated. The agent held credentials broader than the task required, and it trusted text it should have treated as untrusted input.

General Analysis and Supabase's own documentation point to the same fixes: scope the server to one project with project_ref, run queries under a read-only role with read_only=true, and limit which tool groups the server exposes with features. Read-only mode blocks the write step that carried the data back out, though it still permits the server to read anything the underlying database role can see, so scoping the role itself still matters.

General Analysis says the test records its July 2025 setup and that it has not rerun it against the current Supabase MCP server. It rechecked its mitigation advice against Supabase docs on September 6, 2026.

Where a typical MCP server's access needs to be scoped down

Practical checks before you connect a server

Read the tool descriptions yourself, not just the tool names. The UI simplification that makes Tool Poisoning Attacks possible cuts both ways: if you never look past the tool name in your client's interface, you're relying on the same shortcut the model exploits against you. Pull the raw server manifest and read every description before connecting a new server, and again after any update.

Scope credentials to the task, not the platform. If a server only needs to read three tables, don't hand it a role that can write to all of them. This is the single highest-leverage fix in the Supabase demonstration above: read-only mode alone would have blocked the exfiltration step.

Sandbox servers you didn't write. Run third-party MCP servers in a container or restricted environment rather than directly on a machine with broad filesystem and network access, particularly for anything sourced from an unfamiliar publisher.

Audit what data actually flows through each server. Log tool calls and their arguments, not just whether a call succeeded. A request to "summarize the latest ticket" that generates a query against a table named integration_tokens should be visible in that log, and should be reviewable before or after the fact.

Treat fetched content as data, never as instructions. The official MCP security guidance covers this under scope minimization and the confused deputy problem: an assistant that reads a support ticket, a web page, or an email is processing untrusted input, and instructions embedded in that input carry no more authority than the rest of the text.

Use a scanner before trusting a new server. Tools like MCP-Scan check a server's tool descriptions and behavior for known poisoning patterns before you connect it in production. Treat it the same way you'd treat a dependency vulnerability scan: not a substitute for review, but a fast first filter.

Remote MCP servers add an OAuth layer of risk

Everything above applies to any MCP server. Remote, OAuth-authenticated servers add a second layer the official MCP security best practices document covers in detail: token handling. Two patterns show up repeatedly. Token passthrough, where a proxy server forwards a client's access token to a downstream API without validating it was actually issued for that server, lets a stolen or misdirected token reach a system it was never scoped for. The confused deputy problem, where an MCP proxy with a static client ID and a stored consent cookie can be tricked into approving a new attacker-controlled client without the user seeing a fresh consent screen. Neither requires a poisoned tool description. Both require the same fix as everything else here: don't assume a token or a cookie means what it looks like it means, and validate the actual audience and client on every request.

MCP security gateways: what the term actually means

"MCP security gateway" gets searched as if it's a specific product category, and increasingly it is: a proxy that sits between your agent and every MCP server it connects to, enforcing policy (which tools are allowed, which data can flow out, rate limits, logging) in one place instead of per-server. If you're managing more than a handful of MCP connections across a team, centralizing that policy is worth more than auditing each server individually every time someone adds one. If you're running one or two servers, the practices above cover the same ground without adding another piece of infrastructure.

FAQ

What is MCP security?

MCP security is the set of practices that control what a Model Context Protocol server can access and do once an AI agent connects to it, covering credential scoping, tool description review, and treating server-fetched data as untrusted input rather than instructions.

What is a Tool Poisoning Attack?

A Tool Poisoning Attack is a technique, disclosed by Invariant Labs in April 2025, where a malicious MCP server embeds hidden instructions inside a tool's description field. The AI model reads the full description, but the user's interface typically shows only a simplified summary, so the user never sees the hidden instruction that manipulates the model's behavior.

Did Supabase's MCP server actually leak customer data?

No confirmed customer breach has been reported. General Analysis ran a controlled July 2025 demonstration on a test project populated with dummy data, showing that a Supabase MCP connection using elevated service_role credentials could be manipulated through a prompt-injected support ticket into leaking a sensitive table's contents. Supabase's own documentation acknowledges this class of risk and recommends read-only mode and project scoping as mitigations.

How do I scope an MCP server's permissions?

Connect it with the least-privileged credential the task allows, ideally read-only, restrict it to the specific database, project, or directory it needs rather than an entire account, and disable write or execute tool groups unless the workflow specifically requires them.

Are third-party MCP servers safe to use?

Treat any third-party MCP server as an unreviewed dependency. Read its tool descriptions before connecting, check what data it can reach, and run it in a sandboxed environment where possible, especially for servers with filesystem or shell access.

What's the difference between MCP security and general AI agent security?

MCP security is specifically about the server layer: what a connected server can access and what a malicious or compromised server can do to an agent. Broader AI agent security also covers how the agent itself handles autonomous execution, tool-use approval gates, and prompt injection from any untrusted source, not only MCP servers.

Is there a scanner for MCP server security?

Yes. MCP-Scan, released by Invariant Labs in April 2025, checks connected MCP servers for known tool poisoning patterns and other risky configurations before you rely on them in production.

Should I let an AI coding agent connect its own MCP servers without review?

No. Every MCP server an agent connects to should go through the same review as a new dependency: read what it can access, confirm the credential it's using is scoped down, and log what it actually does once connected. If you want that review done systematically across your Claude Code or agent setup, our Claude Code security audit covers MCP server permissions, prompt injection exposure, and credential scoping as part of a full hardening pass.

If your team is connecting MCP servers to production data and wants a second set of eyes on what those servers can actually reach, book a consultation and we'll walk through your current setup before anything gets hardened.

---

Sources: Supabase MCP can leak your entire SQL database, General Analysis, MCP Security Notification: Tool Poisoning Attacks, Invariant Labs, MCP Security Best Practices, Model Context Protocol