MCP server security — scope, tool surface, and the prompt-injection routing problem

What it is

Model Context Protocol (MCP) is a specification for how LLM agents discover and call tools — file operations, HTTP requests, database queries, git commands, and arbitrary user-defined surfaces. An MCP server hosts a catalogue of tools; the agent reads the catalogue, decides which tools to call (often based on user input), and the server executes them. The server is authoritative on what tools exist and what scopes they have; the agent is the consumer.

Vulnerable example

// mcp-server.ts — WRONG
import { McpServer } from "@modelcontextprotocol/sdk";

const server = new McpServer({ name: "my-server" });

// Bug: tool with no scope check. Whatever path the LLM passes,
// the server reads it. A prompt-injection in the user's input
// can coerce the LLM into asking for /etc/passwd, ~/.ssh/id_rsa,
// or your project's .env file.
server.addTool({
  name: "read_file",
  inputSchema: { path: { type: "string" } },
  execute: async (input) => {
    return { content: await readFile(input.path) };
  },
});

Fixed example

// mcp-server.ts — RIGHT
import { McpServer } from "@modelcontextprotocol/sdk";
import path from "path";

const server = new McpServer({ name: "my-server" });

// Per the R6-T5 default-catalog pattern: every tool has an
// explicit allowed-scope. Reads are bounded to a workspace
// directory; writes are bounded by an allowlist of file types.
const WORKSPACE_ROOT = process.env.MCP_WORKSPACE_ROOT
  ?? "/var/mcp-workspace";

server.addTool({
  name: "read_file",
  inputSchema: { path: { type: "string" } },
  execute: async (input) => {
    // 1. Resolve the requested path against the workspace root
    //    using path.resolve, NOT string concatenation.
    const resolved = path.resolve(WORKSPACE_ROOT, input.path);

    // 2. Verify the resolved path is still under the workspace.
    //    If the LLM (or an attacker via prompt-injection) asked
    //    for "../../etc/passwd", the resolution would escape;
    //    this check rejects it.
    if (!resolved.startsWith(WORKSPACE_ROOT + path.sep)) {
      throw new Error("path outside workspace scope");
    }

    // 3. Verify file extension is in the allowlist (no binaries,
    //    no system files, no dotfiles).
    const ext = path.extname(resolved).toLowerCase();
    const ALLOWED = [".md", ".txt", ".json", ".yaml", ".yml"];
    if (!ALLOWED.includes(ext)) {
      throw new Error(`extension ${ext} not in scope allowlist`);
    }

    return { content: await readFile(resolved, "utf-8") };
  },
});

How Securie catches it

// mcp-server.ts — RIGHT
import { McpServer } from "@modelcontextprotocol/sdk";
import path from "path";

const server = new McpServer({ name: "my-server" });

// Per the R6-T5 default-catalog pattern: every tool has an
// explicit allowed-scope. Reads are bounded to a workspace
// directory; writes are bounded by an allowlist of file types.
const WORKSPACE_ROOT = process.env.MCP_WORKSPACE_ROOT
  ?? "/var/mcp-workspace";

server.addTool({
  name: "read_file",
  inputSchema: { path: { type: "string" } },
  execute: async (input) => {
    // 1. Resolve the requested path against the workspace root
    //    using path.resolve, NOT string concatenation.
    const resolved = path.resolve(WORKSPACE_ROOT, input.path);

    // 2. Verify the resolved path is still under the workspace.
    //    If the LLM (or an attacker via prompt-injection) asked
    //    for "../../etc/passwd", the resolution would escape;
    //    this check rejects it.
    if (!resolved.startsWith(WORKSPACE_ROOT + path.sep)) {
      throw new Error("path outside workspace scope");
    }

    // 3. Verify file extension is in the allowlist (no binaries,
    //    no system files, no dotfiles).
    const ext = path.extname(resolved).toLowerCase();
    const ALLOWED = [".md", ".txt", ".json", ".yaml", ".yml"];
    if (!ALLOWED.includes(ext)) {
      throw new Error(`extension ${ext} not in scope allowlist`);
    }

    return { content: await readFile(resolved, "utf-8") };
  },
});

Checklist

• Every MCP tool has an explicit allowed-scope (path prefix, allowlist, parameter constraints).
• Path inputs are resolved with `path.resolve` and verified to stay within an allowed root.
• Extension allowlists are positive (".md is allowed"), never negative (".exe is denied") — negative lists miss new extensions.
• Network tools have URL allowlists (no SSRF — internal IP ranges blocked at the tool level, not just at the network layer).
• Database tools use parameterized queries that the LLM cannot inject into.
• Tool inputs the LLM provides are validated against the inputSchema strictly — extra fields rejected.
• Tool failures fail-closed (return error, not silent fallback) so the agent's prompt-injection cannot succeed by retrying.
• Catalog is pinned by public key (TrustedCatalog) — new tools cannot be added at runtime by an attacker who compromises the upstream MCP server.

FAQ

Related guides