MCP prompt injection is an attack where instructions hidden in the content an MCP tool returns, such as a GitHub issue, an email, a chat message or a web page, get followed by the AI agent as if the user had typed them. The server does not have to be malicious. The agent reads untrusted text, treats it as orders, and uses its other tools to act on them. Two documented cases show the pattern clearly, OWASP lists it as MCP06 in its MCP Top 10, and the defenses that limit it are about what the agent is allowed to reach, not about trusting the text.
What MCP prompt injection is, and what it is not
An agent connected to MCP servers mixes three kinds of text in one context: the user's request, the descriptions of the tools it has, and whatever those tools return. A language model has no reliable way to tell instructions from data in that mix. MCP prompt injection uses the third kind: the attacker plants instructions in content the agent will fetch later.
This is different from an MCP tool poisoning attack, where the instructions sit in a tool's description and arrive the moment the server loads. With tool poisoning, the server is the problem. With prompt injection, the server can be the official, well-maintained one, and the problem is the content flowing through it. That distinction matters for defense. Reviewing a server's tool descriptions, which our MCP security checklist covers, does nothing against an attack that arrives in tomorrow's inbox.
Why MCP raises the stakes
Prompt injection existed before MCP. What MCP changes is what an injected instruction can do next. A chatbot that reads a poisoned web page can only say something wrong. An agent with MCP servers can read private files, query a database, push code or send a message, all with the user's credentials.
The dangerous setup has three parts: a tool that reads content an outsider can write, a tool that can reach private data, and a tool that can send data somewhere. Each part is harmless alone. Together, one injected paragraph can pull private data through the second tool and push it out through the third. Most real agent setups have all three, because developers connect servers for convenience, one at a time, and nobody looks at the combination.
Case 1: a GitHub issue that leaked private repositories
In May 2025, Invariant Labs showed the pattern against an agent using the official GitHub MCP server. The attacker opened an issue in a public repository with instructions hidden in its text. The user then asked their agent to look at the open issues in that repository, a normal request.
The agent read the issue, followed the instructions, pulled information from the user's private repositories, and posted it in a pull request on the public repository, where the attacker could read it. The researchers report that the leak included private project details and the user's salary. They were explicit that this was not a flaw in the GitHub MCP server's code. The server did what it was built to do; the agent's token could simply reach every repository the user could.
Case 2: a WhatsApp message read as tool output
Invariant Labs' WhatsApp research from April 2025 is often cited for its rug pull, but its second experiment is pure MCP prompt injection. No malicious server was involved. The attacker sent the victim an ordinary-looking WhatsApp message containing instructions. When the agent listed the user's chats through the trusted WhatsApp MCP server, it read that message as tool output and acted on it, leaking the user's contact list.
The lesson is that any channel an outsider can write into becomes a way to instruct the agent: messages, tickets, pull request comments, support emails, documentation pages, even file names. If an agent can read it, an attacker can try to use it.
What OWASP says: MCP06 and intent flow subversion
The OWASP MCP Top 10 lists this risk as MCP06. The owasp.org project page names it prompt injection via contextual payloads, while the item page uses the name intent flow subversion; the list is in beta and names can change. The item page describes malicious instructions in retrieved context, such as resources, schemas or tool outputs, overriding the user's original intent while the agent appears to still be doing the original task.
OWASP gives two scenarios that match real setups: an agent asked to review pull requests that finds a hidden file telling it to delete a production branch, and an agent asked for a server status check that receives a fake emergency in a tool output and exports a database to an outside endpoint. The warning signs it lists include treating retrieved text as instructions, never checking whether the next tool call still serves the original goal, and putting system instructions, user intent and untrusted content in one flat prompt.
How to defend against MCP prompt injection
No filter reliably catches every injected instruction, so the defenses that hold are the ones that limit what a successful injection can do.
Narrow every token. Invariant's first recommendation after the GitHub case was least privilege: restrict an agent to one repository per session, or use a token that reaches only what the task needs. The MCP specification calls this scope minimization. A token that cannot see private repositories cannot leak them.
Separate reading from acting. Avoid giving one agent session a tool that reads outsider content and a tool that sends data out. Where both are needed, keep human approval on the sending step, and make sure the approval shows what is being sent and where.
Check intent, not just permission. OWASP recommends anchoring the user's original goal and checking each planned tool call against it, for example blocking write or delete actions when the user asked for a read. An independent check that sees only the user's request and the proposed action is harder for injected text to steer.
Treat tool output as data. Mark retrieved content as untrusted in the prompt and tell the model to treat it as information only. This lowers the success rate; it does not remove the risk, which is why it comes after the steps above.
Know what is connected. You cannot spot a dangerous combination of servers you do not know about. Start by learning how to find MCP servers on developer machines, then review which agents can read untrusted content and also reach private data. Log tool calls so that, if an injection succeeds, there is a trail to follow.
Test your own setup
The simplest test is harmless and quick. In a test repository, open an issue whose text asks the agent to add a specific, unusual word to its next reply, then ask the agent to summarize open issues. If the word appears, the agent is following instructions from content it reads, and every tool it holds is in reach of whoever can write an issue. Repeat the test for each channel your agents read, such as tickets, email or documentation, and note which tools were available in each session.
Next step: find the agents most exposed to MCP prompt injection
MCP prompt injection is most dangerous where one agent can read outsider content, reach private data and send data out. Finding those agents starts with a full inventory of what each one has connected. Run a Discovery Scan to see every agent and MCP server in your org, and what each server can reach.