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

At a glance

What this is: A malicious npm package turned a trusted MCP email workflow into a covert exfiltration channel for sensitive messages.

Why it matters: IAM and security teams need visibility into shadow MCP usage because delegated automation can bypass both asset inventory and traditional email controls.

By the numbers:

• A malicious backdoor in an npm package called postmark-mcp was downloaded roughly 1,500 times per week.
• 1.0.16 after earlier versions had already earned trust., ns had already earned trust.

👉 Read Oasis Security's analysis of the MCP breach and shadow AI exposure

Context

Shadow AI becomes an identity problem when a trusted tool can act on behalf of systems and people without being visible to security teams. In this breach, an npm package used inside AI and automation pipelines quietly changed behaviour and turned outbound email into a data-exfiltration path.

The governance gap is not just malicious code. It is the combination of delegated access, weak inventory, and automatic invocation that lets a compromised MCP tool operate as if it were approved. For IAM teams, the question is whether these tools are governed as identities with privileges or treated as ordinary software dependencies.

Key questions

Q: What breaks when an MCP tool is compromised inside an automation workflow?

A: A compromised MCP tool can still appear functional while duplicating or rerouting sensitive data through legitimate permissions. That is what makes the failure so hard to spot. The real break is the trust boundary, because the workflow continues to run while confidentiality is silently lost.

Q: Why do shadow AI tools complicate IAM governance?

A: Shadow AI tools complicate IAM because they can hold real privileges without appearing in normal inventory or review processes. If a tool can send data, call APIs, or reach databases, it behaves like an identity with access. Governance fails when the access path exists but no one can name or own it.

Q: How can security teams reduce exfiltration risk in MCP-enabled workflows?

A: Security teams should split high-risk actions, log all delegated tool use, and require approval for integrations that can move sensitive content. The goal is to make hidden duplication difficult and detectable. Discovery and ownership are essential because you cannot control a privileged tool you have not mapped.

Q: What should organisations do when an AI automation package changes behaviour?

A: Organisations should suspend trust in the changed package until the new behaviour is reviewed, the owner is confirmed, and the connected workflows are revalidated. Any package that can influence email, data, or API access needs the same lifecycle discipline as other privileged non-human identities.

Technical breakdown

How a compromised MCP package turns email into an exfiltration channel

Model Context Protocol tools often sit between AI workflows and operational systems such as email, databases, and APIs. When a package like postmark-mcp is trusted by an automation pipeline, a small code change can alter message routing without changing the surrounding workflow. In this case, the malicious version appended a hidden recipient to every outgoing email, which meant the tool still appeared to function normally while duplicating sensitive content externally. The failure mode is not a noisy exploit. It is a trusted execution path that quietly becomes a delivery mechanism for stolen data.

Practical implication: inventory every MCP tool that can move sensitive content and treat message-routing permissions as privileged access.

Why shadow AI defeats standard discovery and DLP controls

Shadow AI refers to AI agents, assistants, or supporting tools that operate outside formal visibility and approval. Once an MCP library is invoked automatically, security teams may never see it as a distinct asset, especially if it runs inside developer pipelines or shared automation. Traditional DLP, email gateways, and endpoint protection are tuned for obvious exfiltration paths, not for a trusted integration that duplicates messages from the inside. That is why discovery matters as a governance function, not just an inventory exercise.

Practical implication: build continuous discovery for MCP servers and AI agents, then bind them to approval and monitoring workflows.

Why trust in earlier versions can hide malicious change

Supply chain abuse often works because the first versions of a package behave as expected and build confidence. A later release can then introduce a small, targeted change that preserves normal function while adding covert behaviour. That pattern is especially dangerous for AI and automation pipelines because the tool is already embedded in a workflow that expects machine speed and low human review. The attack surface is not only the package itself, but the trust model around version updates and unattended execution.

Practical implication: add release-level review for tools with email, data, or API privileges before they are allowed into unattended workflows.

Threat narrative

Attacker objective: The attacker aimed to siphon sensitive business and account-recovery messages from a trusted email workflow without triggering obvious detection.

1. Entry occurred when developers installed the postmark-mcp npm package into AI and automation pipelines to handle transactional email workflows.
2. Credential access and abuse were achieved through the tool's legitimate email privileges, which allowed it to duplicate outgoing messages to an external recipient without breaking normal function.
3. Impact followed as invoices, password resets, and internal correspondence were exfiltrated through a trusted automation path that standard controls did not surface.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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 an identity governance problem the moment a tool can act with delegated privileges outside inventory. The breach shows that discovery is not a housekeeping task, it is the boundary that tells IAM whether an automation path exists at all. When an MCP server can send emails, query data, or invoke APIs without being catalogued, governance has already failed. Practitioners should treat invisible MCP tools as unmanaged identities with unresolved ownership.

Trusted automation is the real failure mode here, not just malicious code. The package behaved normally long enough to earn confidence, then used that confidence to hide exfiltration inside routine email delivery. That is a classic trust boundary collapse in NHI governance: the control plane assumes the tool remains benign after approval, but the runtime path is exactly where abuse appears. The implication is that approval cannot be a one-time event for privileged automation.

Deep privileges on MCP tools create a broad identity blast radius. If a package can send transactional emails, the same delegated trust can expose password resets, invoices, internal correspondence, and downstream account recovery flows. That makes MCP identity design a privilege-scoping problem, not a software procurement problem. Practitioners should assume every auto-invoked MCP integration can become a high-impact identity dependency.

Shadow AI lessons from the MCP breach show that asset inventory and access governance now converge. The same control gap that hides an unmanaged tool also hides who owns its privileges, who approves its use, and who can revoke it when behaviour changes. That is why MCP governance belongs in the same operational model as service account review and privileged access oversight. The practitioner conclusion is simple: if you cannot name the identity, you cannot govern the access.

MCP tools need lifecycle governance, not just package hygiene. The breach illustrates a lifecycle failure mode where a tool stayed trusted after its behaviour changed. That means onboarding, review, ownership, and removal must be explicit for every AI-connected integration. Practitioners should govern MCP servers as living access paths with accountable owners and revocation points.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That fragmentation and behaviour gap are why teams should also read Guide to the Secret Sprawl Challenge for the operational controls that reduce secret-driven shadow risk.

What this signals

Shadow AI creates a governance gap that conventional asset inventories do not close. Once a tool can be invoked automatically inside an email or data workflow, the control problem shifts from software management to identity management. Teams need continuous discovery, ownership, and revocation paths for every AI-connected integration, including tools that look like ordinary dependencies.

Identity blast radius is the right concept for MCP governance. A single tool with mail, data, or API privileges can expose far more than its package name suggests, so teams should measure the downstream systems each integration can touch. That changes prioritisation from package count to privilege scope and business impact.

The pressure point is not only malicious code but unmanaged trust. If a workflow can duplicate sensitive messages without a visible change to the user experience, the security programme is already depending on assumptions that no longer hold.

For practitioners

• Inventory every MCP endpoint and AI tool path Map each MCP server, package, and automation workflow that can send mail, query data, or call APIs. Record the owner, the runtime location, the connected systems, and whether the tool is approved for production use. Treat undiscovered tools as shadow AI until proven otherwise.
• Restrict outbound content privileges by default Separate message composition from message delivery so a compromised tool cannot silently duplicate sensitive content. Where that split is not possible, gate high-risk email workflows behind explicit approval and logging, especially for password resets and internal correspondence.
• Review package updates for privileged automation paths Require release-level checks before new versions of MCP libraries enter unattended workflows. Focus review on changes to recipient handling, API scope, and data forwarding behaviour, because small code diffs can create large exfiltration paths.
• Bind AI and MCP usage to named ownership Assign an accountable owner for each AI-connected integration and define a revocation process for suspicious behaviour. Ownership should cover both the tool and the workflows it can influence, so security teams can isolate the path quickly when trust changes.

Key takeaways

• The breach shows that a trusted MCP tool can become a covert exfiltration path without breaking the user-visible workflow.
• The scale of the risk comes from delegated privileges, shadow deployment, and routine automation, not from a noisy exploit chain.
• The control that matters most is continuous discovery plus named ownership for every privileged AI-connected integration.

Key terms

• Shadow AI: Shadow AI is an AI tool, assistant, or agent that operates without formal inventory, approval, or governance. In practice, it behaves like an unmanaged identity because it can hold access, move data, or invoke actions outside the security team's visibility.
• MCP Server: An MCP server is a Model Context Protocol endpoint that connects AI systems to tools and data sources. In identity terms, it becomes a privileged non-human access path when it can send messages, query records, or invoke APIs on behalf of a workflow.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and workflows exposed when a single identity or tool is compromised. For MCP and AI automation, it is measured by the downstream privileges an integration can reach, not by the package name or where it is installed.
• Delegated Privilege: Delegated privilege is access granted to a tool or system so it can perform actions without direct human intervention. The risk rises when delegation is broad, hidden, or hard to revoke, because the delegated actor can continue operating after trust has changed.

Deepen your knowledge

Shadow AI discovery and privileged tool governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment includes MCP-driven automation or hidden AI tool paths, the course helps you map where governance needs to start.

This post draws on content published by Oasis Security: Lessons from the MCP Breach and Shadow AI exposure. Read the original.