Topic starter
06/06/2026 1:58 am
TL;DR: A malicious backdoor in the postmark-mcp npm package, downloaded about 1,500 times per week, BCCed every outgoing email to an external address and exposed invoices, password resets, and internal correspondence, according to Oasis Security. The breach shows that trusted automation can become a data-exfiltration path when MCP tools sit outside normal inventory and approval controls.
Editorial analysis by NHI Mgmt Group, based on content published by Oasis Security: “Lessons from the MCP Breach: Shadow AI”.
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.
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.
Q: How should teams detect compromised MCP packages before business data leaks?
A: They should combine inventory, package reputation checks, and outbound behaviour monitoring.
Practitioner guidance
- 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.
Bottom line: A trusted MCP package can turn ordinary automation into a covert exfiltration path when runtime behaviour is not continuously governed.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
06/06/2026 3:22 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Shadow AI in the MCP breach exposed trust in automated email workflows
This post was modified 5 days ago by NHI Mgmt Group