codeguard-0-mcp-security · v1.5.0 · 2026-10-12 · sha256 61f64a5fc3f94a83

codeguard-0-mcp-security v1.5.0A

Immutable. This exact content never changes and is served at /api/v1/blob/61f64a5fc3f94a83.

---
description: MCP (Model Context Protocol) Security based on CoSAI MCP Security guidelines
globs: **/*.go,**/*.java,**/*.js,**/*.jsx,**/*.mjs,**/*.py,**/*.pyi,**/*.pyx,**/*.rs,**/*.ts,**/*.tsx
version: 1.5.0
---

rule_id: codeguard-0-mcp-security

# MCP (Model Context Protocol) Security Guidelines

NEVER deploy MCP servers or clients without implementing proper security controls.

### Workload Identity and Authentication
- Use SPIFFE/SPIRE for cryptographic workload identities
  - SPIFFE (Secure Production Identity Framework For Everyone) provides a standard for service identity
  - SPIRE (SPIFFE Runtime Environment) issues and rotates short-lived cryptographic identities (SVIDs)

### Input and Data Sanitization
- Validate ALL inputs using allowlists at every trust boundary
- Sanitize file paths through canonicalization
- Use parameterized queries for database operations
- Apply context-aware output encoding (SQL, shell, HTML)
- Sanitize tool outputs: return only minimum fields, redact all PII and sensitive data
- Treat ALL inputs, tool schemas, metadata, prompts, and resource content as untrusted input
- Deploy prompt injection detection systems
- Use strict JSON schemas to maintain boundaries between instructions and data

### Sandboxing and Isolation
- Design MCP servers to execute with least privilege
- MCP servers interacting with host environment (files, commands, network) MUST implement sandboxing controls
- LLM-generated code MUST NOT run with full user privileges
- Implement additional sandboxing layers: gVisor, Kata Containers, SELinux sandboxes

### Cryptographic Verification of Resources
- Provide cryptographic signatures and SBOMs for all server code
- Implement signature verification in your MCP client before loading servers
- Use TLS for ALL data in transit
- Implement remote attestation capabilities to verify servers are running expected code

### Transport Layer Security

#### stdio Transport (Local Servers)
- STRONGLY RECOMMENDED for local MCP to eliminate DNS rebinding risks
- Direct pipe-based stream communication
- Implement sandbox to prevent privilege escalation

#### HTTP Streaming Transport (Remote Servers)
Required security controls to implement:
- Payload Limits (prevent large payload and recursive payload DoS)
- Rate limiting for tool calls and transport requests
- Client-Server Authentication/Authorization
- Mutual TLS Authentication
- TLS Encryption
- CORS Protection
- CSRF Protection
- Integrity Checks (prevent replay, spoofing, poisoned responses)

### Secure Tool and UX Design
- Create single-purpose tools with explicit boundaries; avoid "do anything" tools
- Do not rely on the LLM for validation or authorization decisions
- Use two-stage commit for high-impact actions: draft/preview first, explicit commit with confirmation second
- Provide rollback/undo paths (draft IDs, snapshots, reversible actions) and time-bound commits when possible

### Human-in-the-Loop
- Implement confirmation prompts for risky operations in your MCP server
- Use elicitation on MCP server side to request user confirmation of risky actions
- Security-relevant messages MUST clearly indicate implications
- Do NOT rely solely on human approval (users can become fatigued)

### Logging and Observability
- Implement logging in your MCP servers and clients
- Log: tools that were used, parameters, originating prompt
- Use OpenTelemetry for end-to-end linkability of actions
- Maintain immutable records of actions and authorizations

---

## Deployment Pattern Security

### All-Local (stdio or http)
- Security depends entirely on host system posture
- Use `stdio` transport to avoid DNS rebinding risks
- Use sandboxing to limit privilege escalation attacks
- Appropriate for development and personal use

### Single-Tenant Remote (http)
- Authentication between client and server is REQUIRED
- Use secure credential storage (OS keychains, secret managers)
- Communication MUST be authenticated and encrypted
- Enterprise clients should enforce authenticated server discovery with explicit allowlists

### Multi-Tenant Remote (http)
- Require robust tenant isolation, identity, and access control
- Implement strong multi-tenancy controls (per-tenant encryption, role-based access control)
- Prefer MCP servers hosted directly by service provider
- Provide remote attestation when possible