AI Supply Chain Security and AI-BOM Guide

AI systems are assembled from parts you did not build: foundation models, fine-tuned weights, data sets, open source libraries, agent frameworks, plugins, MCP servers and third-party AI services. Each part can be compromised, and each often brings credentials and permissions with it. Attacks on AI packages, coding agent extensions, agent skill marketplaces and AI SaaS integrations since 2024 show that the AI supply chain is now a primary target, and that the prize is usually the credentials the component can reach. This guide explains the components of the AI supply chain, how attacks on it work, what an AI bill of materials (AI-BOM) should record, and the integrity, identity and monitoring controls that matter most. It is written for AI platform and MLOps teams, application security and supply chain owners, and the IAM teams who manage the non-human identities that AI systems use.

Key takeaways

The supply chain is wider than code: it includes models, data, libraries, tools, prompts and AI services, plus the credentials each component uses. OWASP LLM03:2025 notes that in ML the risks "extend to third-party pre-trained models and data".
An AI-BOM is the inventory you respond from: it records what an AI system is made of, where each part came from and what it can access. MITRE ATLAS lists the AI Bill of Materials as mitigation AML.M0023, and CycloneDX and SPDX 3.0 both model AI components.
Model files can be code: pickle, the default PyTorch weight format, can run arbitrary code when loaded, according to Hugging Face. Prefer safe formats such as safetensors and verify signatures and hashes.
Most AI supply chain attacks are credential attacks: LiteLLM, Mastra, the JetBrains AI plugin campaign and ClawHub all aimed at API keys, cloud credentials and tokens. Least privilege and short-lived secrets limit the damage.
Agents raise the stakes: OWASP's Agentic Top 10 lists Agentic Supply Chain Vulnerabilities as ASI04, covering poisoned tool descriptors, malicious MCP servers and compromised registries, and recommends a "supply chain kill switch".

Components of the AI supply chain

An AI system has the same software dependencies as any application, plus components that ordinary software composition analysis does not see. OWASP LLM03:2025 points out that models are "binary black boxes" where static inspection gives little assurance, and that model cards "offer no guarantees on the origin of the model".

Component	Examples	Key risks
Foundation and fine-tuned models	Hosted model APIs; downloaded open-weight models; LoRA adapters	Backdoored or poisoned weights; unsafe serialisation formats that execute code on load; outdated or deprecated models; malicious adapters
Data sets	Training, fine-tuning, evaluation and RAG sources	Poisoning; embedded secrets and personal data; licensing
Libraries and frameworks	AI SDKs, LLM gateways, orchestration and agent frameworks	Malicious or compromised packages stealing credentials; dependency confusion
Tools, plugins, skills and MCP servers	IDE extensions, agent tools, skill marketplaces, community MCP servers	Tool poisoning; typosquatting and impersonation; credential theft
Third-party AI services	SaaS AI features, AI assistants connected via OAuth	Vendor compromise exposing tokens and data; changed terms on data use
Prompts and agent configuration	System prompts, templates, agent instruction files, agent cards	Hidden instructions; tampering; remotely loaded templates
Build and serving infrastructure	CI/CD pipelines, model registries, container registries, inference servers	Stolen publishing tokens; tampered builds; exposed AI clusters

MITRE ATLAS (release 2026.09) models these as sub-techniques of AML.T0010 AI Supply Chain Compromise: Hardware, AI Software, Data, Model, Container Registry and AI Agent Tool. See the MITRE ATLAS Guide.

How AI supply chain attacks work

The attack paths fall into five groups. Most end with the same outcome: code running inside a developer workstation, CI runner, agent or inference server that holds valuable credentials.

Compromised publishers: attackers steal a maintainer's registry token or abuse a CI workflow to publish a malicious version of a trusted package. Build provenance and trusted publishing make this harder.
Lookalikes and dependency confusion: a package, model or MCP server with a familiar name, or a public package that shadows an internal one. See the Malicious Package and Dependency Confusion Guide.
Unsafe model artefacts: ATLAS AML.T0011.000 Unsafe AI Artifacts describes serialised models that execute code when loaded. Hugging Face explains how a pickle file can call exec on attacker code during deserialisation.
Poisoned data and models: tampered training or fine-tuning data, or weights edited to plant triggers. OWASP LLM04:2025 covers data and model poisoning. See the AI Data Poisoning and Backdoors Guide.
Poisoned agent tools and descriptors: OWASP ASI04 describes hidden instructions in a tool's metadata or MCP agent card that "the host agent interprets as trusted guidance", and malicious registry servers that serve tampered manifests at scale. See the AI Agent Tool and Plugin Security Guide.

Recent AI supply chain incidents

Each of these incidents is analysed in NHI Mgmt Group's breach database. Read together, they show the same lesson: the component was the delivery mechanism, and credentials were the target.

Incident	What was compromised	Identity lesson
Amazon Q Developer Extension Compromise 2025	AWS said an "inappropriately scoped GitHub token" in CodeBuild let an attacker commit a data-wiping prompt that shipped in version 1.84.0	Scope CI tokens to the minimum; review what agents are told to do as code
LiteLLM PyPI Package Breach 2026	Versions 1.82.7 and 1.82.8 carried a stealer for SSH keys, cloud credentials and LLM API keys, published with a PyPI token leaked from LiteLLM's CI	An LLM gateway holds many provider keys; isolate it and rotate fast
Mastra npm Supply Chain Attack 2026	A former contributor's npm account, still holding publishing rights, republished more than 140 agent framework packages with a malicious dependency	Offboard publishing rights; NHI1 Improper Offboarding applies to registry tokens
JetBrains Marketplace AI Plugin Campaign 2026	Aikido Security found 15 AI assistant plugins that sent users' AI provider keys to an attacker server, with about 70,000 installations	Allowlist IDE extensions; issue developers scoped, revocable AI keys
postmark-mcp Malicious MCP Server 2025	An impersonating MCP server added a blind copy of every email to an attacker in version 1.0.16	Pin MCP servers by version and hash; detect changes
ClawHub Malicious Skills 2026	Koi Security found 341 malicious skills out of 2,857 on the OpenClaw marketplace, delivering stealers aimed at API keys and agent credentials	Treat agent skill marketplaces as untrusted registries
Nx s1ngularity Attack 2025	Malicious Nx versions searched for secrets and prompted locally installed AI command-line tools to help find files	Local AI agents widen what a malicious package can reach
Vercel Context.ai OAuth Breach 2026 and Salesloft Drift Breach 2025	OAuth tokens held by third-party AI tools gave attackers access to corporate accounts and customer data	Scope and review OAuth grants to AI vendors; revoke unused ones

Older incidents set the pattern: the PyTorch torchtriton attack (December 2022) used dependency confusion against nightly builds, the Ultralytics PyPI compromise (December 2024) abused a GitHub Actions workflow and a leftover PyPI token, and the Hugging Face Spaces breach (May 2024) exposed secrets stored for hosted AI apps.

What an AI-BOM should record

An AI-BOM extends the software bill of materials to models, data sets, tools and services. OWASP LLM03:2025 recommends a signed, up-to-date inventory and says to "evaluate options starting with OWASP CycloneDX"; ATLAS AML.M0023 adds dataset provenance, "a detailed history of datasets used", including modifications.

Record	What to capture	Why it matters
Models	Name, version, supplier, download location, hash or signature, licence, base model and fine-tuning lineage, serialisation format	Find affected systems when a model or format is found unsafe
Data sets	Sources, versions, collection dates, known sensitive content, licences, modifications	Trace poisoning and personal data exposure
Software dependencies	Libraries and frameworks with exact versions (the SBOM)	Match new advisories to deployments in minutes
Tools, plugins, skills and MCP servers	Source, version, content hash, permissions and credentials used	Detect descriptor changes; scope a compromise
External AI services	Providers, endpoints, data shared, authentication method, terms on data use	Assess vendor incidents and data flows
Prompts and configuration	System prompts, templates and agent instructions under version control, with commit IDs	Prove what the agent was told to do
Identities and credentials	Which NHIs the system uses, what they can access, owner and rotation method	Know what to rotate first

Formats

CycloneDX: its ML-BOM capability represents "datasets, models, and configurations" and dataset provenance. CycloneDX 1.7 is current, and the specification is standardised by Ecma International as ECMA-424. Its Services element records external APIs with authentication requirements and trust boundaries, which suits AI service dependencies.
SPDX 3.0: the AI profile documents "AI system and model artifacts", and the AIPackage class carries properties such as typeOfModel, informationAboutTraining, safetyRiskAssessment and useSensitivePersonalInformation. A separate Dataset profile covers data. SPDX is also an ISO standard (ISO/IEC 5962:2021).
Agentic systems: OWASP's Agentic Top 10 includes an appendix on its relationship to CycloneDX, which answers "What components and tools are in my AI system?" while the Top 10 addresses how they can behave.

Generate AI-BOMs in the build pipeline, sign them, and store them where incident responders can query them. See the SBOM Guide.

Controls

Integrity and provenance

Approved sources: download models only from approved publishers and mirrors; verify hashes and signatures where available. OWASP LLM03:2025 recommends "signing and file hashes to compensate for the lack of strong model provenance".
Safe formats: prefer safetensors, which Hugging Face describes as a format for storing tensors safely "as opposed to pickle"; scan any pickle-based files before loading.
Model signing: the OpenSSF model-transparency project signs models with Sigstore, public keys or certificates, and verification recomputes file hashes against the signed ones.
Build provenance: sign internal models and artefacts. SLSA Build L2 requires signed provenance from a hosted build platform, and Build L3 a hardened build platform. See the SLSA and Build Provenance Guide.
Pinned dependencies: pin package versions, use lock files and route installs through a vetted internal registry.

Allowlisting

Maintain approved lists of models, AI libraries, IDE extensions, agent skills and MCP servers. See the MCP Security Guide.
Pin prompts, tools and configuration "by content hash and commit ID", as OWASP ASI04 recommends, and roll back automatically on hash drift.

Credential containment

Do not give unvetted components access to credentials; run them in sandboxes without ambient secrets.
Use short-lived, least-privilege credentials so a compromised component gains little. See the Secrets Management Guide.
Scope OAuth grants for AI vendors narrowly. See the SaaS and OAuth App Governance Guide.

Vendor assessment

Assess AI vendors on data use and training terms, token protection, their own supply chain security, incident notification and how quickly they can revoke tokens. See the Third-Party AI Risk Guide.

Monitoring and response

Subscribe to advisories for the AI packages, models and tools in your AI-BOMs, and keep a rotation runbook for every credential an AI system holds.
Build the "supply chain kill switch" OWASP ASI04 describes: a way to disable a specific tool, prompt or agent connection across all deployments at once.

Detection and monitoring

New or changed components: alert when a model hash, MCP tool descriptor, skill or extension version changes outside a release.
Install-time behaviour: post-install scripts that reach the network, read credential files or spawn shells on developer machines and CI runners.
Credential use from new places: AI provider keys, registry tokens and cloud keys used from unfamiliar IP ranges or at unusual volume, which is often the first sign of a stolen key.
Agent behaviour drift: agents calling tools or destinations they have not used before, or local AI command-line tools run with safety-bypassing flags.
Registry and repository events: new publishers, new maintainers and token creation on the packages and models you publish.

Framework mapping

Indicative alignment by NHI Mgmt Group, not an official mapping. Control IDs were checked against NIST CSWP 29 (CSF 2.0), the NIST SP 800-53 Rev. 5 catalogue, the CIS Controls v8.1 control list, a published ISO/IEC 27001:2022 Annex A list, OWASP LLM03/LLM04:2025, the OWASP Agentic Top 10 2026 and MITRE ATLAS 2026.09.

Control area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1	OWASP and ATLAS
AI component inventory (AI-BOM)	ID.AM-02, ID.AM-07	CM-8, SR-4	A.5.9	2	LLM03, ASI04, AML.M0023
Supplier and model provider due diligence	GV.SC-06, GV.SC-07	SR-3, SR-6, SA-9	A.5.19, A.5.20, A.5.21	15	LLM03, NHI3
Model and package integrity	ID.RA-09	SI-7, SR-11, CM-14	A.5.21, A.8.19	2, 16	AML.T0010, AML.M0013
Safe model loading	PR.PS-05	SI-3, CM-7(5)	A.8.7, A.8.19	2, 10	AML.T0011.000
Data provenance and poisoning	ID.AM-07, PR.DS-01	SI-7, SR-4	A.5.9, A.8.25	3	LLM04, AML.T0010.002
Tool, plugin and MCP allowlisting	PR.PS-05	CM-7(5), CM-11	A.8.19	2	ASI04, AML.T0010.005
Credential containment	PR.AA-05	AC-6, IA-5	A.5.17, A.8.2	5, 6	NHI2, NHI5, NHI7
Build provenance	PR.PS-06	SA-10, SA-15, SR-4	A.8.25	16	ASI04
Advisories, monitoring and response	DE.CM-09, RS.MI-01	SI-4, SI-5, IR-4	A.5.7, A.8.8, A.8.16	7, 17	ASI04

Common failure patterns

Publishing rights that outlive the publisher: the Mastra npm Supply Chain Attack 2026 used an inactive contributor's account that still held rights across the npm scope.
Over-scoped CI tokens: in the Amazon Q Developer Extension Compromise 2025, a CodeBuild token with too much access let an attacker commit straight into a release.
Secrets leaking through the AI platform itself: in the CrewAI "Uncrew" Flaw 2025, an error message exposed an internal GitHub token that Noma Security said had full administrative privileges.
Trusting model files as data: loading pickle-based weights from unknown publishers on a machine with cloud credentials.
Developer-chosen AI tools with no review: IDE plugins and agent skills installed from marketplaces, as in the JetBrains and ClawHub campaigns, with real AI and cloud keys pasted in.
Training data full of secrets: Truffle Security found 11,908 live secrets in one Common Crawl archive used for LLM training; see 12,000 Live Secrets in LLM Training Data 2025.
An AI-BOM nobody can query: a document generated once for compliance, not a live inventory responders can search when an advisory lands.

Metrics that show progress

Metric	What it shows	Target direction
Production AI systems with a current, signed AI-BOM	Inventory coverage	Up, towards 100%
Models loaded from approved sources with verified hash or signature	Model integrity	Up
Models in pickle-based formats in production	Unsafe artefact exposure	Down
MCP servers, skills and IDE extensions on the allowlist versus discovered in use	Shadow AI tooling	Gap down
AI-related packages pinned and installed through the internal registry	Dependency control	Up
Hours from AI package advisory to identifying affected systems	AI-BOM usefulness	Down
Hours from compromise to rotation of credentials the component held	Containment speed	Down
AI vendor OAuth grants reviewed in the last 90 days	Third-party AI access hygiene	Up

Implementation roadmap

Phase	Actions	Outcome
First 30 days	List production AI systems and the models, packages, tools and AI services they use; find pickle-based models and unreviewed MCP servers, skills and IDE plugins; list the credentials each system holds	A first AI inventory and the riskiest components known
Days 31 to 90	Generate CycloneDX or SPDX AI-BOMs in CI; route AI packages through an internal registry with pinning; publish allowlists for models, MCP servers and extensions; move AI keys into a secrets manager with owners	Repeatable inventory and controlled intake
Days 91 to 180	Verify model signatures or hashes at load; move to safe formats; adopt signed build provenance for internal models; review AI vendor OAuth grants; add detections for component changes and key misuse	Integrity checks enforced, misuse visible
Beyond 180 days	Build the kill switch for tools and agent connections; rehearse an AI package compromise as a tabletop; measure advisory-to-rotation time	AI supply chain incidents contained in hours

Practitioner checklist

Build a signed AI-BOM for each production AI system, covering models, data, dependencies, tools, services, prompts and credentials.
Download models only from approved sources and verify hashes or signatures before loading.
Prefer safetensors or other non-executable formats; scan pickle-based files.
Route AI packages through a vetted registry and pin versions with lock files.
Allowlist AI tools, plugins, skills and MCP servers; pin them by hash and detect changes.
Remove publishing rights and tokens from people who no longer maintain a package or model.
Keep credentials away from unvetted components; use short-lived, scoped secrets.
Assess AI vendors and scope their OAuth access.
Monitor for component changes, install-time behaviour and AI key misuse.
Keep a rotation runbook and a kill switch ready for an AI supply chain advisory.