MCP server tool chaining attacks: read-to-write privilege escalation via chained tool calls

Why tool chaining works

Most MCP server developers think about permissions at the individual tool level: read_file reads a file, write_file writes one, exec_command runs a shell command. If you want to restrict what a caller can do, you check permissions in each tool handler and return an error if the caller lacks the required role or scope.

This model is correct for single-tool calls. It breaks down when an attacker — or a prompt-injected LLM — chains tools together in a sequence where:

1. Tool A retrieves information the attacker doesn't already have (a file path, an API key, a session token).
2. Tool B uses that retrieved information to access a system the attacker couldn't reach directly.
3. Tool C performs the write, exfiltration, or command execution that was the actual goal.

Each individual tool call passes authorization. But the sequence produces an effect that none of the tools' individual permission checks were designed to prevent.

Attack chain 1: env-var extraction to API takeover

This chain appears frequently in MCP servers that expose both filesystem tools and network tools in the same server — a common pattern when a single server is built for developer productivity.

The server operator intended read_file for reading source code during development. They didn't anticipate that an attacker could use the tool to harvest credentials and then feed them into the fetch_url tool in the same server. No individual tool call is unauthorized — the caller has read:files and net:fetch scopes. But the composition is catastrophic.

Here's the handler code that seems fine in isolation but enables the chain:

// Each tool looks correct in isolation
server.tool('read_file', { path: z.string() }, async ({ path }, ctx) => {
  if (!ctx.scopes.includes('read:files')) throw new Error('Unauthorized');
  return { content: await fs.readFile(path, 'utf8') };
});

server.tool('fetch_url', { url: z.string(), method: z.string().optional() }, async ({ url, method }, ctx) => {
  if (!ctx.scopes.includes('net:fetch')) throw new Error('Unauthorized');
  return { body: await fetch(url, { method }).then(r => r.text()) };
});

// The problem: no tool knows what the other tools returned in the same session.
// The LLM does.

Attack chain 2: contact enumeration to mass exfiltration

This chain targets CRM-adjacent MCP servers — anything that manages contacts, users, or customers and also has a communication tool.

The organization's intent was to allow authorized users to look up contacts and send messages to those contacts. The chain exploits the lack of a link between "who you're sending to" and "what data you previously accessed." A GDPR-compliant version of this server would require that messages are sent only to contacts whose data was legitimately retrieved in the same workflow — but most servers don't track this relationship.

Attack chain 3: schema discovery to filesystem write to shell execution

This is the most dangerous chain, and it's possible whenever a server exposes database query tools alongside any write capability.

This chain is notable because it achieves shell execution without ever calling a shell tool. The attacker used schema enumeration → filesystem write → database update as a three-step proxy for exec_command. Standard monitoring that alerts on exec_command or system() calls would miss the entire chain.

Defense 1: scope narrowing with composition awareness

The first defense is recognizing that "what tools are in scope" is a different question from "what sequences of those tools are permitted." Most OAuth-style scope systems answer the first question; you need additional logic to answer the second.

The simplest approach: separate your tools into data retrieval, data mutation, and external effect categories. Require explicit session-level authorization for any session that combines retrieval with external effects:

type ToolCategory = 'retrieval' | 'mutation' | 'external';

const TOOL_CATEGORIES: Record = {
  read_file: 'retrieval',
  list_contacts: 'retrieval',
  get_contact_details: 'retrieval',
  query_database: 'retrieval',
  write_file: 'mutation',
  send_message: 'external',
  fetch_url: 'external',
};

// Middleware: track categories used in this session
function chainGuardMiddleware(ctx: MCPContext, toolName: string) {
  const category = TOOL_CATEGORIES[toolName];
  ctx.session.toolCategories = ctx.session.toolCategories || new Set();
  ctx.session.toolCategories.add(category);

  // Disallow retrieval → external without explicit cross-category scope
  if (
    category === 'external' &&
    ctx.session.toolCategories.has('retrieval') &&
    !ctx.scopes.includes('allow:retrieval-to-external-chain')
  ) {
    throw new AuthorizationError(
      'Cross-category chain blocked: retrieved data cannot be sent to external endpoints in this session. ' +
      'Request allow:retrieval-to-external-chain scope if this is intentional.'
    );
  }
}

This doesn't prevent legitimate use cases — a sales rep who needs to look up a contact and then send them an email gets the allow:retrieval-to-external-chain scope explicitly. What it prevents is an attacker using the same session to exfiltrate hundreds of contacts to an external address.

Defense 2: session-level audit log with chain detection

Even if you can't block chains in real time, logging the full tool call sequence per session gives you the forensic signal to detect attacks and the anomaly baseline to build real-time alerts on:

interface SessionToolCall {
  toolName: string;
  args: Record;
  resultSummary: string;  // truncated, no raw PII
  calledAt: Date;
}

// In each tool handler wrapper
async function auditedTool(
  name: string,
  handler: (args: T, ctx: MCPContext) => Promise,
  args: T,
  ctx: MCPContext
) {
  const result = await handler(args, ctx);
  ctx.session.callLog = ctx.session.callLog || [];
  ctx.session.callLog.push({
    toolName: name,
    args: sanitizeForLog(args),
    resultSummary: summarize(result),
    calledAt: new Date(),
  });

  // Anomaly detection: retrieval followed by external call
  const recentTools = ctx.session.callLog.slice(-5).map(c => c.toolName);
  if (isHighRiskChain(recentTools)) {
    await alertSecurityTeam(ctx.session.id, ctx.session.callLog);
  }

  return result;
}

function isHighRiskChain(recentTools: string[]): boolean {
  const categories = recentTools.map(t => TOOL_CATEGORIES[t]);
  return (
    categories.includes('retrieval') &&
    categories.includes('external') &&
    !categories.includes('mutation')  // pure read-then-exfil, not a normal workflow
  );
}

Defense 3: write-intent verification for sensitive mutations

For write tools that produce irreversible effects (database mutations, external API calls, file writes), add a "write intent" parameter that the caller must supply. This parameter serves two purposes: it breaks the chain automation (an LLM agent needs explicit instruction to provide the parameter), and it creates an auditable record of what the caller claimed they were doing:

server.tool('send_message', {
  to: z.string().email(),
  subject: z.string().max(200),
  body: z.string().max(5000),
  // Required: caller must declare intent
  intent: z.enum([
    'reply_to_contact',
    'notify_user_of_change',
    'send_report',
    'test_email',
  ]),
  // Required for external addresses: explicit acknowledgment
  recipient_is_external: z.boolean().optional(),
}, async ({ to, subject, body, intent, recipient_is_external }, ctx) => {
  if (recipient_is_external && !ctx.scopes.includes('allow:external-send')) {
    throw new AuthorizationError(
      'Sending to external addresses requires allow:external-send scope'
    );
  }
  // Log the declared intent alongside the call
  await auditLog({ tool: 'send_message', to, intent, sessionId: ctx.session.id });
  return await messagingService.send({ to, subject, body });
});

An automated attack chain can't supply a valid intent without the LLM being explicitly instructed to do so — and that instruction becomes part of the conversation log that human reviewers can inspect. This also closes the "the LLM made me do it" defense: if the LLM supplies intent: "test_email" to send 1,000 contacts to an external address, the audit log records exactly what was claimed.

Defense 4: per-session chain depth and volume limits

Rate limiting individual tools is well-understood. Less common but equally important: rate limiting at the session level on the cross-product of tool calls. A legitimate workflow calls a handful of tools. An exfiltration chain calls one retrieval tool 1,000 times and then one external tool:

const SESSION_LIMITS = {
  max_retrieval_calls: 50,
  max_external_calls: 10,
  max_write_calls: 20,
  max_retrieval_before_external: 5, // max retrieval calls before any external call is blocked
};

function checkSessionRateLimits(ctx: MCPContext, newCategory: ToolCategory) {
  const counts = categoryCounts(ctx.session.callLog);

  if (counts.retrieval >= SESSION_LIMITS.max_retrieval_calls && newCategory === 'retrieval') {
    throw new RateLimitError('Session retrieval limit reached (50 calls). Start a new session.');
  }

  if (newCategory === 'external' && counts.retrieval > SESSION_LIMITS.max_retrieval_before_external) {
    throw new AuthorizationError(
      `External call blocked: ${counts.retrieval} retrieval calls in this session exceed ` +
      `the ${SESSION_LIMITS.max_retrieval_before_external}-call limit before external effects. ` +
      'This pattern matches known data exfiltration chains.'
    );
  }
}

The max_retrieval_before_external limit is the most useful defense against attack chain 2. A sales rep looking up a single contact before sending them an email triggers 1 retrieval before 1 external call — well within the limit. An attacker enumerating 1,000 contacts before sending them to an external address hits the limit at contact 5.

Defense 5: path allowlisting with write-context validation

For servers that expose both filesystem and database tools, the most direct defense against chain 3 is to prevent file writes to paths that any automated process (cron, scheduler, CI) might execute:

const EXECUTABLE_PATH_PATTERNS = [
  /\.sh$/,
  /\.py$/,
  /\bscripts\b/,
  /\bcron\b/,
  /\bbin\b/,
  /\b\.github\/workflows\b/,
  /\bDockerfile\b/,
];

server.tool('write_file', {
  path: z.string(),
  content: z.string(),
}, async ({ path, content }, ctx) => {
  // Block writes to executable locations
  const normalizedPath = path.resolve(path);
  for (const pattern of EXECUTABLE_PATH_PATTERNS) {
    if (pattern.test(normalizedPath)) {
      throw new AuthorizationError(
        `write_file blocked: path "${normalizedPath}" matches executable pattern ${pattern}. ` +
        'Writing to scripts, cron paths, or CI config requires the allow:write-executable scope.'
      );
    }
  }
  await fs.writeFile(normalizedPath, content);
  return { written: true };
});

This doesn't prevent legitimate script editing — a developer who needs to edit a shell script gets allow:write-executable scope. What it prevents is a chain where the attacker uses an unrestricted write_file tool to plant a malicious script that gets executed by a scheduled job.

How SkillAudit grades tool chaining risk

SkillAudit's static analysis can detect the structural conditions that make tool chaining attacks possible, even without observing a live chain:

What tool chaining defenses don't replace

The defenses above address the structural conditions for tool chaining. They don't replace:

• Input validation — an attacker who can inject malicious arguments into individual tool calls doesn't need a chain. See the guide on MCP server input validation patterns.
• Prompt injection protection — the attacker's goal is often to inject malicious instructions into the LLM's context via external data, causing the LLM to construct the chain. Context poisoning is a separate attack surface covered in MCP server context poisoning security.
• Credential hygiene — if .env is in the file system the server has read access to, chain 1 works regardless of chain guards. The root fix is to never expose credential files to the MCP server's filesystem scope.