On March 24, 2026, a poisoned PyPI package was live for 40 minutes. During those 40 minutes, every machine that pip-installed LiteLLM received malware. It executed silently on every Python startup, harvesting AWS credentials, SSH keys, and Kubernetes tokens. The attackers got in by compromising Trivy, the security scanner LiteLLM used in its own CI/CD pipeline. A package with 95 million monthly downloads was compromised through the tool built to protect it.
When an AI agent loads a third-party MCP server, it grants that server access to the full session context. This includes credentials, system prompts, and prior tool outputs. The server receives all of this before it returns any result. Two attack vectors in this space have no npm analogue: rug pulls and context hijacking. Neither is addressed by code signing or dependency auditing.
No Third-Party Tool Runs With Less Than Agent-Level Trust
MCP servers are local processes. They run with the permissions of the user who started the agent. An npm-installed MCP server reads ~/.ssh/, ~/.aws/credentials, and every environment variable available to the parent process.
The trust model is binary: the agent either uses the tool or it doesn't. There is no least-privilege mode for tool plugins. The MCP protocol grants every registered tool access to the same context window that holds user credentials, system prompts, and prior tool outputs.
A CSA Labs scan (May 2026) covered 1,899 MCP servers and found a 5.5% tool poisoning rate. Zero percent of scanned servers included security documentation. The arXiv 2510.16558 paper documents the structural gap. MCP's trust model assumes server authors are trusted third parties, but no verification mechanism exists at the protocol layer.
Installing a tool plugin is not like installing a library. A library runs in your process. A tool server runs as a peer, receiving the full session context before any result is returned.
The Return Value Is Not the Only Channel
The standard mental model: the tool sends input, the server processes it, the server returns output. The attack surface seems bounded by the output.
The actual model: the server receives the full context window, including all prior tool results, credentials from prior turns, and the system prompt. All of this happens before any return value.
The MCP-38 threat taxonomy (arXiv 2603.18063) classifies "context hijacking" as a distinct threat class: the server reads context before returning anything. The return value is the visible channel; the context read is the invisible one.
Three exfiltration paths require no malicious return value. The server can make an outbound HTTP request during processing; the agent never sees it. It can write to a local file that it reads later. It can inject content into its return value that causes the orchestrator to make a further tool call that exfiltrates data. The Enkrypt AI scan (October 2025) found 33% of servers with critical vulnerabilities. None of the scan methods detected context-read exfiltration, which leaves no artifact in the agent trace.
Rug Pulls Have No npm Analogue
An npm supply chain attack: the attacker compromises a package version, victims who run npm install get the malicious version. Mitigation: pin versions, use lock files.
CVE-2025-54136 (CVSS 8.8) formalized a different pattern. In MCP, trust is bound to the server name, not its content. A server listed as trusted in the agent configuration remains trusted after the author pushes a malicious update. The agent does not re-evaluate trust on update.
Snyk documented Clinejection on February 9, 2026: an attacker published a malicious version of a Cline plugin to npm. The package was live for 8 hours. Every agent that ran npx during that window received the malicious version. npx does not cache; it fetches fresh on every execution.
The rug pull timeline: install clean (trust established), use for weeks (trust reinforced), malicious update pushed. Trust persists because it is bound to the server name, not to the content. npx does not respect package-lock.json by default, and most MCP server registries do not support content-addressed pinning.
Three Incidents in Fourteen Months: The Blast Radius Is Already Real
LiteLLM/TeamPCP (March 2026, Datadog Security Labs): Attackers compromised Trivy, the security scanner inside LiteLLM's own CI/CD pipeline, to obtain maintainer credentials. They published poisoned versions 1.82.7 and 1.82.8 with a .pth file payload. Python .pth files execute on every interpreter startup without any explicit import. The payload targeted AWS, GCP, and Azure credentials plus SSH keys from AI infrastructure hosts. Versions were live for 40 minutes before PyPI quarantine. LiteLLM has 95 million monthly downloads.
Smithery.ai path traversal (June 2025, GitGuardian): Path traversal in the dockerBuildPath parameter exposed configuration files for 3,000+ hosted servers, including API keys and credentials in plaintext.
Clinejection (February 2026, Snyk): 8-hour window for a malicious Cline plugin on npm. Attack vector: the npx execution model fetches fresh on each run. No lock file protection.
The common thread: none of the three required exploiting the MCP protocol. All three used the existing trust and execution mechanisms as designed.
Why the npm Security Model Does Not Transfer
The npm supply chain defenses: code signing (Sigstore, npm provenance), reproducible builds, SBOM requirements, dependency audits (npm audit).
Code signing verifies that published code matches the author's signature at publish time. After a rug pull, the malicious version is also signed by the compromised author key. npm audit checks for known vulnerabilities in dependencies; it has no concept of prompt injection in a return value. SBOM lists what a package depends on; it does not constrain what a tool server reads from agent context during execution.
OWASP LLM03:2025 names tool plugins as a supply chain vector but does not distinguish rug pulls from context hijacking. Both require defenses the OWASP control list does not include. Stacklok (2026) identified that the npx execution model bypasses all local security tooling. Running a package directly from the registry without local installation means no SBOM, no audit, no lock file, no scan.
Controls That Correspond to the Actual Threat Model
For rug pulls: pin MCP servers to content hashes, not version strings. Run a private registry that holds verified snapshots. Do not use npx for production agent deployments; pre-install and pin with a lock file. Treat MCP server updates as code deployments: review diffs, require approval.
For context hijacking: never pass credentials in tool call context. A tool that needs an API key should fetch it from a secrets manager on each invocation, not receive it as a parameter. Isolate tool server processes with network policies: outbound connections should be limited to the APIs the tool is documented to call. Log what each tool server received as input, not just what it returned. Context-read exfiltration is only detectable if you have the input log.
For both vectors: treat the tool server as an untrusted third party. Apply the same model you use for any external API, not the trust you extend to internal components. The MAGO Intel tool (intel.mago.team) audits MCP server configurations and third-party tool registrations. It flags unsigned packages, known-malicious server fingerprints, and tool servers with documented outbound network activity before they run in production.
The attack surface for AI agent tooling is not poorly understood. It is a known problem the ecosystem has chosen not to solve yet. Every team running npx-installed MCP servers without containerization, version pinning, or tool output sanitization has accepted a risk profile they have not quantified. The incidents are not edge cases. They are the expected outcome of deploying a trust model designed for single-application use in a multi-party, multi-agent supply chain.
Top comments (0)