agentleFS
santosomarsantosomar/AI-agents-for-cybersecurity/.cursor/rules/codeguard-0-mcp-security.mdc

AI-agents-for-cybersecurity / rules

Cursor rule256 starsChanged 20 days agoBSD-3-ClauseView on GitHub

MCP (Model Context Protocol) Security based on CoSAI MCP Security guidelines

We split this codeguard-0-mcp-security.mdc into the rules it gives an agent

16 rules. About 0 are common, 15 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈15

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

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

    line 11
  2. Distinctive:

    Use SPIFFE/SPIRE for cryptographic workload identities

    line 14
  3. Distinctive:

    Use parameterized queries for database operations

    line 21
  4. Distinctive:

    Treat ALL inputs, tool schemas, metadata, prompts, and resource content as untrusted input

    line 24
  5. Distinctive:

    Use strict JSON schemas to maintain boundaries between instructions and data

    line 26
  6. Distinctive:

    Use TLS for ALL data in transit

    line 37
  7. Distinctive:

    Create single-purpose tools with explicit boundaries.

    line 59
  8. Distinctive:

    Do not rely on the LLM for validation or authorization decisions

    line 60
  9. Distinctive:

    Use two-stage commit for high-impact actions: draft/preview first, explicit commit with confirmation second

    line 61
  10. Distinctive:

    Use elicitation on MCP server side to request user confirmation of risky actions

    line 66
  11. Distinctive:

    Do NOT rely solely on human approval (users can become fatigued)

    line 68
  12. Distinctive:

    Use OpenTelemetry for end-to-end linkability of actions

    line 73
  13. Very specific:

    Use stdio transport to avoid DNS rebinding risks

    line 82
  14. Distinctive:

    Use sandboxing to limit privilege escalation attacks

    line 83
  15. Distinctive:

    Use secure credential storage (OS keychains, secret managers)

    line 88
  16. Distinctive:

    Prefer MCP servers hosted directly by service provider

    line 95

≈ “Common” is an estimate: at least 1 in 5 of the 6,350 Cursor rule files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
codeguard-0-mcp-security.mdc
---
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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.