MCP Security Engineering · Context Injection · L2 LAB
MCP Context Injection Risk Design
Intermediate LAB teaching how to design and review MCP context injection risks, untrusted context sources, instruction hierarchy conflicts, prompt boundary failure, and reviewer-safe mitigation evidence without running live MCP infrastructure.
Overview
This LAB teaches how to review MCP context injection risk before external context is allowed to influence an AI workflow, tool decision, recommendation, or policy-sensitive output.
Context injection happens when untrusted or lower-authority content attempts to influence the model outside its intended role. In MCP workflows, injected context may come from files, tickets, webpages, database records, tool responses, logs, messages, prompts, or resource descriptions.
Concept Deep Dives
Expand each concept when studying MCP context injection risk design.
1. What is MCP context injection?
MCP context injection is the risk that data exposed through an MCP server contains instructions, misleading claims, hidden prompts, malicious text, or authority-confusing content that attempts to steer the AI workflow beyond the approved task.
2. Why does source authority matter?
Source authority defines how much trust a workflow should place in a context source. A policy document, user-submitted text, vendor response, webpage, log entry, and tool output should not have the same authority over model behavior or tool decisions.
3. How can instruction hierarchy fail?
Instruction hierarchy fails when lower-trust context is allowed to override system rules, developer rules, business policy, human approval requirements, or safety boundaries. Context should inform the model, not silently rewrite the operating rules.
4. What makes MCP context high risk?
Context is high risk when it is externally controlled, user supplied, tool generated, stale, unverified, cross-tenant, sensitive, or capable of influencing tool execution, approvals, access decisions, customer messaging, financial actions, or production changes.
5. What controls reduce context injection risk?
Controls include source labeling, authority ranking, context sanitization, prompt boundary separation, instruction hierarchy enforcement, retrieval filters, output grounding, refusal behavior, human approval gates, and evidence capture.
6. What evidence should reviewers capture?
Evidence should document source type, authority level, context sensitivity, injection indicators, expected controls, observed gaps, uncertainty, and remediation. It should not include secrets, customer data, credentials, or live MCP tool output.
Visual MCP Context Injection Risk Model
A strong MCP context review separates useful context from unsafe instruction influence.
Learning rule: MCP context is safe only when source authority, instruction hierarchy, prompt boundaries, and approval gates are explicit.
Example Scenario
A support assistant retrieves a customer-submitted attachment through an MCP server. The attachment includes normal troubleshooting details, but also contains text telling the assistant to ignore approval policy and execute a refund tool. The learner must classify the attachment as untrusted context and prevent it from becoming an instruction source.
Evaluate whether retrieved context is being treated as data or incorrectly promoted into instruction authority.
Synthetic context sample only. No real customer attachment, live MCP server, production tool, credentials, or customer data.
The workflow should label the retrieved content as untrusted context, reject embedded instructions, and preserve approval gates for sensitive actions.
Reviewer-safe notes covering source authority, injection indicator, control gap, refusal requirement, approval boundary, and remediation.
Safe MCP context injection review:
identify the context source
classify the source authority
label retrieved content as data
separate data from instructions
detect embedded instruction attempts
verify approval gates remain intact
ground responses in trusted sources
refuse unsafe instruction override
document uncertainty and gaps
recommend context boundary controls
Result:
The workflow can use retrieved context without allowing untrusted content to rewrite operating rules.High-Risk Anti-Pattern
A dangerous pattern is allowing retrieved MCP context to directly influence tool execution or approval-sensitive decisions without authority ranking or instruction separation.
Unsafe pattern:
- untrusted context treated as instruction
- no source authority label
- no prompt boundary separation
- no injection detection
- no retrieval filtering
- no approval preservation
- no refusal behavior
- no reviewer evidence
Risk:
instruction hierarchy bypass
tool execution manipulation
approval bypass
data exposure
unsafe customer communication
policy violation
production mutation
loss of auditability
Safe alternative:
label source authority
treat retrieved content as data
separate context from instructions
filter and sanitize inputs
preserve system and policy hierarchy
require approval for sensitive actions
ground outputs in trusted context
capture reviewer-safe evidenceGovernance Boundary
This LAB is static and educational. It teaches MCP context injection risk design only. No MCP server is started, no MCP client connects, no tools are invoked, no credentials are handled, and no runtime system is mutated.
Runtime = read-only learning
Backend exposure = false
Public backend exposed = false
MCP server execution = false
MCP client execution = false
Live MCP integration = false
Live tool invocation = false
Live API call execution = false
Context execution = false
Customer data access = false
Credential handling = false
Secret handling = false
Runtime mutation = false
Production enforcement claim = false