The Koi Security team recently uncovered the first known, malicious MCP server in the wild: a package called postmark-mcp, downloaded over 1,500 times per week, that silently BCCs every outgoing email to an attacker-controlled domain.
So, what happened? High-level, a lot:
- The attacker cloned the legitimate Postmark MCP repository, made one small but nefarious change (a BCC insertion), and published it under the same name.
- For 15 versions, the package behaved as expected and developers integrated it into their workflows trusting it to do what it promised.
- With version 1.0.16 onward, it began copying every email, but also included password resets, financial notices, internal memos to “giftshop.club”, a domain under attacker control.
- Because MCP servers are used by AI assistants with broad permissions, this kind of backdoor bypasses typical security controls. These tools don’t show up in asset inventories, vendor risk assessments, or standard email gating, which can be a serious red flag for security specialists, but relatively an unknown risk to AI developers.
- When the author of the Postmark MCP repository was confronted, they deleted the malicious package from npm, but that does not remove instances already in use, so the threat persists.
The key takeaway? AI development must up-skill to recommended security practices or risk mistakes like handing over “god-mode” privileges without verifying who is behind the tools or how they might evolve over time.
Why MCP & AI Makes Security Even Harder
The addition of MCP servers (or “model-coupling” modules) to AI systems expands risk, not just functionality. What are the main contributors to that risk?
- Wildcard trust with sensitive power
MCPs often get access to email systems, databases, APIs, file systems, which is everything an AI agent might need to “do its job.” Once trusted, the AI uses them repeatedly without prompting. A malicious change deep inside an MCP can become catastrophic.
- Invisible attack surface
Because MCPs may not appear in traditional security tools (asset inventories, software bills-of-materials, etc.), they can evade scrutiny and sneak in under the radar.
- Supply chain attack vectors escalate
The postmark-mcp backdoor is a textbook supply-chain compromise. It involves an attacker, who piggybacks off a trusted name, slips in one line of code, and exploits existing trust. When AI + developer ecosystems freely adopt modules from open registries, those attacks become far more potent.
- Delayed detection & high impact
By the time a backdoor is identified, damage may already be done, including hundreds or thousands of emails exfiltrated, credentials exposed, internal operations and even data compromised.
- Compromised automation
AI assistants, once empowered, do not (by default) question or validate their tools. So, the “automation arrow” helps the attack by making the malicious module invisible in everyday operations.
What’s Involved in Security Principles for AI & Data
That risk doesn’t mean we should avoid AI or MCP modules altogether. Rather, we must treat them with much higher scrutiny, especially when they touch sensitive data in our databases. Here are guiding principles for a safer future:
1. Zero Trust for MCP / AI modules
- Treat every MCP as a potential threat until proven otherwise.
- Impose least privilege: only grant the minimal permissions necessary (for email in, email out, etc.).
- Use process isolation, sandboxing, or microservice wrappers so that if a module misbehaves, the blast radius is contained.
2. Layered visibility & auditing
- Log every action (i.e. email sends, database queries, file operations) with metadata on which module and version invoked it.
- Monitor for anomalies (sudden spikes in outbound volume, unexpected BCC recipients, strange API endpoints).
- Regularly reconcile module inventories (i.e. which MCPs are installed and invoked) with your software asset management.
3. Continuous risk/behavioral gating
- Introduce a “risk filter” or “behavior engine” that watches for unexpected behavior changes in MCP modules (i.e. new headers, external calls) and blocks or quarantines suspect updates.
- For each new release or update, require human review for modules that touch sensitive operations (email, database, file I/O).
4. Vendor & identity validation
- Don’t assume module trust based solely on registry name or popularity.
- Maintain a whitelist of trusted authors or cryptographically verify module provenance and signature.
- Use dual-signature schemes when possible (i.e. author with security reviewer).
5. Credential hygiene & response readiness
- Rotate credentials frequently, especially those passing through email channels or automations.
- Have incident response playbooks ready: how to detect BCC backdoors, revoke access, audit logs, and remediate.
- When you discover a compromised module, assume your environment has already been breached and act accordingly (forensic analysis, validation, etc.).
Why Human Oversight Becomes Even More Critical With MCP
In a world with AI & MCP modules doing many of the low-level tasks, the value of human experts increases. How can we accomplish this?
- Contextual judgment: A human can evaluate whether an AI recommendation or module behavior aligns with business logic, compliance constraints, or risk tolerance.
- Security intuition: Recognizing suspicious behavior or design patterns that no AI (today) fully grasps.
- Governance oversight: Ensuring that module adoption, updates, and permissions adhere to enterprise policy.
- Incident recovery leadership: In the event of a breach, skilled professionals are essential to triage, audit, and rebuild trust.
Thus, rather than becoming obsolete, data security professionals may see their role elevated, even prioritized for oversight, review, and governance of AI ecosystems.
Now Your Turn
The postmark-mcp backdoor is more than just an isolated incident; it’s a warning. As AI systems increasingly integrate peripheral modules to act on our behalf, we’re creating brand-new high-stakes attack surfaces.
If your organization is exploring AI assistants or MCP tools:
- Audit every module you adopt (current or future).
- Enforce strong security controls, least privilege, and continuous monitoring.
- Incorporate human-in-the-loop validation, especially for sensitive domains.
- Elevate and empower your data security leaders to own and review these systems.
Because if we don’t build AI ecosystems that respect security boundaries and human oversight, we risk letting automation turn against us and as data professionals, we should be the first ones to know this is a risk we can’t afford.