The Model Context Protocol won the integration war. Almost every serious AI client — Claude Desktop, Cursor, Windsurf, and a long tail of agent frameworks — now speaks MCP, and the ecosystem has exploded into thousands of community servers you can wire into an agent in under a minute. That convenience is exactly the problem. MCP standardizes how agents connect to tools and data, but it does not standardize how to do that safely. The official specification says so directly: the protocol "cannot enforce these security principles at the protocol level." MCP hands you an empty room. You bring your own locks.
If you run agents that touch real systems — your shell, your repos, your customer data — this is the hardening playbook to run before you connect your next server.
Why MCP changed your threat model
A traditional API integration is a closed loop: your code calls an endpoint, parses a known response, and moves on. An MCP agent is the opposite. It reads tool descriptions written by someone else, ingests tool outputs it has never seen, and then decides what to do next — often with the authority to run commands or move data. Every one of those text channels is an instruction channel the model will dutifully follow.
That shift created an entirely new class of attacks that have nothing to do with classic web vulnerabilities:
- Prompt injection. Hidden instructions buried in a document, a web page, or a tool's output hijack the agent mid-task. The model can't reliably tell "data to process" from "commands to obey."
- Tool poisoning. An attacker plants malicious instructions inside a tool's description or metadata. The model reads them; the human approving the connection never sees them.
- Rug pulls. A clean server you approved last week silently ships a malicious update this week. Approval is a moment in time; behavior is not.
- Confused-deputy attacks. A proxy MCP server that fronts a third-party API can be tricked into using its credentials on a malicious client's behalf, leaking authorization codes without real user consent.
These aren't theoretical. Between January and February 2026, researchers filed dozens of CVEs targeting MCP servers — and one of them should reframe how you think about the whole stack.
The CVE that proved the point: CVE-2025-6514
In mid-2025, the JFrog Security Research team disclosed CVE-2025-6514, a critical flaw in mcp-remote — the popular proxy that lets desktop clients reach remote MCP servers. The CVSS score was 9.6, and the affected range was mcp-remote versions 0.0.5 through 0.1.15, a package with over 437,000 downloads.
The mechanics are a clinic in why MCP is different. During the OAuth handshake, a malicious MCP server could return a booby-trapped authorization_endpoint URL. When the client passed that value to the system's open() function, it triggered arbitrary OS command execution on the user's machine. In plain terms: connecting your trusted client to an untrusted server could hand that server a shell.
The attack didn't break OAuth. It abused the trust the client placed in whatever the server said during a routine auth flow — the confused-deputy pattern, weaponized.
Because mcp-remote sits underneath Claude Desktop, Cursor, and Windsurf, a single bad server connection put real developer laptops at risk of full compromise. The fix shipped in mcp-remote 0.1.16. If you're pinned below that, the rest of this playbook is moot until you upgrade.
# Check your installed version
npx mcp-remote --version
# Upgrade to the patched release (0.1.16 or later)
npm install -g mcp-remote@latest
The hardening playbook
1. Patch and pin everything
Update mcp-remote to 0.1.16 or later today. Then treat every MCP server as a supply-chain dependency, because it is: pin exact versions, review the diff before you bump, and scan dependencies the same way you'd scan any package. The rug-pull threat means "I trusted it once" is not a security posture — automatic updates on a server with shell access are a standing liability.
2. Demand OAuth 2.1 — and reject `localhost` HTTP
The November 2025 MCP specification formalized OAuth 2.1 as the authentication standard for all remote MCP server connections, with PKCE mandatory for all public clients. This closes the authorization-code-interception leg of confused-deputy attacks. Operationally: only connect to remote servers over HTTPS, and be deeply suspicious of any server that asks you to disable TLS verification or route auth through plain HTTP "just for testing."
3. Isolate every server
Assume any one server can be compromised and design so that it can't take the others down with it. Separate credentials, separate processes, separate network paths per server. A server that summarizes web pages has no business sharing a process — or a token — with the one that can push to your main branch. Containerize untrusted servers and give each the narrowest credential scope that still lets it do its job.
4. Treat tool descriptions and outputs as hostile input
This is the mindset shift that matters most. Both the metadata a server advertises and the content it returns can carry injection payloads. Pin tool descriptions and alert on changes between sessions — a description that mutates is a rug-pull tripwire. Where your framework supports it, sandbox tool output and strip or quarantine anything that looks like an instruction before it re-enters the model's context.
5. Keep a human on the destructive verbs
Read operations can run freely. Write, delete, send, deploy, and pay should require explicit confirmation — and the confirmation prompt must show the actual resolved action, not the model's paraphrase of it. The OWASP GenAI guidance and the November 2025 spec both lean hard on least privilege and human-in-the-loop for high-impact tools. The 2026 CVE wave is the evidence for why.
6. Log the agent like you'd log a junior with prod access
Record which server was called, with which arguments, and what came back. When something goes wrong with an autonomous agent, the only thing standing between you and a forensic guessing game is a complete, immutable audit trail.
A quick self-audit
Run this checklist against your current setup before your next connection:
| Control | Question to ask | Red flag |
|---|---|---|
| Patch level | Is mcp-remote ≥ 0.1.16? |
Pinned below 0.1.15 |
| Transport | Are all remote servers HTTPS + OAuth 2.1? | Plain HTTP or disabled TLS |
| Isolation | Does each server have its own creds/process? | One token shared across servers |
| Privilege | Are destructive tools gated by confirmation? | Agent can rm/deploy unattended |
| Integrity | Do you pin and diff tool descriptions? | Auto-updating server with shell access |
| Audit | Can you replay what the agent did? | No per-call logging |
The Bottom Line
MCP is a genuinely great protocol, and its security model is not a flaw — it's a deliberate division of labor. The spec moves data; you own the locks. CVE-2025-6514 is the cautionary tale that should be taped to every team's monitor: a 9.6-severity, full-machine-compromise bug that started with nothing more than connecting a trusted client to an untrusted server. Patch to 0.1.16, insist on OAuth 2.1 over HTTPS, isolate aggressively, and treat every tool description and output as potentially hostile. Do that, and you get MCP's enormous upside without betting your laptop — or your production environment — on the good faith of a server you found in a directory yesterday.
