MCP server context poisoning: conversation history manipulation and tool result injection

The attack surface: everywhere data becomes context

Direct prompt injection — where the user types adversarial instructions into the chat — is well-understood and often mitigated at the application layer. Context poisoning is subtler: the adversarial content arrives as the result of a legitimate tool call, not as direct user input. The LLM agent treats tool results as trusted data because they come from the server, not the user.

Context poisoning vectors in MCP servers

1. External URL fetch

Any tool that fetches external URLs and returns the response body to the LLM is a context poisoning vector. Attackers can control the content of pages they own; they can also perform stored injection attacks by getting their content onto pages your users legitimately access.

2. File system reads

A read_file or search_codebase tool that reads files from disk and returns their content can be poisoned if an attacker can write to those files — through a prior tool call, a supply chain compromise, or by tricking the user into saving a malicious file. This is particularly dangerous in coding assistant contexts where the agent reads and executes content from the user's repository.

3. Database query results

A tool that executes user-supplied queries and returns rows can return rows containing adversarial instructions. If another user was able to INSERT a row containing injection content, your agent will consume it during a later query. This is the MCP equivalent of stored XSS — the injection is stored in the data layer, not delivered in the request.

4. Third-party API responses

Responses from external APIs — GitHub issue bodies, Jira ticket descriptions, Slack messages, email content — can contain adversarial instructions. The attacker doesn't need to compromise your server; they just need to get their content into a data source your agent reads.

Defenses

1. Tag external content as data, not instruction

Wrap all external content in a structured envelope that signals to the LLM that what follows is data to be analyzed, not instructions to be followed:

// src/tools/fetch-url.ts
export async function fetchUrlHandler(args: { url: string }) {
  const response = await fetch(args.url);
  const body = await response.text();

  // Wrap in a data envelope — not injected raw into context
  const safeOutput = [
    `[EXTERNAL DATA: ${args.url}]`,
    `Content-Type: ${response.headers.get("content-type")}`,
    `Length: ${body.length} bytes`,
    `---BEGIN DATA---`,
    truncate(stripHtmlComments(body), 8_000),
    `---END DATA---`,
    `[END EXTERNAL DATA]`,
  ].join("\n");

  return { content: [{ type: "text", text: safeOutput }] };
}

function stripHtmlComments(html: string): string {
  return html.replace(/<!--[\s\S]*?-->/g, "");
}

function truncate(text: string, maxLen: number): string {
  return text.length > maxLen
    ? text.slice(0, maxLen) + `\n[TRUNCATED: ${text.length - maxLen} bytes omitted]`
    : text;
}

The [EXTERNAL DATA]/[END EXTERNAL DATA] envelope and the ---BEGIN/END DATA--- markers create a textual boundary that a well-instructed LLM can use to distinguish data from instructions. Stripping HTML comments removes the most common hidden-text injection vector. Truncating at 8,000 characters limits context window consumption from adversarial large payloads.

2. Suspicious content filter at the MCP layer

Before returning external content to the LLM, scan it for patterns that resemble injection attempts:

// src/tools/content-filter.ts
const INJECTION_PATTERNS = [
  /\bSYSTEM\s*:/i,
  /\bINSTRUCTION\s*:/i,
  /\bASSISTANT\s*:/i,
  /\bYOU\s+ARE\s+NOW\b/i,
  /\bIGNORE\s+(PREVIOUS|ALL|YOUR)\s+INSTRUCTIONS\b/i,
  /\bFORGET\s+(EVERYTHING|YOUR|PREVIOUS)\b/i,
  /\bACT\s+AS\b.*\bAI\b/i,
  /\bNEW\s+SYSTEM\s+PROMPT\b/i,
  /\bOVERRIDE\b.*\bINSTRUCTIONS\b/i,
];

export function filterSuspiciousContent(text: string): {
  clean: string;
  flagged: boolean;
  matches: string[];
} {
  const matches = INJECTION_PATTERNS
    .filter(p => p.test(text))
    .map(p => p.toString());

  if (matches.length === 0) {
    return { clean: text, flagged: false, matches: [] };
  }

  // Return sanitized version with suspicious sections marked
  const sanitized = INJECTION_PATTERNS.reduce(
    (t, p) => t.replace(p, "[FILTERED]"),
    text
  );

  return { clean: sanitized, flagged: true, matches };
}

Log flagged content for security monitoring. Consider refusing to return flagged external content entirely in high-security contexts, returning only a summary instead.

3. Result size limits

Large tool results consume more of the context window, which both increases the attack surface and can crowd out system prompt instructions that establish trust boundaries:

const MAX_TOOL_RESULT_BYTES = {
  fetch_url: 8_000,
  read_file: 16_000,
  search_codebase: 12_000,
  query_database: 4_000,
} as const;

function capResult(toolName: keyof typeof MAX_TOOL_RESULT_BYTES, text: string): string {
  const limit = MAX_TOOL_RESULT_BYTES[toolName];
  if (text.length <= limit) return text;
  return text.slice(0, limit) +
    `\n[Result capped at ${limit} characters. Use a more specific query to retrieve targeted data.]`;
}

4. Session isolation

If your MCP server maintains any session state (cached context, conversation memory, tool results stored for multi-turn reference), ensure that poisoned context from one session cannot bleed into another. Use per-session scoped storage with TTLs:

// Never share a mutable context cache across sessions
const sessionContexts = new Map<string, { data: string; expiresAt: number }>();

function getSessionContext(sessionId: string): string | null {
  const entry = sessionContexts.get(sessionId);
  if (!entry || Date.now() > entry.expiresAt) {
    sessionContexts.delete(sessionId);
    return null;
  }
  return entry.data;
}

// Sessions expire after 30 minutes of inactivity
const SESSION_TTL_MS = 30 * 60 * 1000;

SkillAudit findings for context poisoning

Context poisoning is one of the more nuanced findings in SkillAudit reports — it's not always a clear-cut finding because the severity depends on what tools your server provides and how the LLM agent is instructed. Run a free audit to see how your server is assessed for this vulnerability class.