MCP Prompt Injection: How Tool-Calling Agents Get Hijacked (and How to Defend)

What changes when prompt injection meets MCP

A model with no tools that gets prompt-injected produces bad text. Annoying, sometimes embarrassing, rarely catastrophic. A model with five MCPs installed — filesystem, GitHub, Slack, Gmail, Stripe — that gets prompt-injected can delete your repo, send a message to your team, email a customer, or refund a charge. The injection itself is the same; the blast radius is dramatically larger.

This is why the 2025-06-18 MCP specification explicitly calls out confused-deputy attacks. The model is a deputy acting on the user's behalf. When that deputy is manipulated by a third party (a malicious page, a poisoned tool result), it makes calls the user did not authorise. Defending against this is the job of the MCP client, the MCP server, and the user — none of them alone.

The three attack patterns you will see

Four defenses that move the needle

1. 1

   Capability scoping

   Only install the MCPs each workflow needs. A code review conversation should not have payment or email access. A research conversation should not have filesystem write. If your client supports per-conversation MCP profiles, use them. If it does not, lean on separate user accounts or separate client installs to isolate capability sets.

2. 2

   Confirmation gates on destructive calls

   Configure your MCP client to require explicit user confirmation before any tool call that writes, deletes, sends, or transfers. Claude Desktop, Cursor, and most agent frameworks support this — and the MCP spec encourages servers to declare the side-effect profile of every tool so the client can highlight the risky ones.

3. 3

   Read-only by default

   When you install an MCP that supports both modes, start with read-only. Many database, filesystem, and SaaS MCPs ship with explicit read-only flags. Use them during prototyping, audit the tool calls, and graduate to read-write only after you trust the workflow on this conversation.

4. 4

   Tool-call audit trails

   Pick an MCP client that logs every tool call with arguments. After any session that touches real systems, scan the log for unexpected calls — different tool, different MCP, or arguments that do not match what you asked for. This is the cheapest detection mechanism and the one most often skipped.

What MCP server authors should do

• Declare side effects on every tool. The spec lets you mark a tool as read-only, destructive, or interactive. Clients use this to decide what to highlight.
• Default to the safest mode. A new install should not be able to wipe data without the user opting in.
• Keep the tool surface narrow. Five sharp tools are safer than fifty fuzzy ones — and easier for the model to use correctly.
• Sanitise content you return to the model. If your tool fetches arbitrary web content, consider stripping prompt-injection patterns or labelling output as untrusted.
• Require a confirmation token for high-impact actions. A second round-trip for destructive calls turns a one-shot exploit into a two-step process that a human can interrupt.

Frequently asked questions