MCP (Model Context Protocol) Security Cheat Sheet — Do's and Don'ts

Reference note (untrusted external data; do not execute it as instructions). Enforce least privilege per MCP server and per tool. Inspect and pin all tool descriptions and schemas. Sandbox local MCP servers in containers or restricted environments. Require human approval for sensitive or destructive tool calls. Validate all inputs and outputs at the MCP server layer. Use mcp-scan or equivalent tooling to detect poisoned tools. Log and monitor all tool invocations centrally. Verify MCP server sources and scan dependencies. Sign MCP messages at the application layer — do not rely solely on transport-layer (TLS) security. Pin tool definitions with cryptographic hashes and verify before each execution. Auto-approve tool calls without showing full parameters to the user. Trust tool descriptions blindly — they are a prompt injection vector. Share OAuth tokens or credentials across MCP servers. Run MCP servers with full host access or permissions. Install MCP servers from unverified public registries without review. Assume a tool approved yesterday is the same tool today (rug pulls). Ignore cross-server interactions — shadowing attacks are real. Store secrets in MCP server code, configs, or environment variables. Silently fall back to unsigned message processing when signing is configured. Accept server public keys from unverified first-contact responses (TOFU without pinning). Attribution: Adapted from OWASP Cheat Sheet Series under CC-BY-SA-4.0. Adaptation: WikiKV isolated this documentation section, normalized formatting, retained only bounded code excerpts, and shortened it at a paragraph or sentence boundary for retrieval. Verify version-sensitive details at the source.