MCP server trust failures are exposing AI agent email flows

At a glance

What this is: This is an analysis of a malicious npm MCP server and the security gap it exposes in AI agent tool trust.

Why it matters: It matters because IAM, NHI, and agentic AI teams must treat MCP servers as privileged identity-bearing components, not just convenient integrations.

👉 Read Semgrep's analysis of the malicious MCP server on npm

Context

Model Context Protocol, or MCP, is the interface that lets AI assistants and agents call tools in existing software. In this case, the security issue was not a broken protocol implementation but a malicious package that exploited trust in the software supply chain and the permissions attached to the tool.

For identity teams, the governance problem is that MCP servers can move sensitive data without changing the user-facing workflow. That creates a hidden control plane for non-human identity activity, where package provenance, tool scope, and consent are all part of the security boundary.

This is an NHI and agentic AI problem at the same time: the server is a non-human identity component, while the AI agent can act through it at runtime. The starting assumption that a tool wrapper is harmless because it is simple is increasingly typical, and increasingly dangerous.

Key questions

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. Security teams should classify each server by the authority it can influence, sanitize any user-generated or third-party content before delivery, and limit the agent’s tool access so malicious context cannot easily become destructive action.

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. The risk is amplified when the server uses long-lived secrets, because the same identity can persist across sessions, users, and tool invocations.

Q: What do security teams get wrong about AI agent authentication?

A: They often confuse prompt-level identity propagation with enterprise authentication. A claim injected into an agent does not equal a durable control plane, and it does not guarantee self-service federation, fine-grained policy, or revocation. Production readiness depends on the surrounding identity architecture, not on the agent toolkit alone.

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.

Technical breakdown

Why MCP tool wrappers become privileged identity surfaces

MCP exposes application functions as tools, often through a simple HTTP or stdio server. That simplicity is useful, but it also means the server becomes a privileged intermediary for data, actions, and sometimes secrets. If the server is republished, typosquatted, or altered, the agent may still execute the same tool call while the underlying behaviour changes. The trust decision shifts from the application UI to the package source, dependency integrity, and server provenance. In identity terms, the server is acting as a machine identity with delegated authority, even if the user only sees a harmless integration.

Practical implication: Treat every MCP server as a governed NHI with explicit provenance checks and scope review before allowing it into production workflows.

How a hidden BCC turns an email tool into a data exfiltration path

The attack described here did not rely on malware or obfuscation. It relied on a tiny code change that duplicated outbound email to an attacker-controlled address. That is a classic integrity failure in the application path, because the legitimate workflow still completes while the attacker silently receives the message content. For security notifications, password resets, and transactional mail, that can expose tokens, account details, and other sensitive data. The risk is especially sharp when an AI agent is generating or sending content at scale, because the agent may trigger the same tool repeatedly without human inspection.

Practical implication: Inspect outbound content paths and email-handling tools for duplication, forwarding, and covert copy logic before they are allowed into agent workflows.

Why package popularity is not a security control for MCP supply chains

The article shows that the package looked legitimate because it had history, a realistic developer profile, and enough versions to avoid obvious suspicion. That is not the same as trust. In public package ecosystems, popularity, age, and naming similarity can all be manipulated, especially when the package is a wrapper around a widely used service. For MCP, the supply chain risk is amplified because users may install a server once and then let an AI agent invoke it repeatedly. The result is long-lived delegated access built on weak provenance assumptions.

Practical implication: Require signed provenance, publisher verification, and code review for any MCP server that can handle sensitive data or act on behalf of users.

Threat narrative

Attacker objective: The attacker aimed to silently siphon sensitive email content and related account data without disrupting the normal delivery workflow.

1. entry via a typosquatted npm package that reused the legitimate MCP server name and appearance, giving the attacker distribution into developer workflows.
2. escalation through a subtle code modification that added a hidden BCC to outbound emails, preserving normal functionality while silently copying content to the attacker.
3. impact through interception of password reset messages, security notifications, and other sensitive email content sent through AI agent workflows.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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

NHI Mgmt Group analysis

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.

Tool provenance is the named concept here: a server’s origin, publisher integrity, and code lineage have become part of the access decision. The attack worked because the package looked legitimate enough to inherit trust, even though its behaviour changed later. That is a governance failure in the identity layer, because the access path depended on where the code came from as much as what it was allowed to do. Practitioners need to treat provenance as a first-class attribute in tool approval and review workflows.

Zero trust for AI agents only works if the tool layer is verified every time trust is extended. AI agents may not be autonomous in every deployment, but they still consume delegated authority through MCP and can amplify a single compromised server across many actions. The article validates the need for explicit verification of publisher, package integrity, and tool scope before an agent is allowed to act. Practitioners should assume that convenience will keep outpacing scrutiny unless identity controls are made mandatory.

Least privilege is being violated at the tool boundary, not just at the account boundary. The server exposed only a small set of functions, yet one extra line changed the security outcome completely. That shows why access reviews that focus only on user entitlements miss the more important question of what each tool can do with delegated authority. Practitioners should recast privilege analysis around the action path, not just the login path.

AI agent governance and NHI governance are converging on the same failure mode: silent delegation without continuous verification. The article’s deeper lesson is that the agent does not need to be malicious for the ecosystem around it to fail. If the server, package source, and permissions are not continuously revalidated, the agent becomes a multiplier for hidden compromise. Practitioners should align AI controls, software supply chain checks, and NHI lifecycle governance instead of treating them as separate disciplines.

What this signals

MCP trust will increasingly be judged like any other delegated identity control. As agents start invoking more tools, the line between application integration and NHI governance will blur further. Teams that already manage service accounts, token scopes, and software provenance have an easier path to governing MCP than teams that still treat it as a developer-only concern.

Tool provenance is becoming the practical control point for AI-enabled workflows. The important question is no longer whether a package exists, but whether its origin, publisher, and behaviour can be continuously trusted. That shift pulls software supply chain controls into the centre of identity governance for AI systems.

For practitioners, the most useful next move is to align AI agent permissions with the same review discipline used for NHI lifecycle management. If an MCP server can send, read, or transform sensitive content, it should have an owner, an approval trail, and a revocation path just like any other privileged machine identity. The organisations that treat this as a governance issue will close the gap sooner than those waiting for a dedicated AI control standard to do the work for them.

For practitioners

• 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. Remove any capability that can duplicate, forward, or transform sensitive content without an explicit business need.
• 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. Include these checks in secure code review and runtime monitoring.
• Tie AI agent approvals to package integrity controls Do not let an agent invoke a newly installed MCP server until the package is verified, the publisher is confirmed, and the access scope is documented in your identity governance process.
• Model MCP servers as governed NHI assets Assign ownership, review cadence, and revocation paths for every server that can access data or perform actions. If the server cannot be offboarded cleanly, it is not ready for production use.

Key takeaways

• The real risk in this MCP attack was not model behaviour but delegated trust in a republished tool server.
• A tiny code change in a trusted-looking npm package was enough to create a covert email exfiltration path.
• Security teams should govern MCP servers as privileged non-human identities, with provenance checks, least privilege, and revocation controls.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Action Provenance: Action provenance is the record of who initiated a task, which identity executed it, what tool was used, and what decision was made at runtime. It is essential when delegated work crosses systems because it preserves accountability even when the original request and the final action are separated by many steps.
• Delegated non-human identity: A machine or agent identity that acts on behalf of a user or system and inherits access to connected tools. The control problem is not only authentication, but the scope, duration, and downstream reach of that delegation once the session is established.

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.

👉 Semgrep's full post covers the attack chain, tool trust failure, and defensive controls in more detail.

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 or identity governance programme, it is worth exploring.