Fifteen Versions of Trust
The postmark-mcp package appeared on npm as a Model Context Protocol server for sending transactional emails through Postmark's API. It did exactly what it advertised. Version 1.0.1 through 1.0.15 were clean, functional, and unremarkable. Developers integrated it into their AI agent workflows. Claude Code, Cursor, and custom LLM pipelines used it to send confirmation emails, password resets, invoice notifications, and internal alerts. Fifteen versions of legitimate behavior established a trust history that no automated scanner would flag.
Then version 1.0.16 shipped. Snyk's security research team identified the change: the package now silently appended a BCC recipient to every email sent through it. Every transactional email — every password reset, every invoice, every authentication token delivered by email — was copied to an attacker-controlled inbox. The modification was minimal. The package's external behavior was unchanged. No errors, no latency increase, no visible indication that anything was different.
The BCC Mechanism
BCC exfiltration is a particularly effective technique because it is invisible to both the sender and the recipient. The email arrives normally. The sender's logs show a successful delivery. The recipient sees nothing unusual. The only evidence exists in the SMTP transaction itself — a BCC header that most email infrastructure strips from the delivered message. Unless an organization is actively monitoring outbound SMTP headers at the transport layer, the exfiltration is undetectable through normal email workflows.
The content of transactional emails makes this especially damaging. These are not marketing newsletters. Transactional emails carry password reset links, two-factor authentication codes, invoice details with payment information, customer PII, API keys, and session tokens. A single week of intercepting a mid-size company's transactional email flow can yield credentials for internal systems, financial data sufficient for fraud, and customer information that triggers breach notification requirements under GDPR, CCPA, and sector-specific regulations.
Why MCP Makes This Different
Supply chain attacks on npm packages are not new. What makes postmark-mcp significant is that it targets the Model Context Protocol layer — the infrastructure that connects AI agents to external services. MCP servers are not ordinary dependencies. They operate with elevated trust because they execute actions on behalf of AI agents: sending emails, querying databases, accessing file systems, calling APIs. A compromised MCP server does not just inject malicious code into an application build. It corrupts the action layer of an autonomous system.
The trust model of MCP is built on the assumption that servers are vetted and legitimate. There is no built-in attestation, no cryptographic verification of server behavior across versions, no behavioral sandbox that constrains what an MCP server can do compared to what it claims to do. When a developer installs an MCP server, they grant it the full scope of its declared capabilities. If that server sends emails, it sends emails — and the protocol has no mechanism to verify that it is sending only the emails the agent requested, with only the recipients the agent specified.
The Long-Game Supply Chain Pattern
The fifteen clean versions are the detail that matters. This is not an opportunistic attack — it is a patient, deliberate operation designed to pass every automated security check. npm audit scans the package on install and finds no known vulnerabilities. Snyk and Socket scan the dependency tree and see a package with a clean history. Even manual code review of earlier versions would show nothing suspicious. The attacker invested months of development effort to establish legitimacy before deploying a single, surgical modification.
This pattern — long-game trust establishment followed by a minimal payload — is structurally harder to detect than the typosquatting and dependency confusion attacks that dominate supply chain security discussions. Typosquatting relies on developer error. Dependency confusion exploits package resolution logic. Both can be mitigated with tooling. A legitimate package maintained by a seemingly credible author that introduces a subtle behavioral change after fifteen versions requires a different class of defense entirely: continuous behavioral monitoring of what packages actually do in production, not just what their code looks like at install time.
The Agentic Web's Protocol Layer Is Now a Target
WebPulse tracks the shift from human-browsed web to agent-navigated web. AI agents are becoming the primary interface layer — browsing, transacting, and operating on behalf of users and organizations. MCP is the protocol that connects these agents to the services they act upon. The postmark-mcp incident establishes that this protocol layer is now an active target for supply chain attacks. The agents are the new browsers. MCP is their HTTP. And the first confirmed man-in-the-middle attack on that protocol has already happened.
Organizations integrating MCP servers into AI agent workflows should treat every MCP server as a privileged dependency — equivalent to a production service account, not a development library. Pin exact versions. Monitor outbound network behavior. Audit the gap between declared MCP capabilities and actual runtime behavior. The cost of trust in the agentic web is now measured in stolen corporate emails, exfiltrated credentials, and breach notification obligations that no one budgeted for.
