Guide · Security
Treat MCP Tool Results as Untrusted Context
Anything an MCP server returns—tool descriptions, Custom Rules, docs snippets, or call results—lands in the model context. Treat it as untrusted data. The host decides what tools may run.
MCP descriptions and results are untrusted context—AI Security treats them as data, never as system policy. Primary control: AI Security
Delivery trust ≠ content trust
Teams often allowlist a "read-only" docs or utility MCP and relax. The server cannot open files itself, so it feels safe. The coding agent already has file, shell, and network tools. If poisoned natural language arrives in the same window as trusted instructions, the deputy executes—without the MCP process ever touching disk.
That is the ContextCrush and GhostSplice pattern family: Custom Rules or split description/result text steer the model; host capabilities do the damage. Prompt text that says "ignore this if it looks like instructions" is not a boundary. The gateway is.
Boundaries that hold
- System / developer policy (trusted): Built by you; never concatenated from MCP text.
- Tool schemas & descriptions (untrusted): Inventory and optionally fingerprint; never grant AuthZ by themselves.
- Tool / docs / RAG results (untrusted): Delimit and label as data. Do not promote to system.
- Host tool execution (privileged): Allowlist + argument validation + AuthZ + HITL for secret-class and destructive paths.
Read-only MCP is not a safety boundary. Anything that can write into the model context is an instruction channel unless the host enforces otherwise.
Controls that survive clever prose
1. Structured roles at the API—MCP payloads stay in a data role.
2. Server-side disposition: the model proposes; the platform decides (Tool Safety).
3. Injection suites that include docs/Custom Rules, split description+result, and post-approval metadata flips—not only chat jailbreaks.
4. Output / egress guards where secrets leave the host.
5. Traces that link MCP fetch → model turn → privileged tool proposal.
What "done" looks like
Code review shows MCP text cannot become system policy. High-impact host tools cannot run because a description asked. Adversarial cases fail the release gate when broken. On-call can reconstruct the journey when something weird happened. That is APRF AI Security + Tool Safety—not "we only installed popular MCP servers."
Next: AI Security
Open the related pillar specification for mandatory checks, artifacts, and pass conditions. Self-attest is optional.
Related
- Prompt Injection and Jailbreaks in Production AI
- MCP and Tool Allowlists in Production AI
- MCP Tool Metadata Integrity After Approval
- Context Packing, Truncation, and Trust Boundaries
- Gate Secret File Reads for Coding Agents
- Context7 Custom Rules Mcp Prompt Injection Aprf
- Ghostsplice Mcp Split Instruction Exfil Aprf
- Adversarial Security
- Tool Safety
Frequently asked questions
- Is a read-only MCP server safe?
- Not by itself. It can still inject instructions into the model. Safety depends on how the host treats that text and which privileged tools the agent already has.
- Are tool descriptions different from tool results?
- Both are untrusted context. Descriptions often carry stronger "instruction" framing; results can still smuggle directives. Scan and mediate both.
- Does allowlisting the MCP server fix injection?
- No. Allowlisting decides which host may speak. It does not sanitize what that host says into the model.