The complete guide to AI supply chain security — third-party model risks, plugin ecosystem threats, dependency poisoning, AI SBOM requirements, retrieval pipeline compromise, and the procurement controls that close each gap.
Software supply chain security — SolarWinds, Log4Shell, the npm package poisoning campaigns — established that the components your software depends on are attack surfaces with the same severity as your own code. AI supply chain security extends this principle to a new category of dependencies that traditional SBOM tools and dependency scanners were not designed to track: the foundation models you call via API, the fine-tuned models you download from model hubs, the plugins connected to your AI agents, and the document sources feeding your RAG pipelines. Each of these is a dependency. Each can be compromised. And the consequences of compromise are amplified by the same characteristic that makes AI systems powerful: they interpret and act on everything they receive.
A poisoned npm package can execute arbitrary code. A poisoned model or poisoned RAG document can execute arbitrary instructions — phrased in natural language, invisible to traditional security tools, and delivered through the system's own reasoning layer. This is why AI supply chain security requires AI-native controls rather than extensions of traditional dependency scanning. The RAG pipeline security controls that directly address supply chain risks at the retrieval layer: RAG Security: Complete Guide to Securing Retrieval Systems →
Every model API call is a supply chain dependency. When AIZA-HexTyx calls claude-sonnet-4-20250514 for the AXIOM analyst, the LLM evaluator, and the mutation engine, Anthropic's model is a third-party dependency in the AI supply chain. The controls required: version pinning (model string specifies exact version — a silent model upgrade can change security properties), DPA/no-training attestation (see the SOC2 guide for required contractual controls), and re-testing on version upgrade (model version change triggers full HexTyx scan, same as any dependency upgrade).
For open-source models downloaded from model hubs (HuggingFace, Ollama library, etc.), the risks are more severe: no DPA, no training data attestation, and the possibility of hidden backdoors in model weights — trigger behaviors that produce normal output until a specific input activates a covert function. Before deploying any open-source model in production: verify the model's provenance chain (who published it, from what base model, with what fine-tuning data), test behavior consistency across a diverse input set, and run the full HexTyx adversarial scan against the deployed endpoint. Version-pin model weights by hash, not by name — model names on hubs can be reassigned to different weights.
The governance framework for third-party model risk: AI Agent Governance Framework: Complete 2026 Checklist →
AI agents connected to external tools inherit the security posture of every tool in their tool manifest. A plugin that has write access to a CRM, send capability on an email system, and query access to a database is a high-authority dependency. If the plugin itself is compromised — through a malicious update to a plugin registry, a supply chain attack on the plugin developer, or a dependency vulnerability in the plugin's own code — the attacker inherits the same tool access as the AI agent.
The specific supply chain vectors for plugins: malicious registry packages (an attacker publishes a package with the same name as a popular AI plugin package, capturing installations from teams who don't pin exact versions), dependency confusion attacks (a private internal plugin package name is registered in a public registry, causing builds to pull the attacker's version instead), and malicious updates to legitimate packages (a legitimate plugin developer's account is compromised and a backdoored update is pushed).
Controls: pin all plugin dependencies to exact version + hash, not semantic version ranges. Review all plugin update diffs before upgrading, same as reviewing application dependency diffs. Add every plugin to the AI System Inventory with its tool permissions, last review date, and the specific AIZA-HexTyx modules that test its security (tool_call_abuse, agentic_tool_abuse). Re-run those modules on every plugin version upgrade.
LangChain, LlamaIndex, AutoGen, CrewAI, and the other AI orchestration frameworks are themselves software dependencies with supply chain risk. These packages have broad API access, deep integration with AI model calls, and growing adoption — exactly the profile that attracts supply chain attackers. A malicious update to any of these frameworks could: exfiltrate prompts to an attacker's endpoint, modify model API calls to insert adversarial system instructions, disable injection detection, or silently log all AI interactions.
The defence is standard software supply chain hygiene applied specifically to AI framework dependencies: lock file pinning, hash verification, automated dependency scanning (Dependabot, Snyk) with alerting on AI framework packages specifically, and a review process for AI framework updates that includes behavioral testing against the deployed system after upgrade. The AI DevSecOps guide covers this in the context of the full development pipeline: Automated LLM Security Testing: The Complete 2026 Guide →
Every data source feeding a RAG knowledge base is a supply chain dependency. An attacker who can influence the content of any data source — a web crawler that indexes attacker-controlled pages, an email integration that processes attacker-sent messages, a document management system where any user can upload files — can plant adversarial content that executes when retrieved by the AI. This is supply chain attack at the data layer rather than the code layer.
The specific threat model: an attacker identifies that your AI indexes content from a particular data source (say, a public web domain that your crawler indexes, or a document upload feature with broad user access). They craft a document or webpage that contains adversarial instructions camouflaged as legitimate content. The document is ingested into the knowledge base. The adversarial content is retrieved in response to queries the attacker can predict. The AI executes the embedded instructions.
The controls at each pipeline stage — source allowlist, ingestion-time injection validation, provenance recording, Aegis CP2 chunk validation at augmentation — are detailed in the RAG pipeline security guide. Risk classification for systems with untrusted data sources: AI Risk Classification: The Complete Enterprise Governance Guide →
An AI Software Bill of Materials extends the traditional SBOM concept to cover all AI-specific dependencies. A complete AI SBOM has four layers traditional SBOMs lack:
Model layer: Every model API called (provider, model name, version string, DPA status, no-training attestation status, last security test date). Every open-source model deployed (hub URL, version hash, provenance chain, training data disclosure).
Plugin/tool layer: Every tool in every agent's tool manifest (tool name, version, tool permissions, last review date, last security test). Every external API the AI system calls (endpoint, authentication method, data classification of data sent).
Data source layer: Every content source feeding RAG pipelines (source name, source type, trust classification, last validation date, ingestion frequency). Every external dataset used for fine-tuning (provenance, data quality validation status).
Framework layer: All AI orchestration framework dependencies with pinned version hashes. All embedding library dependencies. All vector database client libraries.
The AI SBOM is maintained as a version-controlled document, updated on every dependency change, and reviewed quarterly as part of the risk classification cycle. It is the primary evidence artefact for DORA Arts. 28-30 third-party risk, EU AI Act Art. 9 risk management documentation, and SOC2 CC9.1 risk mitigation. Runtime governance that operates on top of the supply chain controls: AI Autonomous Agentic Runtime Governance: Complete Enterprise Control Guide →
Run the rag_poisoning, indirect_injection_advanced, and agentic_tool_abuse modules to test your three highest-risk supply chain attack surfaces — retrieval pipeline, plugin ecosystem, and agent tool access.
Test AI Supply Chain →