Supply Chain
- Tools & External Data
A compromised component — a poisoned base model, a malicious fine-tune, a tainted plugin or MCP server, or a compromised dataset — enters the system before or during deployment.
What it is
A large language model's supply chain reaches far beyond application code — the base model, any fine-tune or adapter merged onto it, the datasets behind each, and the plugins or MCP servers an agent loads at runtime are all external components an attacker can tamper with before an application ever runs. Open-access models, parameter-efficient fine-tuning methods like LoRA, and shared model-merge platforms lower the bar for introducing a compromised component into a chain no single team fully controls. An agentic system multiplies the entry points: every tool server, MCP integration, or third-party model an agent can reach at runtime is its own supply-chain dependency, and a single compromised link can silently corrupt every agent downstream of it.
Kinds
- Vulnerable or outdated components
- Unpatched third-party packages or model-development dependencies give an attacker a known exploit into the pipeline, with a higher blast radius when the dependency sits inside model development or fine-tuning.
- Tampered pre-trained models
- A model pulled from a public repository carries a hidden backdoor or bias introduced through direct parameter tampering or a poisoned training set — a binary black box that static inspection cannot catch.
- Vulnerable adapters & merges
- A malicious LoRA adapter or a compromised model-merge or format-conversion service injects a backdoor into an otherwise trustworthy base model at assembly time.
- Weak provenance
- Nothing verifies that a downloaded model or dataset actually came from the account it claims to — an attacker can compromise or impersonate a supplier account with no signature to catch it.
Attack scenarios
An agent loads a third-party MCP tool server from an unvetted registry that silently exfiltrates every tool call it proxies.
Compromised dependency
An attacker plants malware in a public package registry; a model-development environment installs it as an ordinary dependency, giving the attacker a foothold before the model is ever deployed.
Direct model tampering
An attacker edits a published model's parameters directly and republishes it under its original name, distributing misinformation through what looks like an unmodified, trusted model.
Malicious adapter merge
A compromised third-party adapter, once merged onto a production base model through a public model-merge service, gives the attacker a covert entry point that activates during ordinary operation.
Impersonated model release
After a popular open model is taken down, an attacker republishes a same-named version bundled with malware, trading on the model's prior reputation to reach victims who assume the name still means the same thing.
Mitigations
- Vet every source
- Vet data sources, model suppliers, and their terms and privacy policies before trusting them, and re-audit periodically — a supplier's security posture is not a one-time check.
- Track provenance with a signed inventory
- Maintain a signed bill of materials for every model, dataset, and dependency, and verify hashes on anything pulled from a repository — the same discipline a vetted Tool Registry enforces for agent-loaded tools.
- Scope what a loaded tool can reach
- Bind every tool or MCP server an agent loads to only the access its task requires, per Permission-scoped Tools, so a compromised dependency can't reach beyond its declared scope.
- Red-team and patch continuously
- Evaluate third-party models with adversarial red-teaming before adoption, and keep a patching policy for known-vulnerable components rather than treating integration as a one-time event.