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.
NHIMG editorial — based on content published by Semgrep covering the malicious npm MCP server postmark-mcp and the trust model around AI agent tools
Questions worth separating out
Q: How should security teams govern MCP servers used by AI coding assistants?
A: Treat MCP servers as privileged trust boundaries, not simple data sources.
Q: Why do MCP servers create more NHI risk than ordinary API integrations?
A: MCP servers sit in the execution path of AI tools, so a compromised credential can become a control point for multiple downstream actions, not just one API call.
Q: What do security teams get wrong about AI agent authentication?
A: They often confuse prompt-level identity propagation with enterprise authentication.
Practitioner guidance
- Verify MCP server provenance before deployment Only allow servers from trusted publishers or directly from the original developer repository, and require code review for any package that can process sensitive data or send messages on behalf of users.
- Scope each MCP tool to the minimum delegated function Review every exposed tool for hidden data paths, especially email, notifications, and document generation.
- Inspect outbound workflows for covert copy behaviour Test whether message handling, templates, and notification flows can be altered to add silent recipients, headers, or forwarding logic.
What's in the full article
Semgrep's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact npm typosquatting pattern used to make the malicious MCP server look legitimate to developers.
- The code-level BCC change that redirected outbound emails without breaking the normal workflow.
- The security controls Semgrep recommends for MCP server development, including validation, authorization, and supply chain checks.
- The practical steps developers can take to separate trusted repository code from republished package copies.
👉 Read Semgrep's analysis of the malicious MCP server on npm →
MCP server trust failures: are AI agent controls keeping up?
Explore further
MCP server trust is now an NHI governance problem, not just a developer convenience problem. The article shows that the risky object is not the AI interface alone but the server identity, package provenance, and delegated tool scope behind it. Once an MCP server can move sensitive data, it should be governed like any other non-human identity with explicit ownership and lifecycle controls. Practitioners should stop treating tool wrappers as low-risk plumbing and start treating them as privileged execution surfaces.
A question worth separating out:
Q: How do teams reduce supply-chain risk in agentic AI deployments?
A: Teams should verify every artefact that can influence runtime behaviour, including tokenizer files, prompt templates, and packaging metadata. They also need a revocation path for mirrored or derived models so tampering does not persist across environments. The goal is to govern the full model package, not just the weights.
👉 Read our full editorial: MCP server trust failures are exposing AI agent email flows