MCP security & the
agent supply chain.

Prompt injection is a runtime attack — the threat rides in on data the agent reads while it works. Supply-chain risk is install-time — the threat is baked into a component you chose to add. That distinction changes everything about the defense. Injection abuses the agent's inputs; a malicious MCP server or skill abuses the agent's own trusted code path, with whatever permissions you granted it.

An MCP server can read files, hit the network, and call other tools the moment it's connected — no jailbreak required, because you already trusted it. So the controls are different: not input filtering, but vetting what you install, minimizing what you grant, and containing what it can reach. The next sections make each measurable.

Say each component you install has some independent probability p of being compromised (a backdoor, a hijacked publisher, a malicious update). The chance that at least one of your N installed components is bad is the complement of "all clean":

At p = 5% per component: 5 dependencies → ~23%, 20 → ~64%, 50 → ~92%. The risk isn't linear — it climbs toward certainty as you pile on skills.

This is why "do I actually need this skill?" is a security question, not just a tidiness one. Every MCP server and plugin you add is another independent chance for the chain to break. The cheapest supply-chain control in existence is installing less. The runnable model below plots the curve.

Dependency count sets the odds of compromise; permissions set the damage. The blast radius of a component is the set of capabilities it holds — if it's compromised, that's exactly what the attacker gets. A skill granted {read_files, write_files, network, exec, secrets} hands an attacker your whole machine; the same skill granted only {read_files} hands over almost nothing.

Give each component the narrowest capability set that still lets it do its job. Then even a fully compromised component is boxed into that scope — it can't touch secrets it was never granted.

Everything reduces to moving two numbers. Lower p (make compromise less likely) by vetting before install. Shrink the blast radius (make compromise less costly) by least-privilege and isolation.

Note the trap in the third row: an auto-updating component is one you re-install continuously, often without re-vetting. A benign skill can turn malicious in a version bump you never read. Pinning and reviewing updates is where a lot of real-world supply-chain compromise actually enters.

MCP adds one attack surface an ordinary package doesn't have: the tool description. A server's descriptions go straight into the model's context, and the model reads them as instructions. In April 2025 Invariant Labs described the core problem as instructions that are "invisible to users but visible to AI models," and named three attacks built on it.

A poisoned description, paraphrasing Invariant's proof of concept against Cursor. The user approves a calculator; the model reads a different contract.

Shadowing is why "we only call the trusted server" is no defense: every connected server's descriptions share one context window, so one bad server can steer calls to all the others. A rug pull is the auto-update trap from the vetting table, moved from code into prose.

This isn't hypothetical. Three incidents from 2025 cover the main ways in: a malicious MCP server, a vulnerable piece of MCP plumbing, and an ordinary npm package that turned the developer's own AI tools into its scouts.

The defensive lesson is boringly consistent with the rest of security engineering: treat installed agent components like any other third-party dependency in a production system. Inventory them, pin them, scope them, sandbox them, and review updates. The novelty of "AI agent" doesn't buy you an exception from software supply-chain hygiene. It raises the stakes, because these dependencies come with the ability to act.

Each incident above maps to a control you can deploy now. None of them is exotic. The work is applying them to agent components as strictly as you would to production dependencies.

Two of these deserve a second look. Least privilege couldn't have saved postmark-mcp's users, because the stolen capability, sending email, was the job they installed it for. Only the provenance lever, a lower p, would have helped. And the Nx payload needed no MCP server at all: it borrowed agents already installed on the machine, which makes the agent itself the newest kind of blast radius. Nx's own fix was on the provenance side too. It moved from long-lived npm tokens to npm Trusted Publishing over OIDC and added provenance checks.