Agent supply-chain
security.

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.

This isn't hypothetical. The agent ecosystem has already logged real supply-chain incidents: malicious and vulnerable MCP servers, compromised publisher accounts pushing poisoned updates, and skills that quietly over-reached their stated purpose. The recurring pattern is exactly the two-lever failure — a component that shouldn't have been trusted (high p, no vetting) holding permissions it never needed (huge blast radius, no least-privilege).

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.