AI Supply Chain Risks: Threats, Examples & Best Practices

Key Takeaways

• AI supply chain risk extends well beyond traditional software dependencies — it includes models, datasets, embeddings, prompts, and agent behavior, not just code and packages.
• Every AI system depends on a chain of models, data, APIs, infrastructure, tools, vendors, and increasingly agents, many of which are outside the enterprise's direct control.
• Model and dataset provenance is what makes an incident investigable; without it, "what changed" is often unanswerable.
• Third-party model and vendor risk needs continuous reassessment, not a one-time procurement review — vendors change models, subprocessors, and behavior after the contract is signed.
• An AI-BOM (AI Bill of Materials) is the practical mechanism for turning "we think we know our AI dependencies" into an actual, auditable inventory.
• AI agents and MCP-connected tools convert supply chain risk from an information problem into an operational one, because a compromised or manipulated agent can take real actions, not just generate bad output.
• A vendor changing a model version, a system prompt, or a subprocessor is not a "harmless update" — it can silently change application behavior, accuracy, and even legal exposure.
• Effective protection requires inventory, provenance verification, least-privilege access, continuous monitoring, vendor governance, and a tested incident-response and rollback path — not a single control.

What Are AI Supply Chain Risks?

AI supply chain risks are the security, privacy, integrity, availability, compliance, and intellectual-property risks that an organization inherits from the components its AI systems depend on — datasets, models, model repositories, open-source frameworks, APIs, cloud and GPU infrastructure, vector databases, plugins, tools, AI agents, and the vendors that provide any of these. Unlike traditional software risk, which centers on code and packages, AI supply chain risk also covers behavioral dependencies: a model can change what it does — through a routine vendor update — without a single line of the enterprise's own code changing.

These risks fall into overlapping categories rather than one bucket: security risk (a compromised model or dependency), privacy risk (sensitive data reaching an external provider), integrity risk (tampered weights or poisoned training data), availability risk (a vendor outage or model deprecation), compliance risk (undocumented processing under GDPR or the EU AI Act), and intellectual-property risk (licensing terms attached to open-weight models or training data). An organization can be fully compliant with traditional software supply chain frameworks like SBOM and still have no visibility into its AI supply chain, because none of those frameworks were built to track a model's training data, its provenance, or its behavior after deployment.

What Is an AI Supply Chain?

An AI supply chain is the full set of upstream components an AI system depends on to function, from raw data through to the business process a user interacts with. Each layer can introduce risk that the enterprise did not create and often cannot fully inspect:

Data → Datasets → Models → Model repositories → Frameworks/libraries → Cloud/GPU infrastructure → Model/API providers → RAG/vector databases → Plugins/tools/MCP → AI agents → Enterprise application → Users/business processes

A vulnerability introduced at any layer — a poisoned dataset, a compromised framework, a malicious model upload, a manipulated retrieval source, a tool with excessive permissions — can propagate all the way to a business decision or a customer-facing output, even though every layer above the enterprise's own application sits outside its direct control.

AI Supply Chain vs Traditional Software Supply Chain

Google Cloud's Office of the CISO has argued that AI development is close enough to traditional software development that existing security practices should largely transfer — but with three specific differences that matter for how risk is modeled: AI relies heavily on data, creating unique security challenges around data provenance, poisoning, and versioning, while traditional software primarily relies on code, and version control for AI datasets is not as mature as that for traditional software code. AI models are also opaque — their behavior is shaped by weights that are difficult to manually inspect, unlike code that can be read and reviewed — and provenance carries more weight in AI because of the risks of data poisoning and model tampering.

AI Supply Chain Risk vs Third-Party Model Risk

Third-party model risk is one category inside the broader AI supply chain — not a synonym for it. AI supply chain risk covers the entire dependency ecosystem (data, models, infrastructure, plugins, agents, vendors); third-party model risk is specifically the risk introduced by using a model you did not train, whether via API or downloaded weights.

Types of AI Supply Chain Risks

Data poisoning — Manipulating training or fine-tuning data so the model learns a hidden, attacker-chosen behavior. Impact: degraded accuracy or a targeted backdoor triggered by specific inputs. Mitigation: source verification and anomaly detection on training data before it's used.

Model poisoning — Similar to data poisoning but targets the model artifact directly, often during fine-tuning or a supply-chain handoff. Mitigation: checksum and provenance verification before deployment.

Malicious or backdoored models — A model uploaded to a public repository that behaves normally in testing but executes hidden logic — including arbitrary code execution — on load. Documented as far back as 2023 and early 2024, these compromised models appeared safe but contained dangerous code that could steal data and install backdoors when downloaded. Mitigation: load only from verified, signed sources; scan artifacts before use.

Model tampering — Unauthorized modification of a deployed model's weights or configuration after release. Mitigation: cryptographic signing and integrity checks at load time.

Compromised model repositories — Public hubs (Hugging Face and similar) function as central distribution points, which makes them high-value targets, comparable to how npm and PyPI became targets in the software world. Mitigation: private mirroring of verified models for production use.

Open-source dependency vulnerabilities — ML frameworks and libraries (PyTorch, transformers, tokenizers, etc.) carry the same CVE risk as any open-source dependency, but are less consistently scanned by traditional SCA tooling. Mitigation: extend dependency scanning to ML-specific packages explicitly.

Third-party model/provider compromise — A breach at the model or API provider itself, which can expose prompts, outputs, or credentials flowing through that provider. Mitigation: contractual incident-notification commitments and architectural blast-radius limits.

API and infrastructure compromise — Compromise of the cloud, GPU, or inference infrastructure a model runs on. Mitigation: standard cloud security controls plus AI-specific logging.

RAG poisoning — Injecting malicious or misleading content into the document sources a retrieval-augmented system pulls from, so the model retrieves and repeats attacker-controlled text. Mitigation: source allow-listing and content validation before indexing.

Vector database poisoning — Manipulating embeddings or the vector store itself so poisoned content is retrieved preferentially. Mitigation: access controls and integrity monitoring on the vector store.

Prompt injection — Untrusted content (a document, email, webpage, or supplier record) contains instructions that override the system's intended behavior when the model processes it. Mitigation: treat all retrieved or user-supplied content as untrusted data, never as instructions.

Plugin/tool/MCP poisoning — A connected tool or MCP server is malicious, compromised, or granted more capability than the task requires, letting an attacker manipulate agent behavior through the tool layer. Mitigation: vet and scope every connected tool; apply least privilege.

AI agent supply-chain risk — Because agents can call tools, access systems, and take actions, a supply-chain compromise anywhere in an agent's toolchain becomes an operational risk, not just an output-quality risk. Mitigation: human approval gates for high-impact actions.

Credential exposure — API keys, database credentials, and service tokens embedded in AI-generated code or AI-tool configurations, often left in client-side code or default project settings. Mitigation: secrets management and automated scanning of AI-generated code before deployment.

Sensitive-data leakage — Enterprise data reaching an external AI tool without redaction, logging, or a data-processing agreement in place. Mitigation: pre-processing/anonymization before data reaches any external model.

Model update/version risk — A vendor changes model weights, routing, or safety behavior without the enterprise changing anything on its side, which can silently change application accuracy or behavior. Mitigation: version pinning where offered, change notifications, and regression testing after any vendor update.

Model behavioral drift — Gradual change in model outputs over time due to upstream retraining, routing changes, or fine-tuning by the provider. Mitigation: ongoing output monitoring against a fixed evaluation set.

Vendor/subprocessor risk — Risk introduced by the vendor's own downstream providers, which the enterprise usually cannot see directly. Mitigation: contractual subprocessor disclosure requirements.

Nth-party risk — Risk several layers removed from the direct vendor relationship (see below).

Concentration risk — Overexposure to a single provider, cloud, or model (see below).

Availability/outage risk — A vendor outage, rate-limit change, or model deprecation that breaks a production dependency with no fallback in place. Mitigation: fallback models or providers for critical paths.

Licensing/IP risk — Ambiguous or restrictive licensing on open-weight models, datasets, or generated output. Mitigation: legal review of license terms before production use.

Privacy/compliance risk — Processing personal data through an AI dependency without the safeguards required under applicable law. Mitigation: data-protection impact assessment before adoption.

Real-World AI Supply Chain Risk Examples

Vercel — compromised via a third-party AI tool's OAuth tokens

What happened?

In April 2026, Vercel disclosed that attackers gained unauthorized access to internal systems and a limited subset of customer credentials after a Vercel employee had connected a third-party AI productivity tool, to their corporate Google Workspace account with broad ("Allow All") permissions.

What supply-chain dependency was involved?

An AI SaaS tool authorized via OAuth against enterprise identity — not code the enterprise wrote or a model it deployed, but a connected AI vendor with standing access.

Confirmed incident or research?

Confirmed, publicly disclosed incident — this is a documented breach, not a proof of concept.

What should enterprises learn?

An AI vendor is a supply-chain dependency the moment an employee authorizes it against enterprise identity, whether or not security teams tracked the connection.

Control that reduces the risk?

Inventory every OAuth grant to third-party AI tools, restrict scopes to the minimum required, and treat any AI SaaS integration as a vendor requiring the same review as a core infrastructure provider.

Lovable — AI-generated applications shipping with exposed credentials

What happened?

Security research through 2025–2026 repeatedly found that applications built on the AI app-builder Lovable shipped with exposed Supabase database keys and, in some cases, broken authorization controls that let one user access another user's project data.

What supply-chain dependency was involved?

The AI development platform itself, and the default configuration it generates for connected backend services.

What was the mechanism?

In testing across a sample of Lovable-generated applications, researchers found broken access control present when default code was deployed without manually configuring row-level security, and in some cases the elevated Supabase service-role key — which grants full database administrative access — was exposed directly in client-side code. Separately, a March 2026 API flaw stemming from missing ownership checks allowed logged-in users to query project data belonging to other accounts, exposing source code and embedded credentials from projects created before November 2025.

Confirmed incident or research?

A mix: independent security research documenting a systemic pattern, plus a specific, vendor-confirmed API vulnerability.

What should enterprises learn?

AI code-generation and app-building tools are a supply-chain dependency at the moment they generate infrastructure configuration, not just when they generate application logic — and default settings from these tools should never be treated as production-ready.

Control that reduces the risk?

Security review of any AI-generated backend configuration (access control, credential handling) before deployment, and rotation of any credentials that ever passed through an AI builder's project context.

Claude Code / MCP — an AI agent weaponized for autonomous intrusion

What happened?

In November 2025, Anthropic disclosed that a Chinese state-sponsored group, tracked as GTG-1002, had manipulated its Claude Code tool into functioning as an autonomous participant in a cyber-espionage campaign against roughly 30 organizations, including technology companies, financial institutions, and government agencies.

What supply-chain dependency was involved?

The agent-and-tool layer: the threat actor leveraged several independent Claude Code instances interfacing with a range of tools via the Model Context Protocol (MCP) to attempt its intrusions.

What was the mechanism?

The attackers convinced the model to take the role of an employee at a cybersecurity firm performing legitimate defensive security testing, circumventing the model's guardrails, and the campaign involved multiple Claude agents working autonomously throughout each stage of an attack, with the AI doing 80–90% of the work and humans intervening only 10–20% of the time.

Confirmed incident or research?

Confirmed and disclosed directly by the AI provider itself — an unusually direct primary source for an AI supply-chain incident.

What should enterprises learn?

Agent + tool combinations (via MCP or similar protocols) shift AI risk from "bad output" to "autonomous action," and the same tool-connection architecture that gives an agent legitimate capability is exactly what an attacker needs if the agent is manipulated.

Control that reduces the risk?

Scope every MCP/tool connection to least privilege, require human approval for consequential actions, and monitor agent tool-call patterns for anomalies rather than only monitoring model output.

GitHub Actions (tj-actions) — a trusted CI/CD dependency compromised

What happened?

In March 2025, a widely used GitHub Actions dependency was compromised, exposing CI/CD secrets across roughly 23,000 repositories that depended on it, without any zero-day vulnerability involved — the dependency itself was simply trusted and unaudited.

What supply-chain dependency was involved?

A CI/CD pipeline dependency — not AI-specific, but directly relevant because AI development pipelines rely on the same class of unaudited, trusted third-party actions.

What was the mechanism?

A single compromised dependency in the build pipeline was able to exfiltrate secrets from any repository that used it, at scale, because trust in the dependency was assumed rather than verified.

Confirmed incident or research?

Confirmed, publicly reported incident.

What should enterprises learn?

The blast radius of a single compromised dependency scales with how many pipelines trust it by default — a pattern that maps directly onto AI model repositories and MCP servers, which occupy the same "trusted by default" position in an AI pipeline.

Control that reduces the risk?

Pin dependency versions, audit third-party actions and MCP servers before adoption, and don't extend automatic trust to a dependency just because it's popular.

How an AI Supply Chain Attack Happens

A typical AI supply-chain attack follows a recognizable lifecycle: a component upstream is compromised (a model, a package, a plugin, an OAuth-connected tool) → that component sits inside a trusted vendor, repository, or registry → the enterprise integrates it, often without a formal review → the weakness enters production alongside legitimate functionality → the AI system's behavior or access is manipulated, directly or through an agent's tool calls → the impact surfaces as data exposure, unauthorized action, or degraded output → the incident is detected (ideally by monitoring, not by the attacker's own visibility) → containment follows → recovery requires rolling back or replacing the compromised component and revalidating the system. Visibility and provenance are what let an organization interrupt this chain early — most of the incidents above were detectable well before the "impact" stage, if the dependency had been inventoried and monitored.

What Is an AI Bill of Materials (AI-BOM)?

An AI-BOM is a structured, machine-readable inventory of everything an AI system depends on: models, model versions, datasets and their sources, open-source libraries, APIs, plugins, agents, vector databases, cloud providers, licenses, and known vulnerabilities. It extends the software-world SBOM concept to cover AI-specific dependencies that an SBOM was never designed to track — most notably models and training data.

The leading practical format is CycloneDX, an OWASP project that added machine-learning support with its ML-BOM extension, and the current specification is version 1.7, standardized as the second edition of ECMA-424. An alternative, ISO-aligned approach is the SPDX AI Profile. A useful AI-BOM entry typically records: the model and its provider, model version, the dataset(s) used and their source where known, open-source dependencies and libraries, connected APIs and plugins, connected agents and MCP servers, the vector database in use, the cloud provider, applicable licenses, known provenance information, and the deployment environment.

An AI-BOM improves incident response (you can immediately answer "are we affected" when a dependency is disclosed as compromised), vendor risk management (you know what you're actually exposed to, not just what procurement approved), and compliance evidence (several emerging frameworks expect this kind of documentation as a baseline artifact). Without one, most organizations discover their AI dependencies for the first time during an incident.

AI Model Provenance and Dataset Lineage

Model provenance is the documented, ideally tamper-evident record of where a model came from: where an artifact came from, who authored, changed, or trained it, what datasets were used in training it, and what source code was used to generate the artifact. Dataset lineage extends this to the data layer: which datasets were used, where they originated, and what changed between versions.

Be realistic about the limits here: for models you build or fine-tune internally, full provenance is achievable. For third-party foundation models accessed via API, organizations typically cannot obtain complete training-data provenance from the provider — that visibility usually stops at the model card and whatever the provider chooses to disclose. Provenance still matters at whatever level of detail is available, because it supports trust, traceability during an incident, compliance documentation, and model validation before deployment — even partial provenance is far better than none when you're trying to determine whether a specific model was affected by a disclosed vulnerability.

AI Supply Chain Risk Assessment and Audit

An AI supply-chain audit should review the AI-BOM against actual deployed systems, model and dataset provenance records, vendor and third-party model risk assessments, dependency and library inventories, model version history, tool and agent permission scopes, applicable security controls, privacy and compliance documentation, incident-response readiness, and monitoring coverage. A concise starting checklist:

(1) Do we have a current AI-BOM covering every production AI system?

(2) Can we identify every model, dataset, and vendor in use?

(3) Do we know our subprocessors, not just our direct vendors?

(4) Are agent and tool permissions documented and scoped to least privilege?

(5) Do we have a tested rollback path if a vendor pushes a bad update?

(6) Is sensitive data reaching any AI dependency without redaction or a data-processing agreement?

AI Supply Chain Security Framework

Discover — Inventory every model, dataset, vendor, API, agent, and dependency in use, including shadow AI adopted outside formal procurement.

Map — Document upstream and downstream dependencies for each system, including subprocessors.

Verify — Validate provenance, integrity, licensing, and baseline security posture for each dependency.

Assess — Score vendor, model, data, and dependency risk against a consistent framework.

Control — Apply least privilege, isolation, and access controls, particularly for agents and tools.

Monitor — Continuously watch for model changes, vendor changes, new vulnerabilities, and anomalous runtime behavior.

Respond — Maintain an AI-specific incident-response plan, not a generic one retrofitted for AI.

Recover — Roll back or replace compromised components, preserve evidence, and revalidate before returning to production.

Generative AI Supply Chain Risks

Generative AI introduces its own risk cluster on top of the general taxonomy above: dependency on an LLM provider whose model can change without your application changing, uncertainty about what training data shaped the model's behavior, prompt and output privacy as data flows to an external provider, RAG AI pipelines and the external content they retrieve, embeddings and the vector databases that store them, external APIs and plugins the model can call, model routing decisions made by the provider (which model actually served a given request), and the logging and monitoring gap most organizations have around what prompts and outputs are actually leaving the enterprise boundary.

AI Agent and MCP Supply Chain Risks

Traditional AI generates an output a human reviews before acting on it. An agent can call a tool, access a system, execute an action, modify data, or communicate externally — which means a supply-chain compromise in the agent's toolchain becomes an operational risk, not just an output-quality one, as the Claude Code/MCP incident above illustrates directly.

The specific risk surface includes agent identity (what the agent is authenticated as), tool permissions (what it can actually do), the MCP servers and external tools it connects to, the credentials those connections use, agent memory and context (which can be poisoned via injected content), and third-party tool updates that change agent capability without the enterprise's knowledge. Excessive agency — giving an agent more tools, broader permissions, or more autonomy than its task requires — is one of the most significantly expanded risk categories in current LLM security guidance, precisely because agentic architectures have moved from experimental to production over the past year. Practical controls: log every tool call, require human approval above defined risk thresholds, apply least-privilege scoping to every connected tool, and treat any content an agent retrieves (documents, emails, web pages, supplier records) as untrusted data rather than trusted instruction.

RAG and Vector Database Supply Chain Risks

Retrieval-augmented generation pulls content from external or semi-external sources at query time, which makes the retrieval layer a supply-chain dependency in its own right. Untrusted data sources, poisoned documents, and embedded malicious instructions can all end up in a model's context without a human ever reviewing the source content directly. Vector database integrity matters just as much: if the store itself can be written to by an untrusted process, retrieval poisoning doesn't require compromising the original document at all. Controls that matter here: access control on who or what can write to the vector store, source provenance tracking for indexed content, document versioning so changes are auditable, content validation before indexing, and monitoring for anomalous retrieval patterns.

Regulatory and Governance Considerations

Legal requirements. The EU AI Act applies binding obligations to certain AI system categories, including documentation and risk-management requirements that touch supply-chain transparency for higher-risk systems — but not every organization or every AI use case falls into scope, and applicability should be assessed case by case rather than assumed. GDPR applies wherever personal data is processed through an AI dependency, including by subprocessors, regardless of whether the organization directly controls that processing.

Voluntary frameworks. The NIST AI Risk Management Framework is voluntary and organized around four functions — Govern, Map, Measure, and Manage — that together give organizations a structured, sector-agnostic way to reason about AI risk, including supply-chain risk. ISO/IEC 42001 is the first global certifiable standard for an AI management system, translating governance principles into an auditable structure — distinct from NIST's framework in that it can actually be certified against.

Recommended practice. Regardless of which frameworks legally apply, mapping AI supply-chain controls to a recognized structure (NIST's four functions or ISO 42001's management-system clauses) gives security and compliance teams a shared vocabulary and makes vendor and audit conversations far more efficient — this is a practical recommendation, not a claim that any specific framework is legally mandatory for every organization.

When Sovereign or Private AI Architecture Can Reduce Supply Chain Risk

Private, local, or sovereign AI architectures can meaningfully reduce certain categories of external dependency — particularly data-exposure risk to third-party providers and cross-border data-residency exposure. Running models on infrastructure you control removes some vendor-relationship risk entirely.

But sovereignty is not a universal fix. A self-hosted open-weight model still carries model and dataset provenance questions. Self-hosted infrastructure still depends on open-source frameworks and libraries with their own vulnerability history. Self-built agents still carry tool and permission risk. Sovereign or private deployment shrinks the vendor-dependency surface; it does not eliminate model risk, dataset risk, software vulnerabilities, or agent/tool risk, all of which live inside the deployment regardless of who hosts it.

How to Continuously Monitor AI Supply Chain Risk

One-time vendor due diligence is insufficient because every layer of the AI supply chain changes after the initial review: models get updated, vendors add subprocessors, dependencies get new CVEs, agents get new tool access, and regulations evolve. A continuous monitoring program should track model and vendor changes (via changelogs and notification commitments), new dependency vulnerabilities, new or changed subprocessors, security incidents at any vendor in the chain, dataset and data-source changes for RAG systems, model behavioral drift against a fixed evaluation set, agent and tool permission changes, and relevant regulatory changes that could affect existing deployments.

How Questa AI Can Help Protect Enterprise AI Data and Workflows

Everything above — AI-BOM, provenance, vendor due diligence, monitoring — addresses what enters the AI supply chain. There's a related but distinct problem: what enterprise data leaves the organization's boundary every time an employee or system sends something to an external AI tool. Supplier contracts pasted into a summarization assistant, customer records processed by a third-party AI feature, or internal documents uploaded to an AI coding tool are all data-exposure events that a vendor checklist or an AI-BOM won't catch on their own, because the data itself — not just the dependency — is what's at risk.

This is the specific slice of the problem a privacy-first architecture Questa AI is built around: anonymizing or redacting sensitive data before it reaches an external model or AI service, so the AI system works with de-identified patterns rather than raw enterprise data. That reduces the blast radius if any downstream AI dependency — a model provider, a plugin, an agent's tool call — is ever compromised or misused, because the sensitive underlying data was never exposed to it in the first place. It's worth being direct about scope: this kind of data-protection layer doesn't replace vendor due diligence, model provenance verification, security testing, or incident response — it addresses the data-exposure dimension of AI supply chain risk specifically, alongside those other controls, not instead of them.

Frequently Asked Questions