In November 2024, Anthropic open-sourced a small specification called the Model Context Protocol, or MCP, built to solve a mundane problem: giving AI models a standard way to call tools, read files, and query APIs instead of requiring a custom integration for every data source. Eighteen months later, MCP security has become one of the most urgent conversations in enterprise AI, because the same protocol that lets an assistant read a calendar, query a production database, or open a pull request also hands it a direct line into your infrastructure. What started as roughly 700 public MCP servers in January 2025 has grown to more than 16,000 a year later, and each one is a potential entry point. This piece walks through what MCP actually does, why its design invites a new class of attacks, and what a realistic MCP threat model looks like for teams running it in production right now.
What Is the Model Context Protocol, and Why Does It Matter for Security?
MCP is an open standard, introduced by Anthropic in November 2024 and now backed by OpenAI, Google DeepMind, Microsoft, and most major AI vendors, that lets an AI model discover and invoke external tools through one standardized interface instead of a bespoke integration for every system. Under the hood, an MCP "host" (the AI application, such as an IDE or chat client) talks to one or more MCP "servers" over JSON-RPC, using either a local stdio transport or a remote HTTP/SSE connection. Each server advertises a set of tools, resources, and prompts — "read this file," "run this SQL query," "create a GitHub issue" — and the model decides at runtime which ones to call and with what arguments.
That design is exactly why MCP matters for security. Historically, every integration had its own bespoke, reviewed code path with its own access controls. MCP collapses dozens of those integrations into a single, generic calling convention, and it hands the decision of when to call a tool to the model itself, based on natural-language instructions embedded in the same context window as untrusted content. Anthropic shipped reference servers for Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer at launch specifically because the pattern generalizes so well — which is also why a flaw in the pattern generalizes just as well to every server built on top of it.
What Does the MCP Threat Model Look Like in Practice?
The MCP threat model centers on one structural fact: tool descriptions, file contents, API responses, and the user's actual instructions all arrive in the same context window, so the model has no reliable, built-in way to tell a legitimate command from an attacker's payload hidden inside a document, issue, or query result. Researcher Simon Willison documented this problem in April 2025, describing how MCP's architecture reopens the classic prompt injection problem at a much larger blast radius, because the "prompt" now includes whatever a Slack message, ticket, or webpage happens to contain.
From that fact, several concrete attack patterns follow. "Tool poisoning" hides malicious instructions inside a tool's own description field — text the model reads but a user rarely sees — telling the agent to, say, read a credentials file and pass its contents as a parameter to an unrelated function call. "Rug pull" attacks exploit the fact that a server can silently change its tool definitions after a user has already approved them, so a tool that looked safe on day one can be rewritten to exfiltrate data on day seven without any new consent prompt. "Tool shadowing" lets a malicious server redefine or intercept calls meant for a trusted one when multiple servers are connected at once. Layered on top is a straightforward confused-deputy problem: the agent typically runs with one broad credential (an API token, a database login, a filesystem mount) that it applies indiscriminately across every task, so a single compromised prompt can reach far beyond what any individual task should need.
How Wide Is the MCP Attack Surface Today?
It is wide, and it is growing fast: the ecosystem went from about 700 public MCP servers in January 2025 to more than 16,000 roughly a year later, spread across registries like the official MCP Registry, PulseMCP, Glama, and LobeHub, alongside thousands more packages published directly to npm and PyPI. A 2025 scan of 1,808 live MCP servers by security researchers at AgentSeal found security findings in 66% of them — the majority of a rapidly growing, largely unaudited software category.
The MCP attack surface isn't just "more servers," it's also more paths into each one. Local stdio servers run arbitrary code on a developer's machine with whatever permissions that process already has, often including cloud credentials, SSH keys, and browser cookies sitting nearby. Remote HTTP servers add classic web-app concerns — authentication, session handling, and the widely discussed OAuth "token passthrough" pattern that can leak upstream access tokens to a downstream server that was never supposed to see them. And because installing a new MCP server is often a one-line config change or a single npx command, it behaves a lot like installing an unreviewed npm package with shell access — a software supply chain risk that most teams don't yet treat with the same scrutiny they apply to actual dependencies.
What Model Context Protocol Vulnerabilities Have Already Been Exploited?
Real ones, and recent ones: the clearest example is the GitHub MCP server issue disclosed by Invariant Labs on May 26, 2025, affecting a server with roughly 14,000 GitHub stars. An attacker filed a malicious issue on a public repository containing hidden instructions; when a developer later asked their agent to review open issues, the agent followed the embedded instructions, pulled data out of the user's private repositories, and leaked it by opening a pull request back on the public one — no credential theft required, because the agent already had legitimate access to both. Researchers noted this wasn't a simple code bug GitHub could patch away; it's an architectural consequence of mixing untrusted content and privileged tool access in one context, which is precisely why it's a useful case study for the wider class of Model Context Protocol vulnerabilities rather than a one-off.
Other documented issues fall into predictable buckets: command and path injection in early filesystem and git MCP server implementations that trusted repository configuration files too readily; servers that request far broader OAuth scopes than any of their tools actually use; and registries with little to no code review before a server is listed and installed by developers searching for a quick integration. None of these require exotic techniques — they exploit the ordinary gap between what an MCP server can do and what a given task actually needs it to do.
Why Is MCP Security Different From Traditional API Security?
MCP security is different because the interface is natural language, not a fixed schema, so the input validation and allow-listing techniques that secure a traditional REST API don't fully transfer. A REST endpoint enforces a contract in code: specific fields, specific types, specific permitted values. An MCP tool call is authorized, in effect, by the model's judgment about what the user "meant," formed after reading a mix of trusted instructions and untrusted content it cannot reliably separate. That shifts a large share of the access-control decision from a reviewable code path into a probabilistic reasoning step, which is a fundamentally harder thing to test, log, and guarantee.
It's also different in scale and velocity. A typical enterprise vets and versions its APIs deliberately; MCP servers are frequently added by individual engineers experimenting with agent workflows, often outside any formal security review, and can be swapped or updated by a third party at any time. Treating MCP the way teams already treat open-source dependencies — with provenance checks, version pinning, and continuous scanning — is a more accurate mental model than treating it like an internal API.
How Safeguard Helps
Safeguard treats MCP servers as what they are: another node in your software supply chain, and one that now sits closer to your data and credentials than most dependencies ever have. We extend the same provenance and integrity controls we apply to packages and containers to MCP servers — verifying what code a server actually ships before it's approved for use, flagging unsigned or unpinned versions, and alerting when a previously approved server's tool definitions change, which catches rug-pull behavior before it reaches production rather than after.
On the runtime side, Safeguard maps the credentials and scopes each MCP server actually needs against what it's been granted, so a Slack or GitHub integration doesn't quietly end up holding filesystem or database access it never uses. We scan server source and dependencies for the injection, path-traversal, and secrets-handling issues that have already shown up in real incidents, and we give security teams a single inventory of every MCP server connected across their environment — because you can't defend an attack surface you can't see. Combined with policy enforcement at the point of tool invocation, that turns MCP from an unmanaged risk into a governed part of your AI infrastructure, without slowing down the teams building on it.