AI supply chain risk
AI supply chain risk is the exposure an organization inherits from the external components its AI systems consume at runtime: the foundation model and its version, fine-tuning datasets, prompt templates, retrieval sources, agent tool definitions, MCP servers, and the vendors behind each one. A compromise in any of these components reaches production through normal operation, because the AI system ingests the component as trusted input.
Where the AI supply chain extends past software dependencies
The SBOM practice CISA codified for software covers packages, versions, and known CVEs. AI systems add components that carry no equivalent provenance record: model weights whose training data lineage is opaque, third-party prompt templates, retrieval corpora that change daily, and tool descriptions that enter the context window verbatim. A poisoned tool description executes as indirect prompt injection the moment an agent loads it, which is why OWASP places the pattern under LLM01 in the 2025 LLM Top 10. NIST AI RMF MAP 4.1 expects third-party AI components to be inventoried, and EU AI Act Article 11 expects the equivalent record inside a high-risk system's technical documentation.
How the risk surfaces in production traffic
A compromised component announces itself inside live AI traffic: instructions arriving through a retrieval source, a manipulated tool response steering an agent loop, a prompt template exfiltrating context. The request layer is where those manifestations become observable and attributable, which makes two artifacts the working countermeasures. An AI Bill of Materials names the components and versions a system depends on, and per-decision audit records name which of those components were active in each request, so an investigation can trace a bad outcome back to the component that introduced it.
Related reading
- AI Bill of Materials (AIBOM): The Inventory Layer Compliance Teams Keep Skipping
Search interest in "AIBOM" and "AI bill of materials" is climbing fast, but the SERP is owned by vendors selling tooling rather than explainer content. This article defines AIBOM in concrete terms, compares it to the Software Bill of Materials (SBOM), maps the artifact to NIST AI RMF and EU AI Act Article 11 documentation requirements, and walks through what an AIBOM actually contains: model card references, training data lineage, inference dependencies, and gateway policy version. The per-decision audit log of LLM traffic is the inference-layer AIBOM artifact most programs are missing.
- MCP Tool Poisoning Prevention: Gateway Controls for the Model Context Protocol Surface
Model Context Protocol tool poisoning is the agentic analog to supply-chain compromise. An MCP server presents a set of tools to an agent host; an attacker who controls the MCP server (or the tool definitions an MCP server advertises) can change what the tools do, what they return, or what parameters they accept. The agent loop calls the tool in good faith and the actions executed against downstream systems are the attacker'"'"'s. The prevention surface splits across MCP server selection, tool-definition pinning, and per-decision authorization at the agent-tool boundary. This article walks through the MCP poisoning patterns and the gateway controls that contain them.
- Prompt Injection via MCP Tool Descriptions: The Attack Surface in the Schema Itself
When a client connects to a Model Context Protocol server, the server advertises its tools to the model through descriptions. The model reads the descriptions to decide which tool to call. A malicious MCP server can place prompt-injection content in the tool descriptions themselves. The model treats the description as instructions, not as data. The attack surface lives inside the schema that the protocol uses to advertise its capabilities. This article walks the attack pattern, the variants that have surfaced, the detection signals, and the gateway controls that contain the blast radius.