The Model Context Protocol (MCP) is the open standard Anthropic released on November 25, 2024, to let AI models like Claude call external tools, read files, and query APIs through a single, standardized interface instead of one-off integrations. Within eight months, thousands of public MCP servers appeared on registries like Smithery and mcp.so, connecting LLMs to GitHub, Slack, databases, and internal codebases. MCP security is the discipline of securing that connection layer: the servers, the tool descriptions passed to the model, the credentials MCP servers hold, and the trust boundary between an AI agent and the systems it can now act on. Because MCP grants models the ability to execute code, read private data, and chain actions autonomously, a single malicious or vulnerable server can turn a coding assistant into a remote-access tool. Three critical CVEs disclosed between April and July 2025 already prove this isn't theoretical.
What is the Model Context Protocol, and why does it need its own security model?
MCP needs its own security model because it collapses the line between "data the model reads" and "instructions the model follows," something traditional API security was never designed to handle. A REST API call returns data; an MCP tool call can return data that also contains natural-language instructions, and the model has no reliable way to tell the two apart. When Claude, Cursor, or Windsurf calls an MCP server, the server's tool descriptions, error messages, and even file contents are injected directly into the model's context window as if they were trusted developer input. Anthropic's own MCP specification (rev. 2025-06-18) added OAuth 2.1 authorization flows specifically because the original March 2025 spec left server-to-client trust largely unaddressed. Traditional AppSec tooling — SAST, DAST, dependency scanning — checks code paths and known CVEs; it doesn't model what happens when an LLM autonomously decides to call a "read_email" tool after parsing a poisoned calendar invite.
What are the most common MCP attack vectors?
The most common MCP attack vectors are tool poisoning, rug pulls, and cross-server shadowing, all identified and named by Invariant Labs in April 2025. In a tool poisoning attack, a malicious MCP server embeds hidden instructions inside a tool's description field — invisible to the human reviewing the tool list, but fully visible to the model — telling it to, for example, exfiltrate SSH keys or forward emails to an attacker-controlled address while performing an innocuous-looking task like "format this document." A rug pull is a supply-chain variant: a server passes review with benign tool definitions, then silently changes those definitions after installation, since MCP has no built-in integrity verification for tool schemas between calls. Cross-server shadowing occurs when one compromised MCP server injects instructions that alter how a client interacts with a second, legitimate MCP server in the same session — Invariant demonstrated this by having a malicious server override how an agent handled WhatsApp message-sending tools from an unrelated trusted server.
What real-world MCP vulnerabilities have already been disclosed?
Real-world MCP vulnerabilities disclosed in 2025 include two critical-severity CVEs and at least two vendor-specific data exposure incidents. CVE-2025-49596, disclosed by Oligo Security on June 4, 2025, is a critical (CVSS 9.4) remote code execution flaw in the official MCP Inspector developer tool: its proxy server bound to 0.0.0.0 without authentication by default, letting any malicious website the developer visited issue a DNS-rebinding attack and execute arbitrary code on the developer's machine. CVE-2025-6514, disclosed by JFrog researchers on July 9, 2025 and carrying a CVSS score of 9.6, is an OS command injection vulnerability in the widely used mcp-remote proxy package (downloaded over 437,000 times) — connecting to a malicious or compromised MCP server could trigger arbitrary command execution on the client host, no user interaction beyond the initial connection required. Separately, in May 2025 Invariant Labs showed that GitHub's official MCP server could be manipulated via a poisoned public issue to leak private repository contents into a public one, and in June 2025 Asana disclosed a bug in its MCP server that exposed customer data across unrelated tenant workspaces for roughly three weeks before it was patched.
How does MCP security differ from traditional API security?
MCP security differs from traditional API security because the "caller" is a non-deterministic model, not a fixed client you control. With a REST or GraphQL API, you can enumerate every possible request shape, rate-limit by endpoint, and validate input against a strict schema, because a human wrote the calling code. With MCP, the calling logic is generated at inference time: the model decides which tools to invoke, in what order, and with what arguments, based on natural-language context that can include attacker-supplied text buried in a document, email, or ticket the agent was asked to summarize. That means the attack surface isn't just the MCP server's code — it's every piece of untrusted content the agent might ever read during a session, since any of it can function as an indirect prompt injection. Traditional API security also assumes credentials map to a known service account with fixed scope; many early MCP integrations instead hand agents long-lived OAuth tokens or API keys with broad, unaudited permissions because the protocol's authorization spec wasn't finalized until mid-2025.
What does an MCP security checklist look like for security teams?
An MCP security checklist for 2025-2026 starts with inventory: security teams cannot secure MCP servers they don't know are running, and shadow MCP adoption inside engineering and product teams is already common since any developer can npm install a server in minutes. Beyond inventory, five controls matter most: (1) pin MCP servers to a specific reviewed version and hash rather than "latest," to block rug-pull updates; (2) run MCP servers with least-privilege, short-lived credentials scoped to only the tools actually used, not the account's full API scope; (3) treat every tool description and tool response as untrusted input and sandbox or filter it before it reaches the model's context, the same way you'd treat user-uploaded content; (4) monitor egress from hosts running MCP clients, since data exfiltration from a poisoned tool call looks like normal outbound traffic without network-layer inspection; and (5) require SBOMs for MCP servers pulled from public registries, since a 2025 review of public MCP listings found dozens of servers with no maintainer verification, no changelog, and dependency trees several layers deep.
How Safeguard Helps
Safeguard extends existing supply chain security controls to the MCP layer instead of treating agentic AI as a separate, unmanaged category. Reachability analysis identifies whether a vulnerable dependency inside an MCP server — like the mcp-remote package affected by CVE-2025-6514 — is actually invoked by a code path your agents call, cutting through alert noise from theoretical CVEs that never execute. Safeguard's SBOM generation and ingest pipeline extends to MCP server packages and their transitive dependencies, giving security teams the same provenance visibility over agent tooling that they already have over application dependencies. Griffin AI continuously analyzes MCP server behavior and tool descriptions for the poisoning, rug-pull, and shadowing patterns Invariant Labs documented, flagging schema drift between installed and reviewed versions before it reaches production agents. When a fix is available, Safeguard opens an auto-fix pull request pinning the safe version or patched dependency, so remediation doesn't wait for a manual audit cycle.