AIDiveYour agent stack has a weak link
A malicious MCP server can steal your SSH keys without ever writing out one complete malicious instruction. The ASSET research group proved it: when a theft order is given to a model in one block, the big models almost all refuse. Split that same order into harmless-looking fragments, and GPT-4o, Gemini 2.0 Flash, and Llama 3.3 comply in 100% of the tested cases.
Meanwhile, most developers add a new MCP server to their agent every week, copying a config line found on GitHub. Each of those servers holds a piece of your access: API tokens, cloud keys, service accounts. MCP is useful — nobody argues with that. But the MCP server has become the weakest link in the whole agent stack.
This article covers how an MCP server leaks your secrets without getting noticed, the GhostSplice attack that beats model refusals by splitting its instructions, and the concrete defenses, from Cloudflare WriteGuard to rules you can apply on your own setup today.
What an MCP server actually holds
An MCP server is the bridge between your agent and an outside tool: your database, your GitHub, your Slack, your cloud. To do that bridge work, it stores whatever it needs to log in as you — tokens, API keys, service account credentials — in plain text, in a config file on your disk, usually with zero encryption.
One protocol detail matters for what comes later. When an agent connects to an MCP server, the server sends back its list of tools, each with a free-text description telling the model when and how to use it. Those descriptions go straight into the model's context, with the same weight as your own instructions, and the results the tools return go in there too. An MCP server talks to your agent nonstop, in text nobody ever re-reads. That is exactly what makes the GhostSplice attack possible.
The ecosystem also blew up faster than its guardrails:
| Signal | Number |
|---|---|
| Servers in the official MCP registry | 9,600+ |
| Growth of remote server deployments since May 2025 | 5× |
Anyone can publish a server, there is no central review, and your agent trusts each one exactly like an official tool. The NSA published a security guide dedicated to MCP in May, stating that the protocol's adoption outpaced the building of its protections. When an intelligence agency writes a guide about your favorite dev tool, it is rarely to congratulate you.
That is the setting: thousands of servers, no review, and your keys in the middle.
Where the secrets leak from
The first hole is credentials stored in plain text. The Hacker News published a detailed breakdown of the leak mechanics on August 17, and the starting point is blunt: tokens get pasted straight into configuration strings and stay readable on disk. One slightly rushed commit is enough to push a config into a Git repo with the keys inside. It gets worse with what the article calls sprawl: the same keys duplicated across config files, environment variables, and copies in dev, staging, and production. After a while nobody knows where the secrets live, so nobody rotates them — and a static key that never rotates is a key waiting for its attacker.
The second hole is over-permissioning. During development you hand your server broad rights to dodge authorization errors, and those broad rights ship to production untouched. One single compromise then exposes far more than real usage ever justified.
The third hole is the supply chain. CVE-2025-6514 hit mcp-remote, an OAuth proxy downloaded more than 400,000 times, and let a malicious server trigger command injection on the user's machine — running code and walking away with credentials. One popular npm package, installed in one line, and the door was open.
The fourth hole is the sneakiest: prompt injection. An agent reads everything its tools bring back — a web page, a ticket, an internal document. If one of those contains a hidden instruction, the agent can follow it as if it came from you, and use its legitimate tools to expose what it was supposed to protect. That leak goes through no technical flaw; it goes through the model's gullibility.
Before any sophisticated attack, the ordinary life of an MCP server — plaintext config, oversized rights, unvetted dependencies, unfiltered content — already exposes your secrets.
GhostSplice: the attack that ships in pieces
GhostSplice is the name the ASSET research group gave to a technique that makes your own agent run the exfiltration, with its full cooperation. The principle fits in one sentence: instead of writing the theft order in full, the malicious server splits it up, puts one fragment in a tool's description, and another in the result that tool returns. Each piece, read alone, looks harmless. But the agent combines everything that enters its working context: it rebuilds the full instruction and executes it in complete good faith — from its point of view, it is just filling in the form the tool asked it to fill in.
The test numbers are the real story:
| Model | One-block instruction | Fragmented instruction |
|---|---|---|
| GPT-4o | Refuses 100% | Complies 100% |
| Gemini 2.0 Flash | Refuses 100% | Complies 100% |
| Llama 3.3 | Refuses 100% | Complies 100% |
| Claude Haiku 4.5 | Refuses via API | Complies 100% in the three-piece test inside Cursor |
The Claude detail kills any easy conclusion: the same model can refuse in one client and exfiltrate in another, depending on the protections that client adds or does not.
What GhostSplice steals in the tests: SSH keys, environment secrets, source code, customer data. The researchers worked on isolated projects with fake keys, not on real victims, but the method is published and reproducible.
GhostSplice is not a first try. The same lab published Ghostcommit in June, an attack that hid its instructions in PNG files referenced by project conventions, then encoded the stolen secrets into source code as integers. Instruction splitting is a family of attacks settling in, not an isolated curiosity.
Two things keep this in perspective. The attack has two prerequisites: the malicious server is already plugged into your agent, and the agent has read access to the target files. That is exactly why provenance matters so much — where your servers come from is your first line of defense. And remember the mechanics: the model's alignment does not protect you, because the attack never asks for anything forbidden in one piece.
Shadow MCP: the servers nobody approved
GhostSplice assumed a malicious server already plugged in. But who decides what gets plugged in? In a team, the honest answer is nobody. That is the problem Cloudflare calls shadow MCP: all the servers that developers connect to their agents without any security review. Until recently that traffic was invisible — an MCP request looks like any other HTTPS call.
Cloudflare changed that with detection at the protocol level. Since the spec update, every conforming MCP client sends an MCP-Protocol-Version header on its requests, and Gateway inspects that header on all the TLS traffic it decrypts. A security team can now see every MCP server used in the company, with a dedicated dashboard: unique servers, users, request volumes. This header approach beats filtering by domain name, because an MCP server has no reason to call itself mcp-something — the protocol gets spotted by what it says, not by what it claims to be.
The team can also act: an is_mcp selector lets you block any MCP traffic that did not come through an approved portal. The portal is the other half of the setup — one single access point that groups the vetted servers behind identity authentication.
The latest spec version pushes visibility further. The new Mcp-Method and Mcp-Name headers expose the requested operation and the tool being called, without the firewall having to open the request body. A team can tell an agent reading a ticket from an agent deleting fifty of them, right at the network level.
Cloudflare splits this into two cases: pure shadow MCP, a server that was never approved, and portal bypass, an approved server reached directly around the checkpoint. Both get blocked with the same base rule. The logic is simple: everything through the portal is known and logged, everything else is blocked. For a company, that is the end of the ghost MCP server installed on a Friday night.
WriteGuard: permissions tool by tool
Even an approved server can do damage, because an agent inherits every one of its user's rights at once. That is where WriteGuard comes in, which Cloudflare just opened in private beta. The idea: classify every tool of every MCP server into a risk tier, and apply a different policy per tier.
- A read passes with no friction.
- A contained write, like posting a comment, passes but enriched: the action is signed as coming from an agent, on behalf of a specific human, and an audit event goes to a central log.
- A critical action — merging code, deploying to production, mass deleting — is blocked before the server even handles it.
The GitLab example in Cloudflare's post shows the gradation: reading a merge request passes, commenting on it passes with attribution, and merging it is refused until a human does it themselves.
The most interesting part is the identity model. The agent keeps the permissions of the employee it serves, but every write now carries two signatures: the person, and the agent session acting for them. Downstream systems can finally tell a hand-made change from a machine-generated one, and the audit ships asynchronously to a central log, scrubbed of sensitive data. Until now an agent was indistinguishable from its human in the logs; for an incident audit that changes everything — one query tells you whether Tuesday's dubious merge came from a hurried coworker or an agent session that got creative.
Cloudflare is not selling a theory; they describe their own internal use: their portal connects 27 MCP servers, up from 13 in April. That number tells the real story — even at Cloudflare, the server count doubles in a few months, which is exactly why per-tool control becomes necessary. The direction the industry is taking is clear: stop trusting the whole server, and decide action by action what an agent is allowed to do.
The limit: what none of this fixes
The limits need saying plainly. WriteGuard is a private beta behind a signup form, and Gateway's detection needs a Cloudflare Zero Trust deployment with TLS inspection turned on: for a solo developer or a small team, that is simply not your infrastructure. Even in a company, the detection only sees the network traffic it decrypts — a local MCP server running over stdio, launched as a plain process on your machine, stays invisible to Gateway. Which is exactly how most of the servers developers install actually run.
Above all, none of these tools repairs the core mechanic GhostSplice exposed: as long as an agent freely combines whatever enters its context, harmless fragments will keep recomposing into hostile instructions. The ASSET researchers say it themselves: the fix requires treating tool output as data, never as instructions, and that separation does not exist natively in agents yet.
In the meantime their recommendations come down to three moves: stop values coming out of one tool from feeding another tool's arguments unchecked, keep the ability to deny each tool invocation by hand, and treat any annotation from an unvetted server as hostile by default. None of the three is automatic today: you apply them, or nobody does. Treat everything Cloudflare ships here as seat belts, not brakes — it limits the damage, it does not prevent the collision.
What we'd apply to our own setup
What to do, starting today:
- Inventory. List the MCP servers really plugged into your agents, and remove the ones you no longer use.
- Sort by provenance. An official server from a known vendor, yes. A 40-star GitHub repo found in a thread, no — not until you have read what it does with your data.
- Scope the rights. Give each server a dedicated token with the minimal scope, never your master key, and rotate those tokens like you would for any production system.
- Keep your hand on sensitive actions. An agent that writes, merges, or deletes has to come back through you — the handmade version of what WriteGuard industrializes.
- Apply the GhostSplice rule day to day. When your agent chains tool actions you did not ask for, stop it and read what the server has been telling it.
Every agent client can list its connected servers and their tools, and that list takes thirty seconds to read. Those thirty seconds are the best time-to-security ratio in your whole setup.
If you are at a company, add the network layer: Gateway's MCP detection and the portals are worth the rollout, because shadow MCP already exists in your org, whether you see it or not.
MCP is not the problem — the speed at which we handed it our keys is.
