What is AI supply chain security?
By Identra · Updated
AI supply chain security protects an AI system against compromised, vulnerable or untrusted models, datasets, software, services and agent tools. It covers where those dependencies come from, how they change over time and what data or actions they can reach.
What does an AI supply chain attack look like?
Say a developer asks a coding assistant to add a PDF parser. The assistant suggests a package name that sounds right but does not belong to any real project. An attacker has already registered that name on npm. The developer approves the install.
This is slopsquatting. It works because people trust the AI's suggestion and the registry listing looks normal. OWASP's NPM security guidance covers the risk.
The package ships a postinstall script. The laptop has a GitHub token in the environment and an AWS profile in ~/.aws. Nothing stops the script from reading both and posting them to a server the attacker runs. Nobody has looked at the generated code yet.
Install new dependencies in a throwaway environment with no real credentials. Check that the package belongs to the project you meant. Then let it into the repo. Anywhere an assistant can install software, this belongs in coding agent security.
What is in the AI supply chain?
More than the model. Anything you build on, buy or let an agent load counts. That includes things an agent pulls in halfway through a task.
An AI bill of materials helps keep track. It only earns its keep when each entry points to a deployment and an owner who will act on a warning.
Models and datasets
- Example
- Weights downloaded from Hugging Face
- What to check
- Origin, license, file format and how the model loads
Hosted AI services
- Example
- A vendor's model API
- What to check
- Data handling, connected accounts and change notices
Packages
- Example
- An npm or PyPI library
- What to check
- Publisher, version, install scripts and what it pulls in
MCP servers and skills
- Example
- A server listed in ~/.cursor/mcp.json
- What to check
- Tool descriptions, bundled code and the access it asks for
Extensions
- Example
- A VS Code or Chrome extension
- What to check
- Publisher, permissions and ownership changes
Why is it different from a normal software supply chain?
Some AI dependencies are instructions. A skill file can tell an agent to run a script or upload a folder. An MCP tool description can try to steer the agent, which is MCP tool poisoning. There may be no executable code at all. Whether it works depends on how the agent behaves and what it is allowed to do.
Model files can carry code too. A model saved in Python's pickle format can run code when it loads. Tampered training data changes behavior downstream. OWASP's AI supply chain guidance covers vulnerable and tampered models along with outdated packages.
Trust also decays. A maintainer account gets phished. An extension changes hands and the next update asks for more permissions. A hosted model can change behind the same API name.
How much damage can a bad dependency do?
As much as the process running it can reach. The same MCP server is a small problem inside a scratch project folder and a big one on a laptop signed in to production. A connected AI service can reach company data through an existing OAuth grant without installing anything.
For each component, write down who owns it, what identity it runs as and what it can touch. Review OAuth app risk for connected services. Apply least privilege to agents and service accounts.
Approving a vendor and approving its access are two decisions. Make them separately.
How do you reduce AI supply chain risk?
Put the checks where things get installed and connected. An approved tools list on a wiki does nothing if the install path ignores it. Start with components that run code, read sensitive data or touch production.
- Record source, publisher, version, owner and deployments for each dependency, including ones agents load at runtime.
- Verify signatures and provenance where they exist. They show origin. They do not show safe behavior.
- Pin reviewed versions. Look at updates before they roll out widely.
- Read skill instructions, tool descriptions and install scripts before first use.
- Run tests without real credentials and with outbound network access blocked.
What should you do when a dependency is compromised?
Find every project, device and account that used it. Disable it or pause the workflow. Save logs and artifacts before you rebuild anything.
Assume anything it could reach is exposed. Revoke the OAuth grants and rotate the tokens. Check commits and data access made under those identities. Uninstalling the package does not take back a stolen token.
Rebuild from a reviewed version and test before turning the workflow back on.
How Identra thinks about it
On managed macOS and Windows devices, Identra inventories the AI supply chain people actually run: MCP servers, agent skills, plugins, IDE extensions and packages. It flags AI tools that hide what they do. In the browser it finds every installed extension, and risky ones can be disabled by policy. For connected services, it shows which apps can reach company data, and an analyst can revoke a risky OAuth grant with the result recorded.
Go deeper: AI security, built on identity
Frequently asked questions
How is AI supply chain security different from software supply chain security?
It extends the same practice to models, datasets, hosted AI services and agent instructions. Some of those change system behavior without containing any code.
Does an approved AI app make its plugins safe?
No. Each plugin, MCP server, skill and connected service is its own trust and access decision. Review it on its own and again when it changes.
Is slopsquatting the same as typosquatting?
No. Typosquatting relies on misspellings of real package names. Slopsquatting registers names that AI tools invent and recommend.
Is an AI bill of materials enough?
No. It tells you what you have. Provenance checks, testing, permission reviews and an update process tell you whether it is safe.
Does using a hosted model remove supply chain risk?
It moves some of it to the provider. You still own vendor review, configuration, connected tools and access grants. Ask the provider how they announce model changes and handle incidents.