Your read-only MCP server can still carry a prompt injection

A read-only MCP tool fetches a support ticket. The ticket body contains customer-written text, including an instruction to send private account information to another service. Fetching the ticket was authorized. Following the instruction was not.

This is indirect prompt injection: external content tries to redirect the agent. The agent may have other tools and private context that the ticket's author cannot access directly.

Separate data from authority

The user authorized the agent to read the ticket for a task. Text inside that ticket does not authorize a different task, an additional data lookup or a call to another connected tool.

Preserve that distinction in tool contracts and orchestration. Identify the source of returned text and mark externally controlled fields as untrusted. Keep credentials in the execution layer instead of including them in model-visible payloads.

OWASP's prompt-injection guidance describes indirect injection through external content and the limits of single-layer defenses. Source labeling and instructions help establish boundaries, but neither guarantees that a model will always follow them.

Constrain the actions around the read

A useful defense does not depend entirely on recognizing suspicious language. Scope credentials, validate tool arguments and restrict output destinations. Validate destinations before allowing a tool to send private results to a URL found in customer content.

Apply authorization to each action using the real user and intended resource. A tool response cannot grant a new permission. For consequential writes or external communication, require an appropriate approval path tied to the intended action rather than accepting instructions embedded in retrieved content.

Restrict what the task can retrieve. If the user needs one account's open tickets, returning all accounts' tickets widens both the data exposure and the content the agent must interpret. Read-only access can still expose confidential information.

Understand tool annotations

The MCP tools specification describes tool behavior and annotations. Hints about read-only or destructive behavior are metadata for consumers; they are not a substitute for enforced permissions or evidence that output text is benign.

Likewise, a clean tool schema validates the structure of a call, not the intent of text inside a returned field. Both a legitimate customer message and an injection attempt can be valid strings under the same schema.

Where output screening is used, treat its result as another imperfect signal. Keep the execution controls in place for content that the screen does not recognize.

Test the whole connected workflow

Build isolated cases containing hostile instructions in plausible fields: a ticket comment, document title, search snippet or API error description. Verify that the requested task remains bounded and that unapproved calls or external destinations are denied.

Inspect the actual call trace, not only the final answer. A model might eventually produce a normal response after having attempted an unwanted action. Record denied attempts and sanitize retained test transcripts.