AI Supply Chain Security: How to Defend the AI Stack

AI supply chain security is the practice of protecting every external component an AI system depends on, from training datasets and pre-trained models to the packages, build pipelines, gateways, and vendors that assemble them.

The reason it commands attention now comes down to leverage. An attacker who corrupts one upstream component reaches thousands of downstream environments at once, riding the distribution channels every build system trusts by default. Poisoning a single artifact outperforms thousands of direct intrusions, and it costs the attacker less.

March 2026 proved the math. One compromised AI gateway package, ingested automatically by build systems, cascaded into potential exposure across more than 2,500 organizations and roughly 434,000 CI/CD pipelines before detection caught up. CloudSEK Threat Intelligence reconstructed the full victim exposure of that campaign, and the anatomy section below draws on that reconstruction. Threats like it span the whole AI stack, before and after deployment, where opaque artifacts, exposed junctions, and automated pipelines meet.

How the AI Supply Chain Differs From the Software Supply Chain

AI supply chains differ from software supply chains in 5 dimensions: primary asset, inspectability, execution trigger, provenance maturity, and surface breadth. Attackers exploit all 5, and controls designed for source code catch none of them cleanly.

Opacity carries a consequence the other dimensions lack. A poisoned dataset or tampered weight file behaves normally during testing and activates only under attacker-chosen conditions, so conventional code scanning misses it entirely. A supply chain attack against AI components inherits every software technique and adds these blind spots on top of it.

Components of the AI Supply Chain

An enterprise AI supply chain contains 4 layers: the data layer, the model layer, the toolchain layer, and the runtime junction layer. Every layer imports trust from outside the organization.

• Data layer: Training datasets, fine-tuning corpora, labeling services, and the retrieval sources feeding RAG (retrieval-augmented generation) pipelines. Poisoned records at this layer embed behaviors that surface only after deployment.
• Model layer: Base models, fine-tuned checkpoints, adapters, and the public hubs that distribute them. A tampered weight file ships a backdoor inside an asset no reviewer reads line by line.
• Toolchain layer: Machine learning frameworks, Python packages, container images, MLOps platforms, and the CI/CD (continuous integration and continuous delivery) pipelines that assemble them. Compromise here spreads at build speed.
• Runtime junction layer: AI gateways, model-serving APIs (application programming interfaces), MCP (Model Context Protocol) servers, agent runtimes, and vector databases. One junction asset holds credentials for models, data stores, and internal tools simultaneously.

Junction assets concentrate the risk. An AI gateway or agent runtime sits between sensitive data and systems that act autonomously, so control of one junction exposes surrounding identities and hands attackers an initial access vector into everything the junction touches.

Understanding AI Supply Chain Attacks: 6 Key Stages

AI supply chain attacks work through 6 sequential stages, from upstream compromise to downstream credential reuse. Recent incidents, from the 2022 PyTorch dependency confusion to the 2026 LiteLLM compromise, walked these stages in order.

1. Upstream compromise 

Attackers take over a maintainer account, an automation token, or a build system behind a trusted component. A single stale credential grants control over software that thousands of organizations ingest.

2. Poisoned artifact publication 

Attackers push a malicious package version, model checkpoint, or dataset revision through legitimate release channels. Authentic signing workflows make the poisoned artifact look trustworthy.

3. Automated ingestion

Dependency resolvers, scheduled CI/CD jobs, and model pulls copy the artifact within minutes of publication. Automation compresses a short publication window into wide distribution.

4. Execution and secret harvesting

Install-time hooks or load-time deserialization run attacker code inside the victim environment. The code collects every credential visible to the process, including environment variables, credential files, and cloud metadata responses.

5. Privilege expansion

Stolen tokens open cloud accounts, source repositories, container registries, SaaS (software as a service) tenants, and AI providers. Access spreads across systems the original package never touched.

6. Persistence and reuse

Attackers sell, trade, or weaponize harvested credentials weeks after the artifact disappears. Removal of the package closes the entry point, not the incident.

Stage 4 marks the pivot from software problem to enterprise breach, because credentials outlive the code that stole them.

Types of AI Supply Chain Attacks

Seven attack types dominate the AI supply chain threat landscape: dataset poisoning, malicious models, dependency compromise, pipeline compromise, tooling compromise, framework exploitation, and third-party AI service compromise. Each type has already produced at least one documented incident.

1. Dataset Poisoning

Dataset poisoning inserts manipulated records into training or fine-tuning data so the finished model carries hidden behaviors. In 2023, the PoisonGPT research demonstration altered an open-source GPT-J model to output targeted false statements while passing standard benchmarks. Poisoned retrieval sources extend the technique into RAG pipelines, where corrupted documents steer model answers at query time.

2. Malicious Models on Public Hubs

Researchers at JFrog identified close to 100 malicious models on Hugging Face in 2024, several opening reverse shells the moment a victim loaded them. The delivery mechanism is pickle, the Python serialization format behind many model files, and pickle executes embedded instructions during deserialization. A routine model download becomes code execution, no exploit required.

3. Dependency Compromise and Typosquatting

Dependency compromise plants hostile code inside the packages AI projects import. In December 2022, the PyTorch nightly build pulled a malicious torchtriton package through dependency confusion, a technique that tricks resolvers into fetching a public impostor in place of a private internal package.

CloudSEK's TXTBOOK investigation tracked 993 npm packages reproducing one bank's private namespace, the same confusion technique aimed at corporate builds. Typosquatting registers near-identical package names to catch mistyped installs. Slopsquatting, a newer variant, registers names that AI coding assistants hallucinate and waits for developers to install the fabricated dependency.

4. Build Pipeline and CI/CD Compromise

Build pipeline compromise targets the automation that assembles AI software. Attackers poisoned the Ultralytics YOLO releases in December 2024 by abusing a GitHub Actions workflow, shipping cryptomining code to PyPI through the project's own pipeline. Runners hold broad privileges and install dependencies without human review, so one hijacked workflow contaminates every artifact it produces.

5. Compromised Developer and Security Tooling

Tooling compromise weaponizes the utilities engineering teams trust by default, including scanners, code analyzers, and SDKs (software development kits).

During the 2026 TeamPCP campaign, the threat group weaponized trusted security and developer tooling, including the Trivy scanner and Checkmarx KICS, turning security software into a credential-theft channel across enterprise pipelines. Trusted tooling receives elevated access by design. A compromised scanner inherits every permission the security team gave it.

6. AI Framework and Gateway Exploitation

Framework exploitation abuses vulnerabilities in the serving layer that runs models in production. The ShadowRay campaign exploited the vulnerability CVE-2023-48022 in the Ray framework to hijack GPU (graphics processing unit) clusters and steal workload credentials from exposed deployments. AI gateways sit one step higher in the stack, and a poisoned gateway release reaches every application routed through it.

7. Third-Party AI Service Compromise

Service compromise reaches enterprises through the SaaS AI products and model provider APIs they subscribe to. A breached AI vendor exposes every tenant's prompts, connected data sources, and stored credentials in a single event. Vendor concentration deepens the exposure, because thousands of organizations route sensitive workloads through a handful of shared AI platforms.

Inside the LiteLLM Attack: Anatomy of a 2026 AI Supply Chain Breach

In March 2026, the TeamPCP threat actor group compromised LiteLLM, an open-source AI gateway that routes application traffic to model providers. CloudSEK assesses the campaign as the largest supply chain attack on AI infrastructure identified in 2026.

Entry came one tool upstream. A leaked automation token for the Trivy scanner was rotated but never fully revoked, which handed attackers a window of roughly 20 days to overwrite the scanner's published version tags. LiteLLM's build pipeline installed Trivy unpinned, so the poisoned scanner flowed into the build automatically and published malicious LiteLLM versions 1.82.7 and 1.82.8 to PyPI. The initial access vector was a security scanner: the tool organizations run to catch supply chain risk delivered it.

Both versions stayed live for about 40 minutes. Execution required no import statement: a malicious .pth file, a Python path configuration file that runs at interpreter startup, fired wherever the package was merely installed and sidestepped the --ignore-scripts protection installation tools rely on.

On each compromised runner, a credential stealer tracked as SANDCLOCK escalated privileges and swept 5 categories of secrets:

• SSH (secure shell) keys and repository deploy tokens
• AWS, Google Cloud, and Microsoft Azure credentials read from instance metadata services
• Kubernetes service-account tokens
• CI/CD secrets scraped from process memory, where GitHub Actions masking offers no protection
• LLM (large language model) API keys and gateway configuration

Where exfiltration to attacker infrastructure failed, the malware created public repositories named tpcp-docs or docs-tpcp inside victims' own GitHub accounts and uploaded the stolen data as release assets. Affected organizations were leaking their own secrets into public view without knowing it.

The reconstructed exposure dataset carries high-confidence matches at firms including Cisco, S&P Global, Siemens, and Deloitte, and the footprint reached Indian organizations as well, spanning fintech, manufacturing, SaaS, and a state government entity. Figures of this kind describe potential exposure, not confirmed compromise, and every match warrants private validation, credential rotation, and log investigation.

Presence mattered more than choice. LiteLLM arrives as a transitive dependency of agent frameworks and orchestration tools, so a share of the exposed pipelines installed it without any engineer ever selecting it.

Persistence defines the aftermath. The FBI's FLASH advisory FLASH-20260702-01 warns that affiliated actors are likely to weaponize the harvested credentials long after the intrusion window closed, which keeps the incident live for any organization that skipped rotation.

How to Defend the AI Stack Against Supply Chain Attacks

To defend the AI stack against supply chain attacks, security teams deploy 8 controls, each aimed at a specific stage of the attack chain. Controls 1 and 2 assume the stack is still clean. Control 8 assumes it never was.

Inventory the AI Stack With an AI-BOM

Build an AI-BOM that records every model, dataset, package, adapter, and AI service in production, using the CycloneDX ML-BOM or SPDX 3.0 AI profile formats. Inventory breaks the blindness that lets stages 1 through 3 pass unnoticed, because teams defend only the components they know exist.

Verify Provenance Before Any Artifact Enters the Stack

Require signed models, verified hashes, and SLSA-style provenance attestations, records that prove who built an artifact, from what inputs, on which system, for every package, checkpoint, and dataset. Prefer the safetensors format over pickle serialization, since safetensors stores weights without executable code. Provenance gates stage 2: artifacts whose origin or integrity fails verification never enter the stack.

Pin Every Dependency to a Verified Version

Pin packages, base images, CI actions, and build tools to exact hashes or commit-level identifiers rather than floating tags, and lock transitive dependencies with hash-enforcing installs. 

Enforce a minimum package age threshold of 7 days, a control the FBI recommends, to block freshly published malicious versions before community detection catches them. Pinning breaks stage 3, the automated ingestion that turned a 40-minute publication window into exposure across hundreds of thousands of pipelines.

Harden CI/CD Execution Environments

Run builds on ephemeral, least-privilege runners with outbound egress restricted to approved destinations. Isolate secrets from build steps that install third-party code, and watch runner processes for unexpected network connections.

This starves stage 4: install-time payloads find no privileges worth stealing and no route out. Alert on build steps that read instance metadata endpoints, since almost no legitimate build needs to.

Replace Static Credentials With Short-Lived Identity

Issue workload identities through OIDC (OpenID Connect) federation instead of storing long-lived cloud keys in pipeline secrets. Short-lived tokens expire before attackers reuse them. Expiry collapses the value of the stage 4 harvest and blunts stage 5 expansion.

Scan Models and AI Artifacts for Embedded Threats

Scan every inbound model file for embedded code, suspicious deserialization behavior, and tampered layers before load. Model scanning closes the gap conventional dependency scanners leave open, because weight files carry payloads no public vulnerability database lists.

Monitor the AI Attack Surface Continuously

Track exposed model endpoints, unmanaged AI deployments, leaked AI keys, and shadow AI, the AI services teams adopt outside approved inventory. Continuous AI attack surface monitoring detects stage 5 and stage 6 activity from the outside, surfacing the junction assets attackers scan for daily.

Prepare Broad Credential Rotation as Standing Doctrine

Treat any credential readable by a compromised process as exposed until validated, and follow a wave-based priority order for rotating credentials after CI/CD exposure. First, rotate every secret within reach of the affected environment, across cloud, repository, registry, Kubernetes, and AI provider keys. 

Second, hunt for unauthorized repositories, tokens, and service accounts created during the exposure window. Third, rebuild affected systems from known-clean sources. Rotation doctrine neutralizes stage 6, where stolen credentials outlive the malicious package.

The mapping below pairs each stage with the control that breaks it. A control absent from the stack leaves its stage open.

AI-BOM inventory underpins every row, because unmapped components never receive any of these controls.

How CloudSEK Approaches AI Supply Chain Exposure

Pipeline controls solve half the problem. Exposure visible from the outside, including leaked AI keys, unmanaged model endpoints, and forgotten gateway deployments, calls for outside-in discovery, and that gap is where CloudSEK operates.

CloudSEK AIVigil monitors the AI attack surface continuously, discovering exposed AI infrastructure, MCP servers, vector databases, agentic workflows, leaked AI credentials, and shadow AI before attackers chain them into an attack path. The platform correlates each finding with intelligence from CloudSEK Threat Intelligence, the research team that reconstructed the TeamPCP victim exposure, so security teams see which exposed asset connects to which live threat. For vendor-driven risk, SVigil extends that continuous watch to third-party ecosystems.

None of these findings replace dependency pinning, provenance checks, or hardened pipelines. AIVigil complements those controls by answering the question internal tooling never asks: which parts of the AI stack are already visible to attackers.