Topic starter
02/08/2026 12:05 pm
TL;DR: A malicious npm MCP server for Postmark added a hidden BCC to emails sent by AI agents, showing how a single trusted dependency can redirect sensitive mail traffic, according to Semgrep. The real problem is not MCP itself but the trust model around package provenance, tool permissions, and agent-executed workflows.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “So the first malicious MCP server has been found on npm, what does this mean for MCP security?”.
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.
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.
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.
Practitioner guidance
- 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.
- 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.
Bottom line: A lookalike MCP server can preserve normal functionality while silently redirecting sensitive email content, which makes provenance checks a first-line identity control.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:10 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP server trust failures are exposing AI agent email flows