Context7 MCP server poisoning exposes trust gaps in AI coding workflows

At a glance

What this is: This is a disclosure about Context7 MCP Server poisoning, where malicious Custom Rules were delivered through a trusted AI coding workflow and could drive secret theft, exfiltration, and destructive actions.

Why it matters: It matters because MCP servers can turn third-party content into trusted instructions for AI coding assistants, which means IAM, secrets, and tool-use controls must account for context poisoning, not just access rights.

Context

MCP trust is not the same as application trust. In this case, a server that was meant to provide library documentation also became a delivery path for attacker-controlled instructions, which meant the security boundary sat inside the AI coding workflow rather than around the IDE itself.

For identity and access teams, the important issue is not whether the MCP server can execute code. It is whether content delivered through a trusted NHI channel is being treated as authoritative by an AI agent with its own tool access. That changes the control problem from simple connectivity to trust propagation.

The article describes a classic trust-chain failure in agentic development: content, identity, and execution are compressed into one path. That makes Custom Rules, registry reputation, and downstream tool permissions part of the same governance surface.

Key questions

Q: What breaks when an MCP server delivers attacker-controlled instructions into an AI coding assistant?

A: The boundary between content and command breaks. If an MCP server can place untrusted text into an assistant’s context, the agent may treat it as authoritative instruction and use its own tools to read secrets, exfiltrate data, or modify files. The failure is not in code execution on the server, but in delegated execution through the agent.

Q: Why does MCP poisoning create more risk than a normal documentation issue?

A: Because the content is not just read by a person. It is consumed by an AI assistant that may already have write, shell, or network privileges in the developer environment. That makes poisoned content operational, not informational, and turns a documentation channel into a control path for actions on the host.

Q: What are the signs that an MCP-integrated workflow is too trusting?

A: Warning signs include unrestricted user-generated content flowing into agent context, registry reputation being used as the main trust signal, and the assistant being able to reach secrets or file systems without a separate content review step. If those conditions exist together, the workflow is likely overexposed.

Q: How should teams respond when AI coding tools can ingest untrusted registry content?

A: They should separate content ingestion from action authority. That means restricting what the assistant can see, limiting what it can do after ingesting external text, and reviewing every MCP source that can inject rules or prompts. The goal is to stop untrusted content from inheriting trusted execution rights.

Technical breakdown

How MCP content becomes trusted agent input

Model Context Protocol connects an AI client to external tools and data sources, but the protocol does not by itself solve provenance or content trust. In this case, Context7 used MCP to deliver documentation and Custom Rules into the assistant’s working context. The key failure mode is that the agent sees delivered content as instruction-bearing regardless of whether it originated from maintainers, users, or an attacker-controlled registry entry. That creates an instruction channel inside the data channel. Practical implication: separate transport trust from content trust when evaluating MCP-connected workflows.

Practical implication: Treat MCP-delivered text as untrusted until it is filtered, labeled, or constrained before reaching the agent.

Why a read-only MCP server can still drive harmful actions

A server does not need direct execution rights to create execution risk. Context7 exposed only lookup functions, but those functions fed text into an AI assistant that already had Bash, file read, file write, and network capability in the IDE. Once poisoned rules are accepted as authoritative, the agent can carry out the attacker’s intent with its own permissions. The architectural lesson is that execution authority often sits downstream from the server that supplied the malicious instruction. Practical implication: assess the downstream tool privileges of the agent, not just the apparent safety of the MCP server.

Practical implication: Map every MCP source to the toolset the agent can invoke after ingesting its output.

How registry reputation becomes part of the attack surface

Context7’s registry and trust signals were part of the abuse path. The article shows that social proof, GitHub history, stars, and even activity-based trust scores can be manufactured or acquired, which means reputation can be used to smuggle malicious content past human reviewers. The deeper issue is that popularity metrics are not content assurance controls. They may indicate adoption, but they do not validate the safety of what the registry serves through the MCP layer. Practical implication: do not let reputation metrics substitute for content sanitization and lifecycle review.

Practical implication: Verify the content delivered through a registry instead of relying on account history or popularity signals.

Threat narrative

Attacker objective: The attacker aims to steal development secrets, exfiltrate them through a trusted workflow, and damage local project files using the victim’s own AI assistant.

1. Entry occurred when an attacker registered a library and planted poisoned Custom Rules in the Context7 registry that was exposed through MCP.
2. Credential access followed when the AI assistant was instructed to search for and read .env files in the victim project.
3. Escalation and impact occurred when the poisoned rules drove exfiltration to an attacker-controlled GitHub repository and then triggered destructive file deletion on the local machine.

Breaches seen in the wild

• Mastra npm Supply Chain Attack — Sapphire Sleet: North Korean Sapphire Sleet backdoors 144 AI npm packages in 88 minutes via supply chain attack on Mastra ecosystem.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP trust has become an identity problem, not just a transport problem: This incident shows that the dangerous asset is no longer only the tool connection, but the trust state attached to content moving through it. A registry can be reachable, popular, and still hostile if the server serves attacker-controlled instructions into an agent’s context. For practitioners, the control question shifts from access to provenance.

Content provenance is the missing control plane for agentic development: Context7’s failure was not that it had a tool, but that it had no enforceable distinction between documentation and instructions. That is a governance gap, because the AI agent consumed both through the same MCP channel. OWASP-NHI and OWASP-AGENTIC both matter here, but the core issue is content that can alter behaviour without going through a separate approval path.

Trust scores are not lifecycle controls: Reputation signals built from GitHub history, stars, or activity can be bought, forged, or inflated. That means the security programme cannot treat those signals as evidence of safe delegation. The named concept here is instruction-channel poisoning: when untrusted content inherits the authority of a trusted delivery path, identity governance loses the ability to tell instruction from input.

Agentic workflows collapse the old boundary between read access and action authority: In a coding assistant, reading malicious content is often enough to cause execution, because the agent already has tools that can write, exfiltrate, or delete. That collapses the assumption that harmless input stays harmless until a human acts on it. The implication is that development governance has to distinguish data retrieval from action enablement at the moment of ingestion.

Context poisoning is now a supply-chain pattern for AI development: This case is not just about one server. It shows how third-party content, registry metadata, and downstream agent permissions can be chained into a single compromise path. The practitioner conclusion is that AI supply-chain review must include MCP server content handling, not just model hosting or dependency scanning.

From our research library:

• 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.
• Read next: MCP Security Guide

What this signals

Instruction-channel poisoning: AI coding workflows now need a control that verifies the provenance of content before it becomes part of the agent’s operating context. When a registry can serve attacker-controlled rules through a trusted MCP path, the practical boundary moves from authentication to instruction integrity.

The article’s scale signals why this is not a niche risk. Context7’s first-year MCP footprint included 24,008 unique secrets exposed in configuration files across the ecosystem, which is enough to show how quickly trusted tooling can turn into a secret-handling surface if ingestion is not governed.

For practitioners, the next step is to treat MCP-connected development tools as part of the identity plane. That means reviewing which sources can issue instructions, which agents can act on them, and where human approval must still interrupt execution.

For practitioners

• Audit MCP content boundaries Classify every MCP source as documentation, instruction, or mixed content, then decide whether the agent should ever see raw user-generated text from that source.
• Sanitize agent-fed registry content Strip or isolate Custom Rules, prompts, and other instruction-bearing fields before they can reach an AI assistant that also has file or network tools.
• Restrict downstream tool authority Limit the IDE agent’s ability to read secrets, write files, and make network calls when the upstream content source is not fully trusted.
• Treat reputation as advisory only Use GitHub stars, account age, and trust scores as weak signals, not as evidence that a registry entry is safe to ingest into an agent context.
• Review AI supply-chain exposure Map every installed MCP server to the libraries, registries, and external content sources it can feed into an assistant, then remove any path that can inject instructions without review.

Key takeaways

• MCP poisoning turns trusted content delivery into a security problem because AI assistants can act on malicious instructions as soon as they ingest them.
• This case shows that registry reputation, stars, and account history are not enough to establish safe trust for agentic development workflows.
• The control point is not only the MCP server itself, but the downstream permissions granted to the AI assistant after it receives external content.

Key terms

• Mcp Content Trust: The confidence a system places in content delivered through a Model Context Protocol channel. In agentic workflows, this trust is often stronger than it should be, because the AI may treat delivered text as instruction rather than data. Governance must distinguish transport trust from content trust.
• Instruction-Channel Poisoning: A failure mode where untrusted content inherits the authority of a trusted delivery path and changes how an AI agent behaves. The issue is not only the payload itself, but the channel that allows the payload to be treated as legitimate instruction by the downstream system.
• Agent Tool Authority: The set of actions an AI agent can perform once it has consumed context, such as reading files, writing files, or making network requests. This authority is distinct from the source that supplied the context, which is why a harmless-looking input channel can still enable damaging outcomes.
• Registry Reputation Signal: A popularity or trust metric derived from account age, stars, activity, or history. These signals can help with triage, but they are not assurance controls because they can be fabricated, purchased, or inflated and do not validate the safety of the content being served.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.