Quick answer: MCP itself isn't inherently unsafe, but the ecosystem around it has real, documented security risks — tool poisoning, rug pull attacks, typosquatted packages, and over-permissioned local execution have all led to actual incidents, not just theoretical ones. The risk depends heavily on how you connect to MCP servers: installing unverified community packages locally carries meaningfully more exposure than connecting through a hosted, permissioned gateway. Below is what the research actually shows, a real incident that happened, and what to check before you connect anything to your (or a client's) business data.
If you're a freelancer or agency considering connecting Claude to a client's Slack, database, or CRM through MCP, "is this safe?" is a completely reasonable question to ask before you do it — especially when it's not your own data on the line.
The honest answer is: it depends entirely on what you're connecting to and how.
Why MCP Security Isn't Just "API Security"
A normal API integration has one trust relationship: your code calls an endpoint, the endpoint checks a key, done. MCP has a longer chain: you, the AI client, the MCP server, the token it's using, and the actual resource being accessed. Security researchers describe this as needing to account for the full delegation chain — who's asking, what's acting on their behalf, and whether it's actually authorized to do what it's about to do.
That extra chain is exactly where most of the real risk lives.
The Real Risks, Explained
- Tool Poisoning
This is the risk that shows up most consistently across security research right now, and for good reason — it's ranked among the top risks in frameworks like the OWASP Top 10 for Agentic Applications. A malicious or compromised MCP server can embed hidden instructions inside a tool's description — the metadata Claude reads to decide what a tool does. You never see it; the model does. A tool that looks like "check server status" can carry buried instructions to also exfiltrate data, and there's currently a trust gap in the ecosystem: tool descriptions get reviewed once, at connect time, but nothing re-checks them after that.
- Rug Pull Attacks
This is the one with a real, documented incident behind it. In September 2025, an unofficial Postmark MCP server — with around 1,500 weekly downloads — functioned normally for a period, then was quietly updated to add a BCC field to its email-sending function, silently copying every email sent through it to the attacker. Anyone running the latest version, which is standard practice, started leaking email content without knowing it. Nothing about the install looked wrong. The tool simply changed after people had already trusted it — which is exactly why static security scanning doesn't catch this category: the code passes review, then changes its behavior later, at runtime, between sessions.
- Typosquatting and Supply Chain Risk
Community MCP registries generally don't require a security audit to list a package — just proof you own the GitHub repo or domain. That's a much lower bar than most people assume, and it means registry presence isn't the same thing as vetting. Attackers have already run real campaigns exploiting this: one documented case in early 2026 used typosquatted npm packages mimicking popular utilities to install rogue MCP servers that exfiltrated SSH keys, AWS credentials, and npm tokens through connected coding assistants.
- Local execution and IDE auto-run risk
Several widely used developer tools — including a few major coding assistants — were found running project-defined MCP servers automatically, with full developer-level OS privileges and no process isolation. One such vulnerability was formally disclosed and patched by a major cloud provider in mid-2026. If a project's MCP config is malicious (or gets modified by something you didn't write), it can execute silently the moment you open the project.
- Over-permissioned tokens and the confused deputy problem.
MCP servers often request broader OAuth scopes than the task needs — full inbox access instead of read-only, for example — and then act with their own permissions rather than strictly the requesting user's. That aggregation of access is exactly what turns a single compromised tool into a much bigger exposure than it should be.
- Data exfiltration through normal-looking channels
Rather than an obvious breach, injected instructions can quietly encode sensitive data into something that looks like an ordinary tool call — a search query, an email subject line — so the exfiltration hides in plain sight inside legitimate traffic.
What Actually Reduces These Risks
Across the security research, the recommended mitigations are fairly consistent:
- Scope every credential to the minimum access it actually needs — not "just in case" permissions
- Avoid installing unverified community packages for anything touching real business or client data
- Prefer servers with an accountable, identifiable maintainer over anonymous registry listings
- Watch for tool definitions changing after approval — most setups don't monitor for this at all
- Keep credentials encrypted and out of local plaintext config files
- Log tool invocations with enough context to catch unusual patterns after the fact
- Keep a human in the loop on anything sensitive — the MCP spec itself explicitly recommends this
Where MCP Express Fits — Honestly
Some of the risk categories above genuinely don't apply the same way once you're not installing arbitrary community packages locally. Worth being specific about which ones, and which ones don't just disappear because a platform is hosted.
What's structurally different: MCP Express integrations are first-party maintained, not pulled from an open community registry — so the typosquatting and unverified-package risk that drove the npm-mimicking campaign above isn't something you're exposed to using our confirmed integrations.
There's no local server process running with your machine's own OS privileges, so the IDE auto-execution vulnerability class doesn't apply — the connection runs server-side, not as code on your laptop.
Credentials are stored with AWS KMS encryption rather than sitting in a local config file, closing off the plaintext-credential exposure path. And per-action permission scoping — enabling exactly the actions a tool needs and nothing else — is the concrete version of the least-privilege recommendation security researchers keep repeating, rather than an all-or-nothing connection.
What doesn't change: Tool poisoning and prompt injection are risks that live in the content flowing through a tool — a Jira ticket, a Slack message, a webpage a connected tool reads — not in how the tool was installed. That risk exists on any platform, hosted or self-hosted, because it's about what data an AI model reads and acts on, not the delivery mechanism.
No gateway, ours included, makes that risk zero. Staying deliberate about what actions you enable, and keeping a human in the loop on anything that touches money, credentials, or irreversible actions, still matters no matter how you're connected.
FAQ
- Is MCP itself insecure?
The protocol isn't inherently unsafe, but its openness means security depends heavily on implementation choices — which servers you trust, what permissions you grant, and how credentials are stored.
- What's the single biggest MCP security risk right now?
Tool poisoning and rug pull attacks are the most actively discussed in current security research, largely because they exploit a real gap: tool definitions are typically reviewed once, at connect time, and rarely re-checked afterward.
- Has an MCP security incident actually happened, or is this theoretical?
It's happened. The Postmark MCP rug pull in September 2025 is a documented, real case — a widely used unofficial server was modified after adoption to silently copy user emails to an attacker.
- Does using a hosted MCP gateway make me completely safe?
No platform eliminates every risk. A hosted, permissioned gateway removes real risk categories tied to local package installation and credential storage, but prompt injection through tool content is a separate risk that requires ongoing vigilance regardless of platform.
- Should I avoid connecting sensitive client data to MCP entirely?
Not necessarily — but it's worth being deliberate: prefer accountable, maintained integrations over unverified community packages, scope permissions to only what's needed, and keep a human reviewing anything sensitive or irreversible.
- How can I tell if an MCP server changed its behavior after I approved it?
Most setups don't monitor for this by default — it's one of the harder risks to catch without deliberate logging or a platform that maintains its own integrations rather than pulling from unaudited third-party packages.
Connect Deliberately, Not Blindly
MCP is genuinely useful, and the risks above aren't a reason to avoid it — they're a reason to be specific about what you connect and how. Explore MCP Express → No credit card required to look around.
