AI security has a visibility problem.
Most enterprises know which AI models they use. Far fewer can confidently say what sits underneath those models, where the training data came from, which libraries are involved, what APIs are connected, or what a third-party tool can actually access.
That gap is becoming harder to ignore. The World Economic Forum found that 87% of respondents identified AI-related vulnerabilities as the fastest-growing cyber risk over the course of 2025.
The shift is significant. Securing AI is no longer just about protecting the application or the code written by an internal development team. It means securing everything the system inherits and everything it can reach. That takes traditional DevSecOps thinking into a much messier environment where models, data, APIs, agents and external services can all become part of the attack surface.
What Makes the AI Supply Chain Different?
The AI supply chain is the collection of external and internal components an AI system depends on to operate. That includes models, training data, APIs, libraries, software tools, infrastructure and third-party services.
At first glance, this sounds a lot like the software supply chain. There is a major difference, though.
A traditional application might depend on a library to perform a defined function. An AI system can depend on a model that generates decisions, an external dataset that influences those decisions, or an agent that can act on the output. The dependency is no longer always passive.
Microsoft’s guidance on AI security says that AI supply-chain attacks hit parts that an AI system uses from outside. It is not only the main model. These outside parts can include open-source models, code libraries, pre-trained weights, outside data sets, and things used to fine-tune a model.
This creates five areas enterprises need to watch closely. Data can be manipulated. Models can be compromised. APIs can open paths into other systems. Open-source components can introduce hidden weaknesses. Third-party vendors can bring risks into the environment without the enterprise directly owning the underlying infrastructure.
And then there is the newer layer of agents and tools. They make the chain even harder to map because an AI system can now decide which service or tool to interact with during execution.
Also Read: How Enterprises Are Building Identity and Guardrails for AI Agents in Production
Unpacking the 5 Core Risks in AI Dependencies
The easiest mistake to make with AI supply chain security is to think about dependencies as a checklist. Model approved. Library approved. API approved. Done.
It doesn’t work that way.
The risk changes depending on what each component can influence.
Data Poisoning and Manipulation
Data is one of the least visible parts of an AI supply chain and potentially one of the most consequential.
Training and fine-tuning datasets shape how a model responds. If an attacker manages to alter that data, the compromise may not look like a conventional breach. There may be no obvious malicious executable or suspicious login. Instead, the model gradually learns something it should not have learned.
That makes data provenance important. Teams need to know where datasets came from, who changed them, what was added, and whether the data went through proper validation before being used for training or fine-tuning.
The uncomfortable part is that a poisoned dataset can produce a problem long after the original compromise happened.
Vulnerabilities in Open-Source AI Models
Open-source AI has made experimentation dramatically easier. It has also made it easier to bring unknown components into an enterprise environment.
A developer can download a pre-trained model, add a library, connect an SDK and get a working prototype running quickly. Security teams may only discover those dependencies much later.
Microsoft warns about scenarios where organizations download pre-trained models for internal fine-tuning and unknowingly integrate models that have been tampered with through malicious weights or backdoors.
Model provenance therefore matters as much as model performance. A model that scores well in testing is not automatically a model that deserves to be trusted.
The same applies to model files and their supporting packages. Unsafe serialization formats and malicious dependencies can create another route into the environment.
API and Prompt Injection Risks
APIs are what make modern AI applications useful. They are also what make them dangerous when trust boundaries are poorly defined.
A third-party LLM API might process company information. Another service may retrieve data from an internal system. An AI application may then pass the response into another tool.
Now introduce a prompt injection.
The attacker does not necessarily need to break the model itself. They may only need to influence what the model sees or what it does with the information it receives.
That can lead to sensitive information being exposed, an unauthorized command being attempted, or an AI workflow interacting with a service it should never have touched.
Shadow AI and Open-Source Components
There is another problem security teams cannot solve with a firewall.
They need to know what developers are actually using.
Employees and development teams can adopt AI agents, SDKs, libraries and models outside formal procurement or security processes. These tools can then become part of applications before anyone has assessed their provenance or permissions.
Google Threat Intelligence reported in May 2026 that attackers were increasingly targeting AI orchestration layers around frontier models. The targets included open-source wrapper libraries, API connectors, skill configuration files, autonomous skills and third-party data connectors.
Google also observed malicious logic being embedded into integration libraries and trojanized configuration files being used to gain access to production AI environments.
That changes the security conversation. The model might be perfectly legitimate. The problem could be sitting beside it.
Third-Party Vendor Compromise
An enterprise can secure its own environment and still inherit risk from somewhere else.
AI SaaS providers, model providers, data suppliers and other vendors may have access to company information or connect directly into enterprise workflows. If one of those providers is compromised, the customer can end up dealing with the consequences.
Vendor questionnaires alone are not enough.
Security teams need to understand what a provider can access, which systems it connects to, what data passes through it, what permissions it requires and what happens when one of its dependencies is compromised.
The supply chain is only as strong as the trust placed in its weakest critical dependency.
How Enterprises Can Protect Their AI Supply Chain
The answer is not to stop using external models, APIs or open-source software. That would defeat much of the reason enterprises are adopting AI in the first place.
The better approach is to make those dependencies visible and controllable.
Generate and Enforce an AI-BOM
An AI Bill of Materials gives security teams an inventory of what actually makes an AI system work.
That inventory can include models, datasets, libraries, SDKs, APIs, agents, tools and infrastructure components. More importantly, it should show how those pieces connect.
Google Cloud introduced an open-source Kubernetes controller that continuously monitors environments for AI runtimes such as vLLM and Triton and generates CycloneDX Machine Learning Bills of Materials.
There is a practical reason this matters. Google also notes that unregistered shadow AI workloads can evade traditional security scanners.
An AI-BOM therefore should not become another document created for an audit and forgotten afterward. It should help security teams answer basic questions quickly. What are we running? Where did it come from? What does it depend on? Who owns it? What happens if that component becomes compromised?
Without those answers, security teams are operating with partial visibility.
Shift Left with Deterministic Scanning
Security testing needs to happen before an AI component reaches production.
Models, SDKs, dependencies, configuration files and MCP servers should be examined during development and CI/CD. The earlier a compromised or suspicious component is identified, the fewer downstream systems have to be investigated.
This is where AI security starts borrowing heavily from mature DevSecOps practices.
But simply scanning for known software vulnerabilities is not enough. AI environments need visibility into the components specific to AI workloads and the relationships between them.
The principle is straightforward. Don’t wait for production behavior to reveal that a dependency should never have been there.
Shield Right with AI Runtime Security
Pre-production controls will catch a lot. They will not catch everything.
Production environments change. Developers add tools. Models get updated. APIs evolve. Agents gain new capabilities. New data sources get connected.
AWS highlights an important limitation here. Agents can invoke tools, fetch external data and communicate with other systems outside the model boundary. Model-level guardrails therefore do not automatically protect those interactions.
This is where runtime security earns its place.
Enterprises need to intercept sensitive API interactions, watch for unusual model and agent behavior, control access to external tools and detect attempts to move sensitive information outside approved channels.
The model boundary is not the system boundary. Treating it as one is an architectural mistake.
Practice Continuous AI Red Teaming
An AI system can pass a security test today and still become vulnerable tomorrow.
A new model version can change behavior. A new API can create another access path. A new tool can give an agent additional permissions. A seemingly harmless configuration change can alter how the system responds to an attack.
Red teaming should therefore continue after deployment.
Teams should test for prompt injection, data leakage, model manipulation, unsafe tool use, excessive permissions and unexpected agent behavior. They should also test the dependencies around the model rather than focusing exclusively on model responses.
The goal is not to prove that the system cannot be attacked. That is an impossible standard.
The goal is to find the failure paths while the organization still has time to close them.
Aligning AI Security with Global Compliance Frameworks
AI supply chain security increasingly sits at the intersection of engineering and governance.
The OWASP LLM Top 10 provides a useful lens for application-level risks such as prompt injection, supply-chain vulnerabilities, and data and model poisoning. The NIST AI Risk Management Framework provides a broader approach to identifying, assessing, managing and governing AI risks throughout the lifecycle. The EU AI Act adds regulatory requirements for applicable AI systems around areas such as risk management, documentation, transparency and security.
The useful part is not treating these frameworks as three separate compliance exercises.
Their value becomes clearer when security controls connect to them. An AI-BOM creates visibility. Dependency scanning provides preventive controls. Runtime monitoring creates evidence of ongoing oversight. Red teaming provides another layer of testing and validation.
That connection also changes how leadership should view AI security. It is no longer just a technical team’s responsibility. Once AI touches sensitive data, business processes or external systems, the supply chain becomes part of enterprise risk management.
Securing the Future of AI Innovation
AI supply chain security will become harder, not easier, as enterprises add more models, agents, APIs and third-party services.
The biggest mistake would be assuming that a trusted model automatically creates a trusted AI system. It doesn’t. A model can sit on top of compromised software, questionable data, exposed APIs or an agent with more access than it actually needs.
That is where zero trust becomes more than a security slogan. Every dependency needs to earn trust through verification, monitoring and controlled access.
The sensible starting point is an audit of the AI assets already in use. Map the dependencies. Find the unmanaged ones. Identify what can access sensitive information or external systems. Then test those paths before someone else does.
AI innovation can move fast. Security cannot afford to remain blind to what makes that innovation possible.
