Permission scoping, execution sandboxing, prompt injection defense, and multi-agent trust boundaries all share an assumption: the agent's own tools are on its side, and the risk comes from untrusted content or an untrusted handoff flowing through them. Supply-chain trust is the case those don't cover — the tool itself is the untrusted party. A third-party MCP server, a skill package pulled from a registry, or a dependency an agent's generated code imports can act with exactly the permissions it was granted, with no need to manipulate the model at all. It doesn't have to be clever. It just has to do the thing it was already allowed to do.
Prompt injection defense is about untrusted *content* steering an otherwise-trustworthy agent into misusing its tools. Supply-chain risk skips that step: if the tool itself is malicious or compromised, it can exfiltrate data, modify files, or make network calls the moment it's invoked — using its own code, not the model's reasoning. A skill that shells out to a bundled script, or an MCP server that proxies to code you've never read, is an unaudited program running with the agent's access, and every prior guide's defenses (scoping the model's tool choices, sandboxing what the model executes, filtering what content reaches the model) do nothing to stop a tool that was simply built to misbehave.
Teams that would never run an unreviewed shell script from a stranger will install an MCP server or skill package with less scrutiny than a routine dependency bump, because it arrives through a chat interface instead of a package manager prompt. But the access is often broader: many agent tools request filesystem, network, or credential access by default, and the installation step itself may run setup code. Treat adding a new tool, skill, or MCP server as equivalent to adding a new production dependency with shell access — same review bar, same "who published this and can I verify it" questions, not a lighter one just because it was framed as an agent capability rather than a library.
| Risky pattern | Bounded equivalent |
|---|---|
| installing an MCP server or skill from an unverified publisher because it claims a useful capability | checking publisher identity, source repository, and install count/history before granting it any access |
| granting a new tool the same broad permissions as the agent's core toolset by default | scoping each tool's own permissions independently, no broader than the specific capability it provides |
| auto-updating tools/skills/MCP servers to whatever the publisher pushes next | pinning versions and reviewing diffs before upgrading, the same discipline as any other dependency |
| letting agent-generated code add and run its own new dependencies unreviewed | routing new dependency additions through the same review a human contributor's PR would get |
| trusting a tool because its description/docstring says it's safe | trusting a tool because its actual code or a reputable audit says it's safe — descriptions are unverified claims, same as any other untrusted text |
Tool and skill definitions typically include a natural-language description that tells the model when and how to use them. That description is text the publisher wrote, and the model reads it the same way it reads any other input — which means a malicious tool can use its own description as an injection vector, instructing the model to pass it sensitive data "for validation" or to call it in situations the user never intended. This is the supply-chain version of prompt injection: instead of untrusted content reaching the model through a file or web page, it arrives baked into the tool's own metadata, already inside the system before any task starts.
You can't verify a tool won't be misused just by reading what it claims to do, but you can check facts that don't depend on trusting the publisher: is the source public and readable, does it match what's actually installed, has it been stable across versions without scope creep, does its permission request match its stated purpose. A skill that asks for network access to "format text" or an MCP server whose published source doesn't match its installed behavior are answerable red flags — cheaper to check before granting access than to discover after.
The question to ask before adding any tool, skill, or MCP server: if this were a malicious package instead of a helpful one, what would it be able to do with the access I'm about to grant it, and would I notice? If the honest answer is "quite a lot, and probably not," that's a supply-chain gap, not a convenience.