AI Supply Chain Security

How AI supply chain security works#

An AI system is rarely built from a single model or application. It may depend on source code, open-source packages, container images, training data, pretrained models, embedding models, vector databases, plugins, cloud services, and operational configuration. Each dependency creates a potential supply chain risk.

AI supply chain security applies controls across the system’s lifecycle.

1. Inventory the AI stack

Teams first identify what is being used and where it came from. An inventory should cover:

Application and infrastructure code
Direct and transitive software dependencies
Base images and operating system packages
Training, validation, and retrieval datasets
Pretrained and fine-tuned models
Tokenizers, embeddings, and inference libraries
Prompts, system instructions, and agent tools
Model registries, artifact stores, and pipelines
External model APIs and managed AI platforms

Connect each artifact to an owner, source, version, environment, and business use case. Without that context, security teams may know that a model exists but not whether it processes regulated data or supports a critical workflow.

2. Verify provenance and integrity

Provenance records describe how an artifact was created, modified, tested, and promoted. A model record, for example, might identify its base model, training datasets, fine-tuning code, build pipeline, evaluation results, and approving users.

Integrity controls help confirm that the artifact in production is the one that was reviewed. Useful controls include:

Cryptographic hashes for models, datasets, containers, and packages
Signed commits, builds, and release artifacts
Trusted registries with access controls
Immutable or append-only audit records
Version pinning for dependencies and model artifacts
Checks that compare deployed content with approved content

A hash does not establish that an artifact is safe. It only helps detect unexpected changes. Security teams still need source validation, testing, review, and risk assessment.

3. Assess content and component risk

AI-specific components require additional review. A model can contain unsafe behavior, hidden instructions, biased outputs, or capabilities that are inappropriate for its use case. A dataset can include poisoned records, confidential information, licensing restrictions, or malicious content that influences training or retrieval.

Assessment should consider:

Source reputation and ownership
License and usage restrictions
Dataset collection and cleaning methods
Model purpose, capabilities, and limitations
Known vulnerabilities in supporting software
Exposure of secrets or personal information
Evaluation results for security and reliability
Whether the component is maintained and still supported

Public repositories and model hubs should not be treated as automatically trusted. Download counts, community ratings, or a familiar project name are not substitutes for validation.

4. Protect the build and deployment pipeline

The pipeline that trains, packages, evaluates, and deploys an AI system is a high-value target. An attacker who alters pipeline code or credentials may be able to change the model, inject data, bypass evaluation, or deploy an unapproved artifact.

Recommended controls include:

Separate development, testing, and production permissions
Short-lived credentials for pipeline jobs
Secret storage outside source code and notebooks
Branch protection and mandatory code review
Dependency and container scanning
Isolated training and build environments
Approval gates before production promotion
Reproducible builds where practical
Network restrictions for training and deployment workers

Credentials should be stored in an approved secrets manager rather than in notebooks, environment files, or source code. A password manager such as Try 1Password → may help teams manage access to shared administrative accounts, but it does not replace dedicated machine-identity and secrets-management controls for production pipelines.

The pipeline should fail safely when provenance is missing, signatures do not validate, or an artifact differs from its approved version.

5. Monitor runtime behavior

Supply chain security continues after deployment. Monitor model-serving systems, agent tools, data access, outbound connections, package changes, and administrative actions.

Important signals may include:

A model file changing outside the release process
New packages or system binaries appearing on a serving host
Unexpected access to training data or model registries
Requests to unapproved external AI services
Sudden changes in output patterns or refusal behavior
Model endpoints making unusual tool or network calls
Deployment activity from an unexpected identity or location

Runtime monitoring can help distinguish a compromised component from ordinary model drift, but it should be paired with known-good versions and a rollback process.

Organizations should also document the response path for suspected tampering. An incident response planning checklist can help teams define ownership, escalation criteria, evidence collection, containment, and recovery steps before an incident occurs.

Technical notes

A basic artifact-integrity check can be part of a deployment gate:

sha256sum models/customer-support-v3.bin

# Compare the result with the approved release record
test "$(sha256sum models/customer-support-v3.bin | awk '{print $1}')" = "$EXPECTED_SHA256"

A simple software manifest can document the components associated with a release:

release: customer-support-v3
model:
  name: support-base
  version: "3.2.1"
  sha256: "approved-digest"
dataset:
  name: support-knowledge
  version: "2026-09"
dependencies:
  - name: inference-runtime
    version: "pinned-version"
approvals:
  - security
  - model-owner

This example is not a complete security control. Production systems should use signed attestations, protected registries, access logging, and automated policy checks where available.

When you’ll encounter AI supply chain security#

You will encounter AI supply chain security whenever an AI capability depends on components or services your team does not create and control entirely.

Common situations include:

Downloading a pretrained model from a public or commercial registry
Fine-tuning a third-party model with internal data
Installing machine learning frameworks or inference packages
Building an AI application from open-source repositories
Using retrieval-augmented generation with external documents
Connecting an AI agent to plugins, APIs, databases, or scripts
Deploying models through a cloud provider
Calling hosted AI APIs from business applications
Importing models into laptops, servers, or edge devices
Using AI-generated code or configuration in production pipelines

Small organizations may encounter these risks through a single SaaS integration, while larger enterprises may operate multiple model registries, data pipelines, and internal AI platforms. The scale changes, but the core questions remain the same: What are we using, where did it come from, who changed it, and what can it access?

A practical starting checklist#

Teams can begin with a focused set of controls:

Create an AI component inventory. Record models, datasets, code, packages, containers, services, prompts, and tools.
Assign ownership. Identify who approves, maintains, and monitors each component.
Record provenance. Capture sources, versions, transformations, evaluations, and approvals.
Protect credentials and pipelines. Use least privilege, isolated build environments, secret storage, and code review.
Verify releases. Use hashes, signatures, protected registries, and approval gates.
Monitor production. Track changes, access, network activity, tool calls, and unusual model behavior.
Prepare for rollback. Maintain known-good artifacts and test the process for restoring them.

These steps align with a broader defense-in-depth approach: no single hash, scanner, approval, or monitoring rule can address every AI supply chain risk.