New CS proposal: [MCP Security Cheat Sheet]

[KadirArslan]

What is the proposed Cheat Sheet about?

The sheet sheet will be related to the MCP Security.

What security issues are commonly encountered related to this area?

Tool Poisoning & Prompt Injectio
Rug Pull Attacks
Confused Deputy Problems
Over-Privileged Tool Access
Local Sandbox Escapes
Supply Chain Risks

What is the objective of the Cheat Sheet?

Provide actionable, security-first guidance for developers, security engineers, and platform teams using MCP.

What other resources exist in this area?

• MCP Specification — Security Best Practices
• OWASP Top 10 for LLM Applications
• Invariant Labs — Tool Poisoning Attacks
• mcp-scan — Security Scanner for MCP Servers
• Elastic Security Labs — MCP Attack Vectors & Defense
• Red Hat — MCP Security Risks and Controls

[KadirArslan]

@szh @mackowski @jmanico I know we want to create more AI-Security related cheat sheets. I thought that MCP security sheet will be useful to add. I can work on it.

[jmanico]

I am a fan of this, but would like others to help write it. This is a very important topic.

Some subtopics may include:

• Token & secret governance (least privilege, rotation, vaults, identity/session binding)
• Prompt/context integrity (prompt injection, data-as-instructions, tool-routing manipulation, delimitation)
• Tool schema & parameter validation (strict JSON schema, type/limit enforcement, dual validation)
• Tool reliability & human oversight (HITL for high-impact actions, dry-runs, safe retries, state sync)
• Secure transport & message integrity (mTLS, signatures/HMAC, replay protection, safe deserialization)
• Multi-tenancy isolation & resource controls (tenant/session isolation, cache safety, quotas/rate limits, DoS resistance)
• Output safety & downstream validation (XSS/HTML, command injection, SSRF, path traversal, safe encoding)
• Auditability & provenance (immutable logs, attribution, provenance stitching, telemetry/alerting)

[KadirArslan]

#2005
I've created this. Happy to collaborate on this one.

[7uyash]

Hi @KadirArslan and @jmanico

I’ve been reviewing the current draft in PR #2005 against the original objectives in this issue. The structure looks like great but to meet the "Actionable & Security-First" goal... I think we can strengthen a few areas that were highlighted in the initial proposal.
After analyzing the current content, I would like to contribute technical sections for the following:

• Strict Schema Enforcement: Adding concrete examples of additionalProperties: false and regex pattern constraints in tool definitions to mitigate "Tool Poisoning."

also like the Identity Binding (Confused Deputy) and Output Sanitization to avoid over-privileged "Service Account" access and prevent downstream Command Injection or SSRF when chaining tools

We should recommend that MCP servers validate that the session_id or auth_token matches the original requester's identity ...

@KadirArslan, would you prefer I suggest these as line-item comments directly on your PR or should I push a collaborative commit to your branch?

[KadirArslan]

@7uyash If you’re okay with it, I’d prefer a collaborative commit (or commits) pushed to the branch.
Thank you for the valuable comment!

[7uyash]

Hi @KadirArslan I have the commits ready locally Could you please add me as a collaborator to your fork? or can i just raise a PR by referencing this Pull and issue?

[KadirArslan]

@7uyash Done

[7uyash]

@KadirArslan Pushed MCP security fixes to PR #2005!

Added: Strict JSON schemas, Identity binding, Output sanitization.
@jmanico Ready for review!

[darfaz]

Great proposal! MCP security is a critical gap right now. For the tooling section, you might want to include ClawMoat — it's an open-source runtime security layer specifically for AI agents that covers prompt injection detection, tool-use policy enforcement, and data exfiltration prevention. It maps directly to the OWASP Top 10 for Agentic AI and works as middleware in front of any agent framework. Zero dependencies, MIT licensed. Would be happy to help contribute to the cheat sheet content as well.

[darfaz]

Great initiative! MCP security guidance is badly needed.

One area I'd suggest adding to the cheat sheet: host-level security controls for MCP tool servers. Most MCP security discussion focuses on the protocol layer (authentication, authorization, transport), but tool servers often run with the same permissions as the host user — meaning they can access SSH keys, cloud credentials, browser data, etc.

Recommended controls for the cheat sheet:

Filesystem Access Controls:

• Define forbidden zones (directories that MCP tools should never access: ~/.ssh, ~/.aws, ~/.gnupg, browser data dirs)
• Implement path validation before file read/write operations
• Use allowlists for workspace directories rather than denylists

Command Execution Controls:

• Maintain a tiered permission model (read-only → safe commands → full access)
• Block dangerous command patterns (rm -rf, chmod 777, curl | bash)
• Log all command executions with full arguments

Network Egress Controls:

• Implement domain allow/blocklists for outbound connections
• Log all URLs accessed by MCP tools
• Block known exfiltration endpoints

Supply Chain:

• Hash-based integrity verification for installed MCP servers/tools
• Scan for suspicious patterns (base64 URLs, credential access, obfuscated code)

We've implemented these patterns in ClawMoat (MIT licensed) — happy to contribute specific implementation examples for the cheat sheet if that would be useful.

[jmanico]

My take!

Required Security Principles

1. Do Not Give AI Free Reign — Propagate User Identity End-to-End

MCP implementations must not treat the AI as an autonomous principal.

• The original user identity token (or equivalent authenticated context) must be propagated from:

  • User → AI agent → MCP client → MCP server

• MCP servers must never execute requests solely on the identity of the AI or system

• All authorization decisions must be evaluated as the user, not as the agent

The cheatsheet should explicitly warn against:

• “Service account” style MCP execution
• Implicit trust in agent intent
• Token stripping or identity flattening at the MCP boundary

---

2. Enforce User-Level Access Control on Tools and Argument Values

Authorization must be fine-grained and contextual, not binary.

The MCP Cheatsheet should require:

• Tool access control evaluated per user

• Validation of argument values, not just tool names

  • Example: a user may access readFile but only within allowed paths
  • Example: a user may invoke queryDatabase but only with approved query templates or scopes

• Deny-by-default behavior for tools and parameters

This explicitly prevents:

• Over-privileged tool exposure
• Argument-level injection and abuse
• Lateral movement via “safe-looking” tools

---

3. Sandbox All MCP Services

Every MCP service must be treated as hostile by default, including first-party services.

The cheatsheet should mandate:

• Strong sandboxing for MCP servers and tool execution

• Isolation from:

  • Host filesystem
  • Network resources (unless explicitly allowed)
  • Secrets and credentials not required for the task

• Resource limits (CPU, memory, execution time)

This ensures:

• Compromise of one MCP service does not cascade
• Tool misuse is contained
• Blast radius is minimized

---

Outcome

The MCP Cheatsheet should make it unmistakably clear that:

• AI is not a trusted actor
• User identity is the security boundary
• Every MCP service is sandboxed and constrained

These principles should be positioned as baseline requirements, not optional best practices.