A malicious MCP server stealing emails looks, on the wire, like a working integration. In September 2025, researchers documented a counterfeit Postmark MCP package on npm that turned a seemingly legitimate integration into an email exfiltration channel. The malicious package used the email-sending workflow and its existing access to copy outbound messages to an attacker-controlled address.
The Model Context Protocol is becoming the common way enterprise agents reach email, code repositories, databases and ticketing systems. Each server an agent connects to is therefore a trust decision with consequences across the AI steering committee.
This article walks through how a malicious MCP server operates, why standard install-time approvals miss the attack, and the runtime controls that keep an agent program defensible when a trusted integration turns hostile.
Key Takeaways
- Treat every MCP server as a live supply-chain risk: the counterfeit Postmark npm package showed that trusted-looking agent integrations can covertly export email using permissions already granted.
- Expect attacks to hide inside normal agent behavior: poisoned descriptions, altered tool definitions, routine updates and valid credentials can steer models toward data theft without conspicuous network signals.
- Revalidate trust at runtime, not only at installation: discover agents and servers, enforce allow-lists and integrity checks, narrow credential scopes, inspect interactions before execution and preserve human-linked audit trails.
- Demand operational proof when selecting controls: industry guidance favors least privilege, approval checkpoints, centralized audit trails and description pinning, but scarce benchmarks make pilots and production results essential.
- Respond as though a breach may have occurred, not merely as a bad-package cleanup: remove installed code, inspect affected logs, rotate credentials, reduce permissions and prepare for applicable notification and recordkeeping obligations.
What is a malicious MCP server, and how does one steal emails?
A malicious MCP server is a Model Context Protocol server whose code, tool descriptions or outputs are built to make an AI agent act against its operator’s interests. In the protocol’s design, an MCP host such as Claude Desktop connects to one or more servers through dedicated clients. Each server provides the tools and context the model can use.
The exposure comes from what the server is allowed to write into that context. On connection, the client fetches each tool’s name, description and parameter schema, then places them in the model’s context, where the model uses them to understand available capabilities.
Malicious descriptions can exploit this process by embedding instructions that the model may incorrectly treat as authoritative. Because that text steers behavior directly, the MCP Top 10 ranks tool poisoning third, alongside prompt injection attacks via contextual payloads and shadow MCP servers running without approval.
The email-stealing case is the simplest form of that pattern. An actor created a counterfeit npm package under Postmark’s name, built trust across 15 clean versions, then slipped a backdoor into version 1.0.16. Postmark had never published its MCP server to npm, so its API and services were unaffected, but installations running the malicious version could expose outbound email content when the affected email-sending functionality was used, as Koi Security first documented.
From there, the mechanics were trivial. The backdoored version blind-copied each message an agent sent to an outside address. Since email carries password resets, two-factor codes and invoices, a single BCC line in a developer tool could amount to a corporate data breach.
Your Employees Use 5x More AI Tools Than You Think
WitnessAI scans your entire network to catalog every AI app, agent, and conversation. No endpoint clients or browser extensions are required.
See How Observe WorksHow attackers weaponize the Model Context Protocol
Attackers weaponize MCP by exploiting the protocol’s own design, not by breaking it, which is why some techniques rely primarily on malicious instructions or tool metadata, while others involve compromised server code, dependencies, or software updates. The fake Postmark npm package was crude, but the methods documented since then are quieter and harder to catch. In most cases, the agent itself does the damage with credentials and permissions the organization has already issued.
The attack surface researchers describe tends to cluster around a handful of recurring patterns: poisoned tool descriptions, puppet behaviors, rug pulls on previously approved tools, and malicious external resources pulled in at runtime. These techniques can appear in tool metadata, model context, tool responses, or executable server code. Different attack paths therefore require different detection and enforcement mechanisms. Three design properties do most of the work for attackers, and the sections below walk through each one.
1. Tool descriptions carry instructions the user never sees
Tool poisoning hides instructions inside a tool’s description so the model follows them while the user sees only a benign tool name. Descriptions can be presented to the model during tool discovery, potentially influencing later tool selection or execution even before the user explicitly invokes the affected tool. Depending on the client interface, users may not see the complete tool description or embedded instructions that influence the model.
That sidesteps the approval dialog meant to protect the user. A description can tell the model to exfiltrate the contents of a file whenever a specific tool is called, to prefer a certain server when more than one offers the same capability, or to attach hidden parameters to otherwise normal requests. In one published evaluation of 13 models, researchers reported high attack success rates under their test conditions, illustrating the potential impact of malicious tool metadata. In other words, the model is doing exactly what it was told; the problem is who got to do the telling.
2. One-time approval lets a trusted server turn hostile later
A rug pull changes a tool’s definition after the user has approved it. A catalogue of AI attack techniques notes that an agent may still call a definition “silently altered after initial approval”. That matters because some MCP hosts and configurations retain previously granted approvals, allowing changed tool behavior to go unnoticed unless integrity or authorization checks are repeated: the tool is on the allow-list, the schema is cached, and subsequent calls proceed without a fresh prompt.
The same catalogue adds: “Because agents don’t re-verify tool integrity, the malicious actions are executed under the radar”. The Postmark package applied the same logic to a software update: 15 clean versions earned the install, and the sixteenth collected the mail. The attack vector does not have to be a definition swap at runtime; a routine package update, a server-side change the client never notices, or a swapped dependency can all produce the same effect. The defender’s assumption, trust granted once stays accurate, is the weakness being exploited.
3. Agents act with the access the organization already granted
Tool poisoning can redirect authorized access across connected systems. A poisoned description redirects privilege the organization has already handed out. Tool poisoning “redirects existing authorized access rather than circumventing access controls”.
Without privilege escalation, it can reach email, repositories, databases, calendars and chat platforms. The attacker never needs to find a vulnerability in those systems; the agent is already authenticated.
The credentials behind that access often rely on pasted API keys and long-lived refresh tokens, both of which make rotation slow and scope reduction unlikely without a dedicated effort. Exfiltration can ride routine channels; security guidance warns that sensitive data can be encoded “into seemingly normal tool calls (e.g., search queries, email subjects)”. A BCC on outbound email achieves exactly that, and keyword- or regex-based controls may struggle because little in the traffic looks anomalous.
Several properties of a typical MCP session compound the detection problem:
- **Valid transport and payloads.**Remote MCP connections may use legitimate HTTPS and well-formed protocol messages, while local MCP servers may communicate through stdio. Both can carry malicious behavior that is difficult to identify through conventional network indicators alone.
- Instructions hidden in metadata. The malicious direction lives in tool descriptions and schemas rather than in the request body, which most inspection pipelines don’t parse.
- Non-browser runtimes. Much of the activity runs from IDEs, command-line tools and local agents, so browser-only monitoring may miss activity originating in IDEs, command-line tools, and local agent runtimes. Endpoint and network controls may provide partial visibility, but understanding agent intent and tool semantics requires additional context.
- Policy without enforcement. Written policy complements runtime controls but doesn’t enforce them; published analysis notes that policies don’t enforce behavior during AI operations at runtime.
Effective defenses combine agent and MCP discovery, approved-tool enforcement, least-privilege credentials, appropriate pre-execution protection, and audit trails. Direct tool-call validation adds protection where the architecture supports it.
Runtime AI Threats Need Runtime Defense.
WitnessAI’s enterprise AI firewall delivers bidirectional runtime defense, blocking prompt injections, jailbreaks, and data exfiltration before they reach your models or your customers.
Explore ProtectWhat AI risk management for agents and MCP servers looks like in practice
AI risk management for MCP treats each server as a supply-chain component whose permissions, configuration, and behavior are monitored and periodically revalidated, with runtime authorization checks where supported. If you’re moving an agent program from pilot to production, the three controls below move that verification from install time to runtime.
The pattern across published guidance is consistent: discover what’s connected, enforce tool authorization at supported runtime control points, monitor for unexpected changes, and maintain accountability for agent actions. None of this is theoretical. Each control maps to a specific failure mode the Postmark case exposed.
1. Discover agents and MCP connections at the network level
Building AI inventory comes first because the gap is wide. In a survey of 300 U.S. CISOs, 67% reported limited visibility into AI deployment and none claimed full visibility. Gartner expects a typical Fortune 500 enterprise to run 150,000 agents by 2028, up from fewer than 15 in 2025.
Shadow MCP servers tend to appear when developers lack a sanctioned path to the integrations they need, so discovery has to come before you offer one. Useful discovery operates at the network level rather than relying on endpoint agents or browser extensions, since much of the activity runs from IDEs, CLI tools and local runtimes. The goal is to build an inventory of observable agent activity, connected MCP servers, and exposed tools, while identifying visibility gaps that require additional instrumentation.
2. Replace one-time approval with allow-lists and pre-execution checks
Approval needs to become a runtime check rather than an install-time click. Pinning tool descriptions and schemas with SHA-256 hashes and verifying them before each execution turns a silent rug pull into a detectable mismatch. Joint international guidance published in May 2026 adds minimum permissions, validation of third-party tools and human approval for high-impact actions.
Credential scope matters as much as the allow-list itself. An agent that only reads mail should hold a mail.readonly token, not mail.full_access. Pre-execution protection can reduce risk when applied at the appropriate integration point. Organizations should separately validate tool permissions, arguments, and sensitive-data exposure using controls supported by their agent architecture.
3. Attribute agent actions to a human and keep audit trails intact
Post-incident forensics depend on audit trails that identify who authorized an action and what data moved. In a January 2026 survey of 418 professionals, 65% reported an AI agent security incident in the prior 12 months, and 61% of those involved data exposure or mishandling.
An audit trail that only captures the agent’s actions, without sufficient context linking the initiating identity, agent, tool invocation, policy decision, and relevant interaction data, leaves investigators guessing. For regulated workloads, that gap is also what makes breach-notification clocks difficult to meet with confidence.
Blocking AI Isn’t a Strategy. Governing It Is.
WitnessAI enforces intent-based policies, routes prompts to the right models, and redacts sensitive data in real time so your teams keep moving while your data stays protected.
Explore ControlClosing the MCP trust gap before the next backdoored package ships
The Postmark backdoor, rug pulls and poisoned descriptions share one weakness on the defender’s side: trust established once and never re-checked. Moving that verification to runtime through discovery, allow-lists, pre-execution checks and human attribution helps an agent program leave pilot with evidence a risk committee can read.
WitnessAI combines agent and MCP observability, approved-tool governance for traffic traversing supported network integrations, and API-based runtime protection for custom agent workflows. Its audit capabilities help connect observed agent activity to the initiating corporate identity.
Schedule a demo to explore how WitnessAI supports agent and MCP governance through network integrations and API-based runtime protection, and determine which supported architecture fits your environment.