Your Agent's Tools Are a Supply Chain Now
A tool called postmark-mcp did its job for fifteen releases. It sent email. Developers installed it, wired it into their agents, and moved on. Then version 1.0.16 shipped with one extra line. Every email the agent sent was silently copied to an address the author controlled. Koi Security caught it on September 25, 2025, and called it the first real-world malicious MCP server (Koi Security, 2025). By then the package was pulling roughly 1,500 downloads a week, and the researchers estimated it was leaking somewhere between 3,000 and 15,000 emails a day.
Nobody was phished. No prompt was injected. The agent was compromised because a tool it already trusted turned malicious in a routine update. That is a supply-chain attack, and in 2026 it is the threat model most teams are not defending. The runtime coverage everyone has read is real, but it is a different problem with a different fix. This post separates the two, maps the classic npm attacks onto MCP, and hands you an install-time checklist you can apply this week.
Key Takeaways
- Your agent’s tool list is a dependency manifest. Every MCP server, skill, and plugin is third-party code you install and hand to an autonomous agent. MCP grew from roughly 100,000 SDK downloads a month at launch to about 97 million a month, with 10,000+ active public servers (Digital Applied; PulseMCP, 2026).
- Supply-chain poisoning and prompt injection are different threat models. Injection enters at runtime and is fought at execution. Poisoning enters at install or build time and is fought with allowlists, pinning, and least privilege.
- The rug-pull is real. postmark-mcp shipped 15 clean releases, then one line in v1.0.16 exfiltrated email (Koi Security, 2025). Fifteen clean releases is the point. It defeats a one-time review.
- The agent cannot tell a poisoned tool description from a real order. The MCPTox benchmark measured a 72.8% peak attack success rate and under 3% refusal across 20 models (arXiv:2508.14925, 2025).
- You fix it at install time, not runtime. Allowlist publishers, kill “allow all,” pin versions and hashes, least-privilege each agent’s tools, and scan.
What is an agent tool supply chain, and why does it matter now?
An agent tool supply chain is the full set of third-party MCP servers, skills, and plugins your agent installs and executes on your behalf. It matters now because that set stopped being small. By widely-cited tallies, MCP grew from roughly 100,000 SDK downloads a month at its late-2024 launch to about 97 million a month by early 2026, and public trackers now list more than 10,000 active servers (Digital Applied, 2026; PulseMCP, 2026). That is not a novelty ecosystem anymore. It is a dependency graph.
Here is what each piece actually is. An MCP server is a process that exposes tools to your agent over a protocol. A skill is a bundle of instructions and helpers the agent loads on demand. A plugin packages both. In every case, the thing you install is code and natural-language instructions that run inside your agent’s trust boundary. When you build and run your own MCP server, you control that code. When you install someone else’s, you have adopted a dependency, and skills load into the agent’s context the same way whether you wrote them or a stranger did.
The distribution changed too. In June 2026, Claude Code shipped a community tool marketplace, with plugins that had “passed automated validation and safety screening” (SitePoint, 2026). A marketplace is a discovery surface. It is also an attack surface. “Passed automated validation” is exactly the assurance npm and PyPI offered a decade ago, right up until it wasn’t. This is the same lesson those registries learned the hard way, arriving for agents on schedule.
Citation capsule: The agent tool ecosystem is now a first-class supply chain, not a novelty. MCP SDK downloads grew from roughly 100,000 a month at launch to about 97 million a month, with 10,000+ active public servers (Digital Applied; PulseMCP, 2026). Every server, skill, and plugin is third-party code your agent installs and executes on your behalf.
Supply-chain poisoning and prompt injection are different threat models
They enter at different times and you stop them in different places. Prompt injection is a runtime attack. It arrives inside content your agent reads while it works: a web page, an email, a returned API payload. Supply-chain poisoning is an install or build-time attack. It arrives inside a tool you deliberately chose, installed, and told the agent to trust. Same ecosystem, opposite ends of the timeline.
That timing decides the defense. You fight injection at execution. You break the lethal trifecta so no single agent holds private data, untrusted input, and an exfiltration path at once. You sandbox the agent at execution time. You filter egress. Those controls work because the malicious instruction is riding in on untrusted data, and you can quarantine untrusted data. But none of them help against a tool you installed on purpose. An egress filter does not fire on a “legitimate” email tool sending email. A sandbox happily runs the code you asked it to run.
Supply-chain poisoning inverts every assumption. The malicious code is not untrusted input the agent stumbled onto. It is a trusted dependency you mounted yourself. So the defenses move earlier, to the moment of install and build: allowlist the publisher, pin the exact version and hash, verify provenance, and give the tool the narrowest permissions that let it work. Prompt injection has been OWASP’s number one LLM application risk since the list began, and it is real (OWASP GenAI, 2025). It is just not this problem. Knowing which runtime defenses actually work does nothing for you if the tool itself is the attacker.
Citation capsule: Supply-chain poisoning and prompt injection are distinct threat models with distinct mitigation surfaces. Injection is a runtime attack defended at execution (trifecta break, sandbox, egress filter). Poisoning is an install or build-time attack defended by allowlists, pinning, and least privilege. Prompt injection is OWASP’s number one LLM application risk (OWASP GenAI, 2025), but a runtime control cannot stop a tool you installed on purpose.
What does a real MCP rug-pull look like?
It looks like patience. postmark-mcp cloned a legitimate email tool and shipped fifteen clean, working releases. Then version 1.0.16 added a single line that BCC’d every outbound message to a domain the author controlled, phan@giftshop[.]club (Koi Security, 2025). The tool kept doing exactly what it advertised. It just did one more thing on the side, and the agents using it never noticed.
The fifteen clean releases are not incidental. They are the whole technique. A one-time security review of version 1.0.0 finds nothing wrong, because nothing is wrong yet. Trust accrues. Downloads climb to about 1,500 a week. Then the maintainer spends that trust in a single commit. This is the agent-era rug-pull: build a reputation on clean behavior, then cash it out in one update. Reviewing a package once, at adoption, is structurally blind to it.
Autonomy is the amplifier. A human runs an email tool a handful of times a day and might notice a stray recipient. An autonomous agent calls it hundreds of times, on a schedule, without a human reading each send. The Koi researchers estimated 3,000 to 15,000 emails a day flowing to the attacker before disclosure (The Hacker News, 2025). One line, multiplied by machine speed and machine indifference.
Citation capsule: A trusted MCP package can ship a clean history, then turn malicious in a single line. postmark-mcp shipped 15 clean releases before v1.0.16 added a silent BCC, exfiltrating an estimated 3,000 to 15,000 emails a day at roughly 1,500 weekly downloads (Koi Security, 2025). Fifteen clean releases is the technique, because it defeats a one-time review at adoption.
Why can’t the agent tell a poisoned tool description from a real order?
Because they live in the same place. A tool’s natural-language description sits in the agent’s context window right next to your actual instructions, and the model reads both as authoritative. Editing a description steers the agent about as well as rewriting its system prompt. The MCPTox benchmark put numbers on this: a 72.8% peak tool-poisoning attack success rate and a maximum refusal rate under 3%, across 45 live servers, 353 tools, 1,312 cases, and 20 models (arXiv:2508.14925, 2025).
This is the uncomfortable corollary of a design choice everyone already accepted: a tool’s description is part of the prompt. That is what makes MCP ergonomic. It is also what makes it poisonable. A malicious description does not need an exploit or a memory-corruption bug. It just needs to read like an instruction, because to the model it is one. Microsoft’s June 2026 guidance describes exactly this: poisoned tool descriptions, sometimes dressed up as harmless “formatting notes,” that carry a hidden order, and it recommends applying “least agency, not just least privilege” (Microsoft Security, 2026).
There is a twist worth sitting with. By construction, a model that follows instructions more reliably will also follow a poisoned description more reliably, because to the model the description is just another instruction. Capability and obedience are the same axis here. That is why the fix cannot be “use a smarter model.” The description is trusted input by design, so the control has to sit upstream, at the moment you decide to mount the tool at all.
Citation capsule: The agent cannot distinguish an honest tool description from a poisoned one, because both live in the same context and both read as instructions. The MCPTox benchmark measured a 72.8% peak tool-poisoning attack success rate with a maximum refusal rate under 3%, across 45 servers, 353 tools, and 20 models (arXiv:2508.14925, 2025). More capable, better-instructed models can be more exposed, not less.
The exposed attack surface is already vast
Large, and mostly unlocked. Trend Micro found 492 MCP servers reachable on the public internet with no authentication or encryption in July 2025, exposing 1,402 tools, more than 90% of which granted direct read access to the backing data source (Trend Micro, 2025). Censys, scanning later, counted 12,520 internet-accessible MCP services as of April 2026, with roughly four in ten remote servers exposing tools behind no credential check at all (Censys, 2026).
Then there is the marketplace angle, which is where postmark stops being a one-off. Security researchers documented a campaign, later named ClawHavoc, that seeded 1,184 malicious skills onto the ClawHub marketplace for the open-source agent OpenClaw, uploaded through 12 accounts, one of which pushed 677 by itself (CyberSecurityNews, on Antiy CERT analysis, 2026). Reported counts vary across write-ups, but the shape is consistent: a single actor can flood a skills marketplace faster than humans can review it. That is the industrialized version of the rug-pull, and it lands on the exact “passed automated validation” surface that marketplaces advertise.
The CVE curve tells the same story. The named flaws are not toy bugs: CVE-2025-6514 was a critical remote-code-execution hole in a widely used client, and Cursor’s “MCPoison” (CVE-2025-54132) let a modified MCP config execute silently. They are not isolated either. One 2026 roundup counted more than 30 MCP-related CVEs filed in a single 60-day window (Practical DevSecOps, 2026). This is the broader 2026 CVE surge showing up specifically in the tool layer.
Citation capsule: The exposed and poisoned MCP surface is already large and largely unauthenticated. Trend Micro found 492 zero-auth servers exposing 1,402 tools (Trend Micro, 2025), Censys counted 12,520 internet-accessible MCP services (Censys, 2026), and the ClawHavoc campaign seeded 1,184 malicious skills onto a single marketplace (Antiy CERT, 2026).
The npm analogy: why the rug-pull is the new dependency confusion
Everything happening to MCP already happened to npm. CVE-2025-6514, a critical command-injection flaw in the mcp-remote client, sat in a package that had been downloaded more than 437,000 times before JFrog disclosed it (JFrog, 2025; NVD). That is the agent-era version of a transitive dependency shipping a critical vuln to everyone who ever ran npm install. The distribution mechanics are identical, which is good news, because the defenses transfer too.
The mapping is close to one-to-one.
| Classic npm / PyPI attack | MCP equivalent | Confirmed instance |
|---|---|---|
| Typosquatting | A lookalike server or skill name installed by mistake | Pattern: the standard registry risk |
| Dependency confusion | A public server shadowing an internal name | Pattern: the agent resolves the attacker’s copy |
| Maintainer takeover (rug-pull) | A clean release history, then a malicious update | postmark-mcp v1.0.16 (Koi Security, 2025) |
| Transitive critical vuln | A widely-installed client ships an RCE | mcp-remote, CVE-2025-6514 (JFrog, 2025) |
| Registry flooding | Bulk-uploaded malicious packages | ClawHavoc, 1,184 skills (Antiy CERT, 2026) |
Build provenance is the control you would already demand from a critical npm dependency, so demand it here. For typosquatting and dependency confusion, the named MCP incidents are not public yet, but the mechanics are identical, and the defense is the same lockfile you already run.
The uncomfortable part is that we know how to defend this. We built lockfiles, package signing, provenance attestations, and allowlists for exactly these attacks in the JavaScript and Python ecosystems. The agent ecosystem is speed-running the same failure modes and, for now, mostly without the same controls turned on. The fix is not to invent new security. It is to apply the old security to a new manifest, and to notice that the manifest is your agent’s tool list.
Citation capsule: MCP is repeating npm’s supply-chain attack playbook. mcp-remote (CVE-2025-6514, a critical RCE) had been downloaded 437,000+ times before disclosure (JFrog, 2025). Typosquatting, dependency confusion, and maintainer takeover all map cleanly onto MCP servers, which means the lockfile-and-provenance defenses transfer too.
How do you defend the supply chain?
You fix this at install time, not runtime. The controls are the boring ones that worked for package registries, applied to the tool list. Keep an approved-publisher allowlist. Turn off blanket “allow all” auto-approval. Pin every tool to an exact version and hash, and treat any version bump as a fresh review. Give each agent only the specific tools that agent needs. Re-approve when a tool’s description changes, not just its code. And scan the whole set with a supply-chain scanner. Tencent’s open-source AI-Infra-Guard ships more than 1,400 vulnerability rules across 75+ AI components and can audit an MCP deployment for known issues (arXiv:2606.31227; GitHub, 2026).
Each control maps to a specific incident. Pinning versions and hashes is what stops the rug-pull: postmark’s v1.0.16 would never have been auto-adopted if v1.0.4 was pinned and a bump forced a re-review. A publisher allowlist is what keeps a flood of ClawHavoc-style skills out, because an unknown uploader never clears the gate. Least privilege is what turns a poisoned description from a breach into a nuisance, since a tool with no email access cannot BCC anything. Provenance is what defeats typosquats and dependency confusion, because the wrong publisher fails the check before the agent ever loads it.
I ran this on my own setup, and it is a five-minute exercise worth doing before you finish this paragraph. Count the tools mounted in your agent. Mark which are first-party (code you wrote or run yourself, like a code-intelligence MCP server for your own repo) and which are third-party. For each third-party one, check three things: is it pinned to an exact version, is it running with “allow all,” and does any agent actually use it. In my case the first-party daemon was fine. The third-party skills and servers were the ones I had never pinned, and two of them were mounted on agents that had no reason to call them. Pinning them and trimming the mount list took less time than reading their changelogs would have. That is the whole point: this is cheap, and few teams have done it yet.
Citation capsule: Supply-chain risk is fixed at install or build time. Allowlist publishers, disable “allow all,” pin exact versions and hashes, least-privilege each agent’s tools, re-review on any change, and scan. Tencent’s open-source AI-Infra-Guard ships 1,400+ vulnerability rules across 75+ AI components for auditing MCP deployments (arXiv:2606.31227; GitHub, 2026). Each control maps to a specific 2025-2026 incident it would have stopped.
FAQ
Is it safe to install community MCP servers or skills?
Only with the same care you would give any npm dependency. Community tools are third-party code running inside your agent’s trust boundary, and marketplaces get flooded: the ClawHavoc campaign seeded 1,184 malicious skills onto a single marketplace through 12 accounts (Antiy CERT, 2026). Safe means provenance-checked, version-pinned, and least-privileged, not “it passed automated validation.”
What is MCP tool poisoning?
MCP tool poisoning hides malicious instructions inside a tool’s natural-language description, which the agent reads as trusted context alongside your real orders. Because the model cannot tell the two apart, the poisoned description steers it. The MCPTox benchmark measured a 72.8% peak attack success rate and under 3% refusal across 20 models (arXiv:2508.14925, 2025).
How is this different from prompt injection?
Prompt injection is a runtime attack that rides in on untrusted content the agent reads, and you defend it at execution with trifecta breaking and sandboxing. Supply-chain poisoning is an install or build-time attack on the tools themselves, and you defend it with allowlists, pinning, and least privilege. Different entry point, different fix, same ecosystem (OWASP GenAI, 2025).
How do I vet a third-party MCP server before installing it?
Check the publisher against an allowlist, pin the exact version and hash, read the tool descriptions the way you would read code, scope its permissions to the minimum, and scan it. A single blocked control is often enough: an unknown publisher fails the allowlist, and a version bump forces a re-review before it can auto-update (Tencent AI-Infra-Guard, 2026).
Conclusion
Your agent’s tool list is a dependency manifest, and in 2026 it is one you probably have not audited. The threat that matters most is not a clever prompt injection sneaking past your egress filter. It is a tool you installed on purpose, from a maintainer you trusted, turning malicious in a routine update. postmark-mcp proved the pattern with fifteen clean releases and one line. The marketplaces now shipping into every agent make that pattern repeatable at scale.
So treat supply-chain poisoning as its own threat model, separate from the runtime injection problem, with its own defenses at its own point in time. You cannot filter your way out of a tool you trusted, but you can gate it before it ever mounts. Keep an allowlist, kill “allow all,” pin versions and hashes, least-privilege every agent, and scan the set. Then do the five-minute audit today: count your third-party tools, pin them, and drop the ones no agent actually calls. Pair that install-time discipline with the runtime defenses that actually work, and you have covered both ends of the timeline. The rug-pull is the new dependency confusion. You already know how to stop dependency confusion.
Sources
- Koi Security, postmark-mcp: A Malicious MCP Server Backdoor for Email Theft, retrieved 2026-07-16.
- The Hacker News, First Malicious MCP Server Found Stealing Emails, retrieved 2026-07-16.
- Microsoft Security Blog, Securing AI agents as tools move from reading to acting, retrieved 2026-07-16.
- Wang et al., MCPTox: Benchmarking Tool-Poisoning Attacks on MCP, arXiv:2508.14925, retrieved 2026-07-16.
- Trend Micro, MCP Security: Exposed Servers Are Backdoors to Your Private Data, retrieved 2026-07-16.
- Censys, MCP Servers on the Internet, retrieved 2026-07-16.
- CyberSecurityNews (on Antiy CERT analysis), ClawHavoc: Poisoned Skills on OpenClaw’s ClawHub, retrieved 2026-07-16.
- eSecurityPlanet, Hundreds of Malicious Skills Found in OpenClaw’s ClawHub, retrieved 2026-07-16.
- CNBC, OpenClaw: the open-source AI agent’s rise and controversy, retrieved 2026-07-16.
- JFrog, CVE-2025-6514: Critical mcp-remote RCE Vulnerability, retrieved 2026-07-16.
- NVD, CVE-2025-6514, retrieved 2026-07-16.
- Practical DevSecOps, MCP Security Statistics 2026 Report, retrieved 2026-07-16.
- OWASP GenAI, OWASP Top 10 for LLM Applications: LLM01 Prompt Injection, retrieved 2026-07-16.
- Digital Applied, MCP Adoption Statistics 2026, retrieved 2026-07-16.
- PulseMCP, MCP Statistics, retrieved 2026-07-16.
- Tencent, Securing the AI Agent: A Unified Framework for Multi-Layer Agent Red Teaming, arXiv:2606.31227, retrieved 2026-07-16.
- Tencent, AI-Infra-Guard (GitHub), retrieved 2026-07-16.
- SitePoint, Claude Code June 2026: 10 New Features Devs Need to Know, retrieved 2026-07-16.
If it was useful, pass it along.
