What is AI supply chain security?
AI supply chain security is the practice of identifying, assessing, and controlling the third-party components, dependencies, models, packages, connectors, skills, plugins, MCP servers, datasets, and services that AI tools and AI-enabled workflows rely on.
It extends traditional software supply chain security into an environment where dependencies can be added dynamically and where AI agents may choose or invoke components during runtime rather than only during a controlled build process.
How does the AI supply chain differ from a traditional software supply chain?
Traditional software supply chain security is usually organized around a build pipeline. A package enters a repository, appears in a lock file or SBOM, passes through scanning, and eventually becomes part of a deployed application.
AI introduces dependencies that may never pass through that sequence. A user can connect an MCP server to an assistant in minutes. An agent can pull in a skill or plugin while working. A model can be downloaded from a public registry. A browser or IDE extension can add AI capabilities to an AI workflow without appearing in the application’s dependency manifest.
The security question becomes not only “what shipped with this application?” but also “what can this AI tool reach and trust right now?”
Common AI supply chain risks
- Compromised packages and extensions: A malicious or compromised package can execute inside a trusted development or agent workflow.
- MCP server risk: MCP servers can expose powerful tools, filesystem access, SaaS APIs, or internal systems, and a vulnerable or malicious server becomes a privileged bridge into those systems.
- Tool and skill poisoning: A component can manipulate an agent through malicious metadata, schemas, descriptions, or responses, causing the model to take actions the user did not intend.
- Model provenance and tampering: Organizations may download models or model artifacts without reliable lineage, integrity checks, or confidence about how they were modified.
- Dependency drift: A component that was safe when first reviewed can change later through an update, publisher compromise, ownership transfer, or new downstream dependency.
Pluto’s own MCP research illustrates the pattern directly, including CVEs against MCP servers, spanning findings such as MCPwnfluence (mcp-atlassian) and Vicious Circle (CircleCI’s MCP server).
What does a practical AI supply chain security program need?
Start with inventory. Security teams need to know which AI components are actually present, including local ones and those installed by employees.
Then add context. A connector with read-only access to public data is not the same risk as a skill that can read local credentials and write to a production system.
Useful controls include:
- inventorying AI supply chain components and owners
- rating components by permissions, provenance, vulnerabilities, and behavior
- maintaining allowlists or trusted catalogs for higher-risk components
- monitoring component updates and publisher changes
- restricting what untrusted components can reach
- detecting risky behavior at runtime rather than trusting a one-time review forever
FAQs
1. Is AI supply chain security the same as software supply chain security?
It builds on the same principles, but AI adds models, prompts, skills, MCP servers, connectors, extensions, and runtime-selected tools that may not appear in a traditional build manifest or SBOM.
2. What are the most common AI supply chain blind spots?
Components added outside the formal development pipeline, especially employee-installed extensions, skills, local MCP servers, and other runtime dependencies that security has not reviewed.
3. Does an AIBOM solve AI supply chain security?
An AIBOM can improve inventory and provenance, but inventory alone is not enough. Security also needs risk assessment, permission context, update monitoring, and runtime controls.
4. Why are MCP servers part of the AI supply chain?
They are third-party or internal components that give AI tools access to data and actions. A vulnerable, compromised, or overprivileged MCP server can expand the blast radius of an otherwise trusted agent, as Pluto’s own MCP research has repeatedly shown.