Shadow AI in the MCP breach exposed trust in automated email workflows

At a glance

What this is: This is an analysis of how a malicious MCP package turned automated email handling into a covert exfiltration channel by silently BCCing outbound messages.

Why it matters: It matters because IAM, NHI, and AI governance teams need visibility into MCP tools that operate with delegated access but outside normal asset, approval, and review processes.

Context

MCP tools can sit inside automation flows while operating with the kind of delegated access that makes them easy to trust and hard to notice. When those tools are not tracked as part of the inventory, security teams lose the ability to distinguish approved automation from shadow AI or compromised infrastructure.

In this case, an npm package used in AI and automation pipelines handled transactional email and then silently added exfiltration logic. That is not a generic malware story. It is a governance failure in a non-human identity path where trusted execution, not user compromise, carried the data out.

Key questions

Q: What breaks when an MCP tool is trusted before it is inventoried?

A: Security teams lose visibility into where sensitive data is being handled, which means a malicious update can persist inside routine automation without ownership, approval, or review. The result is not just a bad package, but a blind spot in the identity and control plane that allows normal-looking traffic to carry exfiltration.

Q: Why do trusted automation tools increase exfiltration risk in email workflows?

A: Because the tool itself can modify content or forwarding behaviour after it has already been approved for business use. Once a workflow identity can send messages on behalf of the organisation, malicious logic inside that tool can move data out while appearing operationally normal.

Q: How should teams detect compromised MCP packages before business data leaks?

A: They should combine inventory, package reputation checks, and outbound behaviour monitoring. The key is to compare what the workflow is supposed to do with what it is actually doing, especially when tools handle invoices, password resets, or internal correspondence.

Q: What should organisations do when employees use shadow AI with sensitive context?

A: They should treat it as an access and governance problem, not just a policy violation. That means discovering unsanctioned tools, limiting the identities that can submit sensitive material, and controlling the endpoints and browsers where those tools are used. The objective is to reduce invisible recombination, not simply to forbid AI use.

Technical breakdown

How a trusted MCP package became a covert exfiltration path

The compromise relied on supply-chain trust rather than exploit complexity. A package that had already built confidence through earlier benign versions was updated with a one-line change that BCCed every outgoing email to an external address. Because the package sat in an AI and automation workflow, the malicious behaviour blended into legitimate transactional processing. This is the core risk in MCP ecosystems: once a tool inherits operational trust, its output can become a data channel without triggering obvious user-facing alarms.

Practical implication: treat MCP packages and services as governed execution paths, not ordinary dependencies.

Why normal controls miss shadow AI email workflows

Standard tooling often sees the email leaving, but not the hidden logic inside the trusted automation layer that modified it. If an MCP server is not in the asset inventory, not tied to an owner, and not evaluated as part of vendor or package review, DLP and email security controls may only observe normal outbound traffic. The problem is not the absence of security tooling, but the absence of control over the non-human component that now carries privileged business logic.

Practical implication: extend discovery and ownership mapping to every MCP-enabled workflow that can send or transform data.

Why deep privileges make MCP compromise harder to contain

MCP servers can connect to email systems, databases, and APIs, which means compromise is not limited to a single function. Once malicious code lives in that layer, it can persist across repeated executions and affect multiple downstream systems without re-authentication or user interaction. In NHI terms, the issue is overextension of trust: the identity of the tool is granted far more operational reach than most teams realise, and that reach can be abused quietly over time.

Practical implication: scope MCP access by function and owner, then restrict which downstream systems each tool can reach.

Threat narrative

Attacker objective: The attacker aimed to steal sensitive business and account-recovery communications without disrupting the apparent function of the email workflow.

1. Entry occurred through a malicious update to the postmark-mcp npm package, which had already been trusted in AI and automation pipelines.
2. Credential or access abuse was not needed in the classic sense because the package itself ran with delegated permission to send transactional email, turning normal execution into exfiltration.
3. Impact came from the one-line BCC change that copied every outgoing message to an external address, exposing invoices, password resets, and internal correspondence.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI becomes a governance blind spot when MCP tools are deployed outside inventory. The deeper failure is not simply that a package was malicious. It is that organisations often treat AI-enabled tooling as if it were a peripheral dependency rather than an identity-bearing execution path. Once a tool can send business data on behalf of the enterprise, it needs the same lifecycle scrutiny as any other non-human identity.

Trusted automation is an exfiltration channel when output integrity is not governed. The article’s breach is a clean example of why delegated email workflows cannot be assumed safe just because the surrounding automation is routine. The trust relationship is the control surface, and when that relationship is invisible to security teams, compromise can persist under normal traffic patterns.

MCP tools need governance as operational identities, not just software components. This is where NHI governance and AI endpoint discovery converge. A package that can send email, query data, or invoke APIs is functionally part of the enterprise identity plane, which means owner mapping, approval boundaries, and runtime visibility are mandatory. Practitioners should treat these tools as governed identities with blast-radius limits, not as passive libraries.

Shadow AI discovery has become a prerequisite for controlling agentic and non-agentic automation alike. The same visibility gap affects AI assistants, MCP services, and other automation layers that act without direct human supervision. Discovery does not just reduce unknown assets; it reveals which automated paths have business authority before those paths become persistence channels for malicious code. The implication is straightforward: unknown automation is ungoverned trust.

MCP trust collapse is a named concept worth tracking across the category. A trusted tool can be converted into a covert data path after deployment, which means the security problem lives in the tool’s runtime authority, not only in its source code provenance. The practical conclusion is that governance must follow the tool into production, where its identity, access, and output can be monitored in context.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• 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.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

MCP trust collapse: once a package or service is allowed to act inside an automation flow, the security boundary shifts from the user to the tool itself. That boundary only holds if discovery, ownership, and approval are continuous rather than one-time checks.

A live inventory of MCP endpoints is now a governance control, not an optional documentation exercise. Without it, teams cannot separate approved automation from shadow AI, and they cannot prove which workflows are carrying privileged business data across the environment.

For practitioners

• Inventory every MCP-enabled workflow Create and maintain a live inventory of all MCP servers, packages, and AI automation endpoints, including shadow deployments that are not in formal architecture diagrams.
• Assign an owner to each tool path Require a named business and technical owner for every MCP component that can send, transform, or query sensitive information.
• Gate deployment of high-risk MCP packages Block unreviewed packages from production email and data workflows until they pass approval, provenance, and reputation checks.
• Monitor outbound workflow integrity Inspect automation paths for unexpected message modification, hidden forwarding behaviour, and unauthorized data copying inside trusted services.
• Constrain downstream reach Limit each MCP tool to the smallest set of systems it genuinely needs, and revoke cross-system access that is not required for the workflow.

Key takeaways

• A trusted MCP package can turn ordinary automation into a covert exfiltration path when runtime behaviour is not continuously governed.
• The breach exposed invoices, password resets, and internal correspondence, showing that the data at risk in these workflows is operationally sensitive rather than theoretical.
• Discovery, ownership mapping, and workflow-level access scoping are the controls that would have narrowed or exposed the failure earlier.

Key terms

• MCP trust collapse: The point at which a trusted MCP tool stops being a neutral utility and becomes a security boundary of its own. In practice, the tool’s runtime authority matters more than its label or provenance, because it can move, transform, or expose data once deployed.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Automation Identity: A non-human identity used by a workflow, script, or orchestration platform to perform actions in other systems. It is not the automation tool itself. The identity needs ownership, scoping, rotation, and retirement because its permissions define the real blast radius.
• Output integrity: The assurance that an automated workflow produces only the data transformations and transmissions it was authorised to perform. When output integrity fails, a trusted tool can silently alter messages, copy content, or redirect information without changing the visible user experience.

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 building or maturing an IAM programme, it is worth exploring.