MCP server trust failures are exposing AI agent email flows

At a glance

What this is: A malicious npm MCP server for Postmark quietly added a BCC to AI agent-sent emails, showing how a trusted tool path can redirect sensitive communications without obvious malware.

Why it matters: IAM and NHI teams need to treat MCP server provenance, tool permissions, and email workflows as governance controls because trust failures can expose sensitive tokens, notifications, and account data.

Context

MCP trust breaks when an organisation assumes the server behind a tool call is the same one the developer intended to use. In this case, a malicious npm package reused a familiar name and altered email output with a single hidden BCC, which meant the security problem was provenance and execution trust rather than obvious malware.

For AI agent programmes, that matters because the agent is not just reading or recommending. It is acting through a delegated tool path that can handle sensitive communications, so the control boundary moves from the model to the server, the package source, and the permissions attached to the email workflow.

The article is really about the security debt created when flexible integration outpaces governance. MCP is simply the current form of that debt, not the root cause.

Key questions

Q: What breaks when an MCP server is not the one the team intended to trust?

A: The failure is provenance, not just code quality. If a lookalike package can replace the intended MCP server, the agent may still function while sending data or messages through the wrong implementation. That means trust must be anchored in publisher verification, package integrity, and approval of the exact server artifact before the agent is allowed to use it.

Q: Why do AI agent email workflows increase the impact of a malicious integration?

A: Because email workflows often carry password resets, account notices, and other sensitive content that users expect to be private. When an agent can send mail automatically, the integration becomes a delegated communication channel, so a hidden recipient change can expose valuable information without breaking the visible service.

Q: What do security teams get wrong about MCP plugin risk?

A: Teams often treat plugins as if they were ordinary extensions, when in practice they can become trust-bearing execution components. If a plugin can influence tool output or run commands, it must be validated, scanned, and constrained before use. The mistake is assuming registry presence equals legitimacy.

Q: Should organisations treat AI tool connectors as part of NHI governance?

A: Yes. Once an AI workload can invoke tools and access data, it behaves like a governed non-human identity and should be subject to lifecycle, ownership, and scope controls. The practical question is not whether the connector is clever, but whether it is inventoried, authorised, monitored, and removable when no longer needed.

Technical breakdown

Why MCP server provenance is the real control point

MCP is a tool interface, not a trust framework. The client asks a server to expose functions such as sending email, listing templates, or returning delivery statistics, but the security model depends entirely on whether the server is authentic and whether its package origin is trustworthy. A reposted package with the same name can preserve the same surface area while changing the behaviour in one line of code. That is why provenance, package identity, and review of what the server actually executes matter more than the protocol label itself. In practice, the risky object is the distributed server artifact, not the MCP concept.

Practical implication: verify the source and integrity of every MCP server before allowing it into an agent workflow.

How AI agent email tools expand the blast radius

Email tools look narrow, but they often process high-value traffic such as password resets, notifications, receipts, and account alerts. When an AI agent can invoke those tools automatically, the agent becomes a delegated sender with access to the contents and timing of outbound mail. A hidden BCC is enough to exfiltrate sensitive messages because it does not need to break authentication, steal credentials, or alter the sending application. The abuse path is subtle: preserve delivery, preserve user trust, and quietly duplicate content to an attacker-controlled inbox. That is why message workflows are identity-sensitive even when the underlying tool appears low risk.

Practical implication: classify AI-driven email sending as a privileged workflow and apply tighter permissions and review than a normal integration.

Why simple packaging does not mean simple security

The article shows that MCP servers can be bare-bones HTTP or stdio services, but minimal architecture does not remove governance needs. In fact, simplicity can hide the absence of controls because there may be no built-in identity layer, no enforced authorisation boundary, and no assurance that the package came from the expected maintainer. That leaves the user to make a trust decision at install time and the agent to inherit it at runtime. For security teams, the lesson is that low-friction integration expands the chance of unreviewed privilege, especially when the server can handle business-sensitive data.

Practical implication: require code review, publisher verification, and explicit authorisation for every MCP server that handles sensitive data.

Threat narrative

Attacker objective: The attacker appears to have wanted silent access to sensitive outbound email content while avoiding obvious malware detection and preserving normal delivery.

1. Entry occurred when the attacker published a lookalike npm MCP server that users could mistake for the legitimate Postmark integration.
2. Credential or content access followed when the server processed outbound AI agent email traffic through its normal send function.
3. Exfiltration occurred through a hidden BCC that copied each message to an attacker-controlled inbox without disrupting delivery.
4. Impact was the potential exposure of password reset messages, receipts, and other sensitive account communications.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP trust is a provenance problem before it is a protocol problem: The security failure here was not that MCP exists, but that organisations can mistake a downloadable package for a trusted integration. Once an AI agent inherits that package’s permissions, the control boundary becomes the server artefact, not the agent interface. Practitioners should treat server provenance as part of identity governance, not just software intake.

Delegated email sending is a privileged identity action, even when the tool looks narrow: Outbound mail often carries password reset links, receipts, account notices, and sensitive operational details. If an agent can trigger that workflow, the agent is effectively acting as a delegated sender with access to business-critical content. The implication is that email tools need the same permission scrutiny as other high-impact NHI workflows.

Hidden-content theft is the modern trust failure mode for AI integrations: A single line that adds a BCC can preserve deliverability while quietly diverting information. That pattern undermines the assumption that obvious malware will be present when a tool is malicious. Practitioners should expect abuse to come through normal functionality with altered routing, not through noisy compromise.

Zero trust for AI agents starts with tool and publisher verification, not model behaviour: The article points toward a governance model where trust is earned continuously, not inherited from package popularity or naming familiarity. That aligns with the broader shift from assuming tool safety to validating source, scope, and permitted action at every integration point. The operational takeaway is that agent governance must extend to the software supply chain behind the tools the agent uses.

MCP security will be judged by off-platform controls, not protocol ambition: The protocol can remain simple and still be made safer only if organisations add review, provenance checks, and authorisation guardrails around it. Without those controls, flexibility becomes an invitation for supply chain abuse. The practical conclusion is that governance has to move upstream into package choice, not downstream into incident response.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: MCP Security Guide

What this signals

Hidden trust is the new control plane: MCP makes it easy to wire AI into operational systems, but that convenience shifts risk to the server package, the publisher, and the runtime permission set. Security programmes that still assume “installed equals trusted” will miss the real attack surface.

Privilege now lives in the tool path, not just the account: An agent that can send mail automatically can also leak whatever the message contains or whatever routing change the server introduces. Governance has to examine who published the server, what the server can do, and how far the agent can drive it.

24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption. That scale suggests the control gap is already broader than one malicious package and will keep widening as adoption grows.

For practitioners

• Verify MCP server provenance before installation Allow only known publishers and official repositories for MCP servers that can send email or access sensitive workflow data. Re-check package ownership, maintenance history, and release integrity before approval.
• Restrict AI agents to the minimum email scope Limit agent-executed email tools to the smallest possible message set, and separate template editing, delivery statistics, and outbound send permissions where the workflow allows it.
• Review outbound mail for hidden routing changes Inspect sending logic for blind-copy paths, alternate recipients, forwarding rules, and template mutations that preserve delivery while altering message visibility.
• Treat package selection as identity governance Map MCP server approval to the same governance workflow used for third-party NHI access, including ownership review, renewal checks, and removal of abandoned integrations.

Key takeaways

• A lookalike MCP server can preserve normal functionality while silently redirecting sensitive email content, which makes provenance checks a first-line identity control.
• The compromise path here did not depend on noisy malware or stolen credentials, but on trusted tool execution and hidden message routing.
• Teams that govern MCP server approval, outbound email permissions, and package integrity together will reduce the chance that delegated AI workflows become covert data channels.

Key terms

• MCP Server Provenance: The verifiable origin and ownership of an MCP server package or deployment. In practice, provenance determines whether an AI agent is executing through the intended tool or through a lookalike component that can alter behaviour after installation.
• Delegated Email Workflow: An email process that an AI agent or other non-human identity can trigger on behalf of a user or application. The security issue is not the mail system alone, but the scope of authority granted to the tool that can send, modify, or reroute messages.
• Hidden Routing Change: A message-handling modification that preserves the visible function of a workflow while silently copying, redirecting, or exposing content elsewhere. In AI-integrated systems, hidden routing changes are dangerous because they can survive ordinary functional testing.
• Tool Permission Boundary: The limit that defines what an AI application may access or do through connected tools, retrieval sources, or delegated privileges. When this boundary is too broad or poorly tested, red team findings may expose authorization failures rather than just prompt weaknesses.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.