MCP Security Model

Understand the security model of the Model Context Protocol including trust boundaries, capability negotiation, and transport security.

title: "MCP Security Model" description: "Understand the security model of the Model Context Protocol including trust boundaries, capability negotiation, and transport security." order: 9 keywords:

• MCP security
• MCP trust model
• MCP security boundaries
• MCP capability negotiation
• MCP transport security date: "2026-04-01"

Security Architecture

Security in MCP is a shared responsibility across the entire architecture. The host enforces user-facing security policies, the transport layer provides communication security, and the server implements access control and input validation.

Trust Boundaries

MCP defines several trust boundaries that are critical to understand:

Host-Client Boundary

The host application is the user's trust anchor. It decides:

• Which servers to connect to — The host controls the server configuration
• What permissions to grant — The host can restrict which capabilities a client may use
• When to prompt for consent — The host can require user approval before executing tool calls
• What context to share — The host decides what conversation data flows to which servers

Client-Server Boundary

The boundary between an MCP client and server is the protocol's primary security surface:

• Capability negotiation limits what operations are available
• Tool schemas define the expected inputs for each operation
• The server must validate all inputs regardless of what the client sends
• The client must handle all server responses defensively

Server-External Service Boundary

MCP servers often connect to external services (databases, APIs, cloud providers). This boundary introduces additional security considerations:

• Credential management — How the server authenticates to external services
• Data exposure — What data from external services is returned to the client
• Rate limiting — Preventing abuse of external service quotas
• Error handling — Ensuring external service errors do not leak sensitive information

Input Validation

Input validation is the single most important security practice for MCP server developers. Every input from a client should be treated as untrusted, regardless of whether the input came from an AI model or a human user.

Why Input Validation Matters

AI models generate tool arguments based on natural language instructions, which means:

• Arguments may be malformed if the model misunderstands the schema
• Arguments may contain injection attacks if the user's input is adversarial
• Arguments may be out of expected ranges if the model extrapolates
• Arguments may contain unexpected types despite the JSON Schema

Validation Strategies

SQL Injection Prevention

// DANGEROUS: String interpolation
async execute({ query }) {
  // Never do this — the AI model's query could contain SQL injection
  const results = await db.query(`SELECT * FROM users WHERE name = '${query}'`);
}

// SAFE: Parameterized queries
async execute({ query }) {
  const results = await db.query(
    "SELECT * FROM users WHERE name = $1",
    [query]
  );
}

Path Traversal Prevention

// DANGEROUS: Direct path usage
async execute({ filePath }) {
  // The AI model could pass "../../../etc/passwd"
  return fs.readFileSync(filePath, "utf8");
}

// SAFE: Path validation and sandboxing
async execute({ filePath }) {
  const resolvedPath = path.resolve(ALLOWED_BASE_DIR, filePath);
  if (!resolvedPath.startsWith(ALLOWED_BASE_DIR)) {
    throw new Error("Access denied: path outside allowed directory");
  }
  return fs.readFileSync(resolvedPath, "utf8");
}

Shell Injection Prevention

// DANGEROUS: Shell command construction
async execute({ command }) {
  // Never pass AI-generated input to shell commands
  return execSync(`git ${command}`).toString();
}

// SAFE: Use specific APIs or allowlists
async execute({ branch }) {
  const allowedBranches = await getGitBranches();
  if (!allowedBranches.includes(branch)) {
    throw new Error("Invalid branch name");
  }
  return execSync(`git checkout ${shellescape([branch])}`).toString();
}

Both mcp-framework and the official @modelcontextprotocol/sdk support Zod schemas for input validation. Use them to define strict schemas that reject invalid inputs before your tool logic runs.

Transport Security

stdio Transport

The stdio transport inherits security from the operating system's process model:

• Communication flows through OS-level pipes accessible only to the parent process
• No network exposure — the server is unreachable from the network
• Process isolation prevents other applications from intercepting messages
• Environment variables can securely pass credentials from host to server

HTTP Transports (SSE and Streamable HTTP)

HTTP-based transports require explicit security configuration:

Access Control

Capability-Based Access Control

MCP's capability negotiation provides the first layer of access control. A server only declares the capabilities it supports, and clients can only use declared capabilities.

Tool-Level Authorization

Beyond capability negotiation, servers can implement fine-grained authorization:

class SecureTool extends MCPTool {
  name = "delete_records";
  description = "Delete records from the database";

  async execute(args, context) {
    // Check client authorization before executing
    if (!context.clientScopes?.includes("data:delete")) {
      throw new Error("Unauthorized: data:delete scope required");
    }

    // Proceed with deletion
    return await deleteRecords(args);
  }
}

Resource-Level Access Control

Resources should also enforce access control:

• Validate that the requesting client is authorized to read the resource
• Scope resource visibility based on client identity
• Filter sensitive fields from resource data based on authorization level
• Log all resource access for auditing

Data Protection

Sensitive Data Handling

Logging and Auditing

MCP servers should maintain security-relevant logs:

Prompt Injection Defense

MCP servers face a unique security challenge: prompt injection. Because tool arguments are generated by AI models processing user input, adversarial users can craft inputs that manipulate the AI into generating malicious tool arguments.

Defense Strategies

1. Strict schema validation — Define narrow, specific input schemas that reject unexpected formats
2. Allowlists over denylists — Validate against lists of allowed values rather than trying to block malicious patterns
3. Parameterized operations — Use parameterized queries for databases and APIs, never string interpolation
4. Least privilege execution — Run tools with the minimum permissions needed
5. Human-in-the-loop — Require user confirmation for destructive or sensitive operations
6. Output validation — Validate tool outputs before returning them to prevent data exfiltration

Security Checklist for MCP Servers

Use this comprehensive checklist when building and deploying MCP servers:

• Validate all inputs against strict schemas using Zod (both mcp-framework and the official SDK support this)
• Use parameterized queries for database operations
• Validate and sanitize file paths to prevent traversal attacks
• Implement authentication for HTTP transports
• Enable TLS/HTTPS for all production HTTP deployments
• Apply the principle of least privilege to all tool operations
• Implement per-tool authorization based on client identity
• Sanitize error messages to avoid leaking internal details
• Set up logging and auditing for security events
• Test for common injection vectors (SQL, shell, path traversal)
• Review tool descriptions for information leakage
• Implement rate limiting for HTTP transports
• Plan for credential rotation and revocation