Tutorials
MCP Security: Tool Poisoning, Line Jumping & Rug Pulls Explained
Flavius Dinu11 min read
TL;DR:
- Every MCP server you connect to sends information to your model's context, and the model treats descriptions as trusted developer instructions
- Tool poisoning hides malicious orders in the metadata, so a simple function can exfiltrate credentials, while still returning the right answer
- Line jumping can poison your context at connection time, and rug pulls let a server you approved a couple of days ago swap in a malicious description today
- MCP security can be implemented by treating MCP servers like dependencies (pinning them by version and content hash), defaulting to read-only, and asking for new approvals after new changes
You probably spent the last few months plugging MCP servers into everything, especially if you run infrastructure daily. You already have an agent that can list your pods, query Prometheus, open a PR, check your database, and most of them are connected to different MCP servers.
So, every MCP server you connect can talk straight into your model's context, and your model mostly believes what it hears. That is the gap tool poisoning walks through, and it's why MCP security has been spiking as a search term.
In this article, we will walk through what MCP tool poisoning is and what it looks like, how line jumping and rug pull attacks work, and how to secure your MCP server.
What is MCP tool poisoning?
The normal prompt injections are similar to something like this: someone hides "ignore your previous instructions" in a web page or a Jira ticket, your agents read it, and then it goes off the rails. In this case, those instructions are visible, giving filters and security tools a chance to detect and block them.
When your MCP client connects to a server, it asks the server what it can do, and the server replies with a list of tools, along with their descriptions and parameters. After that, all the text is loaded into your model's context, so it knows when and how to use each tool, and it reads every bit of it, including anything the author should not mention.
What makes tool poisoning more dangerous than a traditional prompt injection attack is that the model assumes tool descriptions were written by the developer who configured its environment and treats them as trusted instructions. That's why tool poisoning resembles a supply chain attack more than a prompt injection attack because, instead of tricking the model through user-controlled input, an attacker compromises something the model already trusts.
Be aware that the bad text does not have to sit in the main description. Also, tool parameters, error messages, and even the output a tool returns can all carry instructions. Researchers at CyberArk showed that no output from an MCP needs to be trusted blindly.
What does an MCP tool poisoning attack look like?
Invariant Labs publishes a tool with a simple add(a, b) function that adds two numbers. This looks easy, and nobody reviews a calculator. But when the input was added, the description secretly told the model to go read the user's SSH keys and other private files and quietly send them along before doing the math. You ask only to add 2 and 3, but the agent reads the tool description, sees the hidden order, grabs your ~/.ssh/id_rsa, sends it off, and then returns 5.
The part you see looks innocent, but the orders the model actually follows have never been shown to you. MCP tools usually run with all your access, and the damage can reach anything your machine and your credentials can reach. So, for someone who runs infrastructure, it means that the MCP tools use your credentials, your kubeconfig, and every cluster they open.
What is a line jumping attack in MCP?
Most people think that a poisoned tool can only hurt you if you actually run it. When your client connects to a server, the first thing it does is ask for the tool list. The server sends back every tool plus its full description, and your client drops all of that into the model's context right away, before you've typed anything.
This happens because the model can't pick the right tool unless it can already see all of them and read what each one does. So the moment you connect, the model has read every word of those descriptions, hidden instructions included, and it reads them as trusted setup text.
Trail of Bits coined the term "line jumping" because the malicious instructions effectively cut to the front of the line: they're injected into the model's context during tool discovery, steering the agent before any tool call occurs. Being careful which tools you run does not protect you. It is enough to have a poisoned server connected, and it gets worse with multiple servers.
What is an MCP rug pull attack?
Being careful and reading every tool description before approving a server is a good habit, but it is not enough.
When you connect to a server for the first time, it shows a completely clean tool. You review it, and if it looks fine, you approve it. After a few days, the server quietly swaps the description for a bad one, so it's the same tool name, the same surface you'd glance at, but the orders now handed to the model are poisoned.
So in this case, since your client already trusts that tool, it will not ask you again about anything. On the second launch, the server swaps its reply so that the poisoned description tells the agent, for example, to reach out to a connected WhatsApp server and forward your chat history to the attacker.
So keep in mind that reviewing a server once does not mean you have real protection. Trust has to be tied to the actual content of the tool, not the fact that you clicked approved at some point in the past.
Are MCP server vulnerabilities real or just theory?
There are two CVEs (Common Vulnerabilities and Exposures) that helped bring this class of attacks into the spotlight, and both affected Cursor, the AI code editor used by many of us almost every day.
The first is CVE-2025-54136, a CVSS 7.2 vulnerability identified by Check Point Research and dubbed MCPoison. It showed how Cursor handled changes to MCP config files by tying trust to the config entry's name rather than to the command it actually ran. So an attacker commits a harmless MCP config to a shared GitHub repo, a teammate opens the project and approves it, and then the attacker quietly edits that same entry to run something else. There is no new prompt, no warning because the name never changed.
The second one is CVE-2025-54135 (CurXecute) that has the same root cause: an MCP server feeds instructions into the agent's context and gets code to run.
On July 29, Cursor shipped a fix in version 1.3 after Check Point reported MCPoison to Cursor on July 16, 2025. The fix states that any change to an MCP config, even adding a single space, forces you to approve it again.
Why do AI agents fall for MCP prompt injection?
One reason AI agents fall for MCP prompt injection is that tool descriptions are considered safe because a developer wrote them. Your agent gets a description with no author attached, no signature, and no warning that a stranger wrote it, and it treats that text like it came from the system prompt.
Another reason is: MCP tools usually run with your permissions, so a poisoned tool can do anything you can do; you often have several servers connected at once, and a poisoned one can turn a clean one into poisoned as well; and most clients still can't spot bad instructions buried in descriptions, so nothing catches this for you by default.
How do you secure an MCP server?
Here is a list of practical fixes, and none of them mean giving up MCP:
- You should pin servers by version and content hash, not by name, and you should not trust a tool just because the name matches. Pin the exact version and hash you approved, and treat any content change as a new thing that needs review
- After every change, ask for approval again. In case a tool's description, command, parameters, or abilities change at all, your client should stop and ask you, and that kills the rug pull.
- Diff every server update before it loads. This means you should compare every time a server is updated to what you last approved before it reaches your model.
- Run scanner tools like MCP-Scan from Invariant Labs to check your client config and tool descriptions before anything runs, looking for prompt injection, tool poisoning, rug pull patterns, and unsafe settings.
- Keep your permissions tight, and go read-only where you can. Having broad access will turn bad descriptions into a real breach, so you need to give the server the least power that still does the job. The Lens MCP Server runs in read-only mode, so an AI assistant can list clusters, pull Prometheus metrics, view alerts, and help you troubleshoot, but it cannot change your resources.
- You should put guardrails around your agents. When you have agents working across a team, you want policy, audit logs, and cost limits in front of them instead of raw access. That's the idea behind Lens Agents, which wrap agents in enterprise governance and MCP integrations so the damage stays contained even as you hand them more work.
Key Points
MCP is genuinely great; you only need to update how you think about it. Every server you connect is not just a new ability; it's an untrusted input pipe straight into your model's context, running with your permissions.
You should treat MCP servers like dependencies, so pin them, diff them, re-approve them on every change, scan them before they run, and give them the least power that gets the job done.
If you want to get hands-on, run MCP-Scan against your current setup, read the MCPoison write-up from Check Point, and then look at how a read-only MCP server changes the math.
At the same time, if you are looking for a platform that can help you govern your AI agents and connects to your MCP servers securely, you can try Lens Agents, and you'll see exactly how we can help.
Check out this video to see an SRE agent built with Lens Agents in action:
FAQ
What is MCP tool poisoning in plain terms?
It's an attack that hides instructions inside a tool's description instead of inside your prompt. So, your model will read that description, see the hidden instructions, and follow them as if a trusted developer wrote them. What makes this process dangerous is that you never see the malicious part.
How is this different from normal prompt injection?
A normal prompt injection hides the attack in content your agent reads (a web page or an email). Tool poisoning hides it in the tool's own metadata, which your model treats as trusted system-level text.
What is a rug pull attack?
This happens when a server shows a clean, safe tool while you review and approve it, but then quietly swaps in a malicious version later. The tool name stays the same, so your client keeps trusting it and never asks you to approve it again.
Has anyone actually been hurt with MCP attacks, or is it just theory?
It's not just a theory; researchers disclosed multiple vulnerabilities in 2025, including CVE-2025-54136 (MCPoison) and CVE-2025-54135 (CurXecute), both of which demonstrated how attackers could achieve code execution through Cursor. The latest public research showed that there are no confirmed reports of data loss or real-world compromises caused by tool poisoning. Now is the right time to put security controls in place before these attacks become commonplace.
How do I secure my MCP servers?
To keep your MCP server secure, pin each server to an exact version and content hash instead of trusting it by name, require new approval whenever anything changes, diff every update before it loads, and run a scanner like MCP-Scan over your tool description. On top of that, keep permission tight and go with read-only access so a poisoned tool has far less it can do.
Does read-only access actually help?
Yes, a lot, because most of the damage from tool poisoning comes from the tool running with your full permissions. In the case of a server that can only read, a poisoned description can still try to trick your agent, but it can't delete resources or make changes. As mentioned before, tools like Lens MCP Server can help reduce your risk by running in read-only mode.
Can a poisoned server attack my other, trusted servers?
If your agent is connected to multiple MCP servers, a poisoned server can attack other trusted servers and manipulate them into misusing others. Invariant Labs demonstrated this by showing how a malicious server could convince an agent to exfiltrate a user's WhatsApp chat history through a separate, trusted server. Here, the best practice is to connect only the MCP servers you actually need for a given session and to grant each one the minimum permissions required to do its job.