Start with the job: reduce prompt-injection risk across MCP tools and data

Prompt injection becomes an MCP security problem when untrusted resource or tool output can influence another capability with sensitive data or external side effects. The control objective is to break that path, not to classify every malicious sentence perfectly.

Prompt instructions and output filtering are useful but cannot replace capability isolation. A model can misinterpret novel content, so high-impact tools need controls outside the same text channel.

Make the operating boundary visible

An indirect injection may enter through a page, issue, document or tool result, then compete with trusted instructions in model context. If the host exposes broad credentials or automatic write tools, the model's mistaken decision can become a real consequence.

FIG. 01 / Conceptual model

Indirect instruction path

Threat trace from untrusted MCP data through model context toward a consequential tool
Conceptual model: injection risk is the complete path from external data to privileged consequence.

Build a reproducible path

For MCP Prompt Injection: Attack Paths and Controls, use a small fixture that another developer can repeat without privileged production data. Change one boundary at a time and preserve the exact configuration needed to explain how the page's decision was reached.

  1. Mark external resources and tool results as untrusted data.
  2. Separate sensitive context from tasks that do not require it.
  3. Narrow tool schemas, credentials, egress and write permissions.
  4. Require review for consequential actions and test adversarial fixtures end to end.

Keep secrets outside the mcp prompt injection artifact. Record variable names, scopes and owners, then verify the relevant system of record whenever this tool or workflow can change external state.

Record evidence that survives a rerun

A meaningful test records the injected content, context available to the model, attempted tool call, blocking layer and downstream result. A refusal sentence without inspecting the tool path is insufficient.

  • Untrusted content origin
  • Sensitive context visible in the same run
  • Tool schema, credential and network reach
  • Approval decision and downstream audit result

Date the MCP Prompt Injection: Attack Paths and Controls record and keep factual observations separate from inference. If a claim depends on a hosted service, preview feature or moving SDK, name that dependency beside the claim.

Use a decision rule and a stopping rule

Automate only actions whose worst plausible mistaken call is contained and reversible. Increase human review and environment isolation as data sensitivity and action consequence rise.

Test direct requests, instructions hidden in retrieved content and payloads that try to redirect the agent to another tool. Confirm the denied call never leaves the boundary and that secrets are absent from model-visible error text.

FIG. 02 / Decision aid

Contain the consequence

Decision matrix matching prompt-injection exposure to data and tool controls
Decision aid: combine context separation, narrow capability and approval as consequence increases.

Protect against predictable failure and continue deliberately

For MCP Prompt Injection: Attack Paths and Controls, the architecture review flags three recurring failure modes: specification versions are mixed; local and remote trust boundaries are conflated; a server is recommended without permission review. Treat them as release checks, not footnotes. This page remains draft when its exact implementation or intent evidence is still research-gated.

Use the MCP security threat model next: it traces data and tool access to concrete consequences.

Use the MCP authorization guide next: it covers resource-bound tokens, validation and upstream separation.

Use the MCP field guide next: it reconnects the decision to protocol roles and versioned boundaries.