An LLM can move money, delete production data, or trigger an industrial process with a single call. Unsurprisingly, adversaries rushed in:
Token replay: Stolen OAuth or session tokens let attackers spawn phantom MCP servers that operate invisibly under a victim’s scopes — BytePlus.
Tool-poisoning & rug-pulls: Approved manifests mutate post-consent to siphon WhatsApp chats or SSH keys — invariantlabs.ai.
Indirect prompt injection in transit: A stray e-mail emoji can detonate a cascade of uncontrolled API calls because the integration layer is literally language — Simon Willison's Blog.
Last year, Snyk, Lakera, and OWASP published the inaugural Large Language Model Security Verification Standard (LLMSVS).
Earlier this month, Snyk contributed an entirely new MCP section to address this new attack surface with 17 testable requirements that slot directly into existing security assessments. Here are a few examples:
9.1 insists on mutual-TLS or DPoP-signed tokens so that every client-to-server hop proves both ends are genuine and binds any bearer token to the underlying connection, shutting down rogue MCP servers spun up with leaked OAuth tokens and foiling man-in-the-middle replays that invisible agents would otherwise miss.
9.4 allow-lists approved MCP servers and integrity-pins each manifest. Clients load tools only from explicitly trusted hosts and verify a hash before execution, blocking “cross-server shadowing” and post-consent rug-pulls where a malicious server silently swaps in a weaponised tool.
9.8 sets hard rate-limits and quotas per tool, capping call volume, cost, and output size at the server, so runaway loops (think infinite “summarise this URL” invocations) can’t trigger denial-of-service storms or drain your budget.
The remaining 14 controls layer on least-privilege OAuth scopes, secrets-manager storage, schema validation, sandboxed runtimes, SBOM-driven patch SLAs, drift detection, signed updates, anomaly-detection feeds, and a transparency UI that surfaces every invocation, turning MCP’s free-for-all into a managed, monitored, and measurable interface.
Every control is phrased as a verifiable requirement that teams can map straight into threat modeling sessions without starting from a blank canvas. Assets (OAuth tokens, tool manifests), entry points (`tools/list, tools/call`, streaming channels), and trust boundaries are already implied, so engineers and architects can trace abuse paths like token replay or tool poisoning in minutes rather than days. The result is a living threat model that evolves with the protocol, highlights residual risk early in the design phase, and shortens review cycles for every new tool integration. Snyk’s security engineers use this approach internally, and this same playbook is now public: apply Section 9 to your data-flow diagrams, annotate the controls that matter most, and turn MCP adoption into a repeatable, defensible risk-management exercise.
You can check out the full set of MCP Security controls here.
