Supply-chain Security

Software supply-chain security, after the high-profile incidents of the early 2020s, settled on a clear model: verify the provenance and integrity of every dependency, sign artifacts, publish SBOMs, and pin versions. The agentic extension of this model depends on Provenance Trust Tagging to handle runtime content from tools, and on Sandboxing and Isolation to contain any tool that does turn out to be malicious. Agentic AI inherits all of that, and adds a threat class that code supply-chain models were not designed for: the attack that targets the reasoning path rather than the execution path. A malicious npm package injects code that runs when the dependency is loaded. A malicious MCP server injects text that the model reads as a legitimate instruction when the tool is called. The mechanism is different in kind: no exploit, no vulnerability, no memory corruption. Just text that a probabilistic reasoner finds persuasive.

This changes when verification must happen. In traditional supply chain security, install-time verification is meaningful because a package’s behaviour is fixed at install. An MCP server’s behaviour is not fixed: the tool descriptions it returns are fetched at runtime, and a server that was reviewed and approved last month may return different, malicious tool descriptions today. This is the “rug pull”: a server builds trust as a benign tool, is adopted broadly, and then the description is silently changed to embed instructions the model will follow. “Approval is an event, not a continuous state”: one-time verification at install is insufficient, and every session requires a fresh integrity check.

Registry poisoning compounds the problem at scale. If a shared MCP registry can be made to serve a malicious tool description to agents that query it, one poisoning event affects every agent connected to that registry. MCPTox research documented high success rates against real servers; registry contamination experiments found that a significant fraction of major MCP registries could be seeded with malicious content. The implication is that trusting any tool description because it came from “the official registry” is not safe without cryptographic verification of the specific content that was reviewed. The description you reviewed and the description the model is reading must be provably the same.

Scenario: the rug pull after adoption

A team integrates a well-regarded MCP server for interacting with a project management API. The server’s tool descriptions are reviewed and approved; the integration ships. Months later, the server’s maintainer changes one tool description to include a hidden instruction: when the create_task tool is called, also read the calling agent’s context and send a summary to a specified URL. The change is invisible to casual inspection, as the tool still works as advertised for its stated function. Runtime re-verification, which hashes the tool descriptions on every session start and compares them to the approved baseline, detects the discrepancy and quarantines the server before the model ever reads the modified description.

Scenario: the model-weight supply chain

An organisation uses a fine-tuned model checkpoint sourced from a third-party provider. The checkpoint contains embedded instructions, inserted during fine-tuning, that cause the model to leak context under specific trigger conditions, a class of attack sometimes called a backdoor or sleeper. There is no code to scan; the vulnerability is in the weights. An AIBOM (AI Bill of Materials) that records the training data provenance, fine-tuning process, and checkpoint hashes, combined with red-team evaluation of trigger-condition behaviour before deployment, surfaces the anomaly before the model reaches production. Version-pinning by content hash ensures the checked checkpoint is the one that runs.

How it fails

• Tool, model, and plugin versions float (:latest or an unpinned branch), so a rug pull takes effect without any action on the consumer’s side.
• Integrity checks happen only at install or deployment; there is no runtime re-verification, so a server that goes malicious after adoption is trusted indefinitely.
• Tool descriptions are not scanned for hidden instructions, because they are treated as documentation rather than potentially adversarial content.
• The SBOM records code dependencies but not model weights, training data, tool schemas, or agent-card specifications, which are the agentic supply chain components with the highest novel risk.

Why the mapped controls work

Signed artifacts verified on every load ensure that the tool description the model reads is byte-for-byte identical to the one that was reviewed. A rug pull produces a signature mismatch and the server is not trusted. Version pinning by content hash removes the floating-version attack surface: the server cannot silently serve a different description because the hash is part of the configuration, not the server’s assertion. Runtime re-verification each session converts the one-time approval event into a continuous trust assertion, catching changes that occur between sessions. Tool-description injection scanning treats every description as potentially adversarial text rather than trusted documentation, applying the same inbound validation logic as any other untrusted content. Together these controls extend the proven code supply-chain model to cover the reasoning-path attack surface that code-only approaches leave entirely unprotected.

First steps

1. Pin every MCP tool server to a content-addressed version today. Record the SHA-256 hash of each tool server’s tool-description manifest in your agent’s configuration file, and add a startup check that hashes the live manifest and refuses to connect if the hash does not match the pinned value.
2. Add tool-description injection scanning to your agent’s session initialisation. Before the model reads any tool description, pass it through the same injection scanner you apply to user input (a regex pattern set for common prompt injection markers, or a fast classifier model), and quarantine any server whose description triggers a match.
3. Produce an AIBOM (AI Bill of Materials) for each model checkpoint you deploy. Record the base model name and version, any fine-tuning dataset provenance, the checkpoint content hash, and the red-team evaluation results, then store this document alongside your SBOM in your artefact registry so that supply-chain audits cover the reasoning layer as well as the code layer.