⚡ Quick Summary
This OWASP guide targets organizations that consume (not build) third-party MCP servers—software that exposes tools, resources, and prompts to LLM hosts/agents. It frames MCP as a powerful but risky extension surface: tools can read files, call APIs, and execute code, so compromise can mean data theft or system sabotage. The cheat sheet lays out concrete controls across four fronts: (1) the emerging attack landscape (tool poisoning/rug pulls, prompt injection, memory poisoning, and cross-server tool interference), (2) client hardening and safe server discovery/verification, (3) correct use of OAuth 2.1/OIDC and least-privilege authorization, and (4) tooling, sandboxing, and governance with an internal “trusted MCP registry.” Think of it as an actionable minimum standard for letting agents touch real systems—pin versions, verify sources, sandbox by default, gate dangerous actions with human-in-the-loop, and continuously monitor.
🧩 What’s Covered
The guide opens by clarifying scope: it’s for companies and developers using third-party MCP servers and explains MCP’s host–client–server model and three primitives (tools, resources, prompts). The risk framing is crisp: connecting models to databases, filesystems, and SaaS APIs unlocks automation while expanding the attack surface (client/server over JSON-RPC + transports like STDIO or Streamable HTTP). It stresses the consequences: malicious code execution, unauthorized access, and exfiltration if the stack is compromised (pp. 4–5).
It then maps common attacks with step-by-step mitigations.
• Tool poisoning & rug pulls: hide instructions in tool descriptions/params or swap a trusted tool with a malicious one. Defenses include full tool transparency in the UI (no shortened manifests), description/code review, version pinning and hashing, and runtime least-privilege egress controls (p. 6–7).
• Prompt injection: sanitize untrusted data and responses before model use, enforce schemas (JSON/YAML) for tool inputs, and segment contexts/sessions for distinct operations (p. 7).
• Memory poisoning: validate every write to agent memory, require source attribution, hash content, apply TTLs, and isolate memory by session/user (p. 7).
• Tool interference: when multiple servers are available, outputs from one can trigger others. Use human-in-the-loop tiers, isolate execution context, and set execution timeouts (p. 7).
Next, it details client security & server discovery. Client guidance includes: trust minimization; strict allowlists and schemas; containerized/sandboxed execution; JIT, narrowly scoped permissions; UI transparency of permissions; local data protection; and anomaly detection for tool calls (p. 8). Discovery/verification calls for “registry-only” discovery, origin verification, IP allowlists, and choosing the right connection mode: STDIO for local sub-process servers hardened with seccomp/AppArmor, vs Streamable HTTP for remote servers with TLS/mTLS or OAuth 2.1 plus WAF and rate-limiting; rotate credentials. Verification requires version pinning, staged rollouts with telemetry, and recorded human approvals with drift monitoring (pp. 9–10).
The authentication & authorization section standardizes identities: client credentials for system ops; OIDC + PKCE for user-bound ops; narrowly scoped, short-lived tokens where OAuth is unavailable. For dynamic client registration (generally discouraged), it outlines protections (access tokens, signed software statements, signed bodies). Authorization design emphasizes least-permission scopes, granular per-action permissions, and human-in-the-loop for first-time or sensitive actions (pp. 10–11).
A tools & utilities catalog lists scanners (e.g., MCP-Scan, Semgrep rules, mcp-watch, mcp-context-protector), moderation/guardrails (LangKit, OpenAI Moderation, Invariant, LlamaFirewall), OSS hygiene (OpenSSF Scorecard, Snyk package health), and sandboxing (Docker) (p. 11). The governance chapter introduces a practical workflow anchored in a trusted MCP registry: submission, automated scanning, dual-sign-off by security + domain owners, staged deployment with monitoring, and periodic re-validation; with clear role definitions (pp. 12–13). The Use Cases diagram (p. 5) contrasts a local, containerized server using STDIO against a remote, HTTP-connected server interacting with cloud APIs—clarifying where auth, discovery, and change-management risks concentrate.
💡 Why it matters?
Agentic systems become truly useful only when models can act. MCP is fast becoming the de-facto way to wire LLMs to tools and data. This guide gives security teams a ready-to-apply baseline: put untrusted servers in containers, gate unknown tools with human approval, pin and hash versions, prefer registry-based discovery, and use OAuth/OIDC properly. Done well, teams unlock automation while containing blast radius—and they accumulate audit evidence through a registry-centric workflow. In short: fewer surprises, safer velocity, and governance that scales with the number of servers and tools.
❓ What’s Missing
- Assurance depth: No prescriptive scoring to compare servers’ risk levels or maturity; readers must define their own thresholds.
- Runtime policy examples: Mentions least-privilege and network egress controls but lacks concrete policy-as-code snippets (e.g., AppArmor/OPA examples).
- Supply-chain playbooks: References verification and hashing; more detail on SBOMs, signature verification, and responding to upstream CVEs would help.
- Model-side controls: Points to prompt-injection resources; deeper coverage of model routing, tool-use guards, and function-calling constraints would round it out.
👥 Best For
- Security architects and platform teams enabling MCP inside enterprises.
- Agent/LLM product teams connecting to SaaS/internal APIs.
- Compliance/GRC leaders needing auditable control over which servers and tools agents may use.
- DevX teams designing safe UX for tool manifests and human-in-the-loop approvals.
📄 Source Details
- Title: A Practical Guide for Securely Using Third-Party MCP Servers
- Project: OWASP GenAI Security Project
- Version/Date: v1.0, October 23, 2025
- License: CC BY-SA 4.0
- Notable visuals: Use-case architecture diagram (p. 5) contrasting local/remote servers; governance workflow and role map (pp. 12–13).
📝 Thanks to
Acknowledged contributors span ServiceNow, HUMAN Security, IBM, Palo Alto Networks, OneTrust, Google, AWS, SAP, Affirm, Vijil, and more under the OWASP GenAI Security Project—reflecting broad, vendor-neutral input (pp. 13–15).
