June 3, 2026 · 9 min read · AGENTIC SECURITY · Part 3 of 5 — Agentic AI Security cluster

Supply Chain Attacks Are Coming for Your AI Pipeline

The SolarWinds playbook works on AI pipelines too — poisoned GitHub Actions, malicious model dependencies, and compromised fine-tunes. Here's the ATLAS-mapped threat model and the controls that catch each vector.

TL;DR

Two ATT&CK/ATLAS techniques dominate AI supply chain risk: T1195.002 (Compromise Software Dependencies and Development Tools) and AML.T0104 (AI Pipeline Tampering). The companion technique is AML.T0010 (ML Supply Chain Compromise). Controls: pin all GitHub Actions to full commit SHAs, run dependency hash verification in CI, and scope agent permissions to the minimum needed for the job. Maps to NIST AI RMF GOVERN-5.2 (third-party AI supply chain governance) and NIST CSF DE.CM-01.

Why AI pipelines are a higher-value target: a compromised CI/CD pipeline for a non-AI app gives an attacker code execution. A compromised AI pipeline gives them code execution plus the ability to silently alter every model artifact, every training sample, and every prompt template the fleet uses. The blast radius is qualitatively larger.

The two AI-specific supply chain attack paths

Path 1: GitHub Actions workflow tampering (T1195.002)

The T1195.002 path targets your CI/CD pipeline directly. For an AI pipeline, the high-value targets in a GitHub Actions workflow are:

The attack surface is any GitHub Actions action referenced by tag (uses: actions/checkout@v4) rather than by full commit SHA. Tag-based references can be silently redirected by a compromised or maintainer-hijacked upstream repo without any change to your workflow file.

# VULNERABLE: tag-based action reference
- uses: actions/setup-python@v5     # can be redirected

# HARDENED: full commit SHA — immutable
- uses: actions/setup-python@42375ac2eaa873de89a0dd8a8c9dbb2a0cec3ae9  # v5.1.0

Path 2: ML supply chain compromise (AML.T0010 + AML.T0104)

AML.T0010 (ML Supply Chain Compromise) and AML.T0104 (AI Pipeline Tampering) describe two sub-paths:

Five hardening controls for AI CI/CD

1. Pin GitHub Actions to full commit SHAs

Replace every @v{N} tag reference with the corresponding full SHA. Use StepSecurity Harden-Runner or Botkube to automate this across all workflows. This closes the T1195.002 tag-redirect vector entirely.

2. Hash-verify all model artifacts

Store expected SHA-256 hashes of model artifacts in a signed manifest in your repo. Verify before loading:

import hashlib

def verify_model_artifact(path: str, expected_sha256: str) -> bool:
    h = hashlib.sha256()
    with open(path, "rb") as f:
        for chunk in iter(lambda: f.read(65536), b""):
            h.update(chunk)
    actual = h.hexdigest()
    if actual != expected_sha256:
        raise SecurityError(f"Model artifact hash mismatch: {actual} != {expected_sha256}")
    return True

Maps to NIST AI RMF MAP-1.6 (map AI system components) and NIST CSF DE.AE-02 (anomaly detection).

3. Scope workflow permissions to minimum required

Set permissions: read-all at the workflow level, then grant the minimum needed for each job. An AI pipeline that only reads model artifacts and runs inference needs zero write permissions.

permissions:
  contents: read       # minimum for checkout
  id-token: write      # only if OIDC auth is needed
  # NO: actions: write, packages: write, etc.

This limits the blast radius of T1195.002: even if a workflow step is compromised, it can't push to the repo or write to the package registry.

4. Behavioral regression testing on model updates

For every model update (fine-tune, quantization, version bump): run a behavioral probe battery — a fixed set of prompts with expected outputs — before promoting to production. A poisoned model will fail on the probes that specifically test for the backdoor trigger pattern.

This is the runtime defense against AML.T0010. Map each probe to an ATLAS technique: include injection probes (AML.T0054), jailbreak probes, and capability-regression probes. Log all results with model artifact hash for traceability.

5. Dependency hash locking with CI enforcement

Lock all Python dependencies to exact hashes in requirements.txt or pyproject.toml, and verify them in CI:

# requirements.txt with hash locking
anthropic==0.30.0 \
    --hash=sha256:abc123...
torch==2.2.0 \
    --hash=sha256:def456...

# CI check: fails if any dep hash mismatches
pip install --require-hashes -r requirements.txt

This addresses AML.T0104 at the Python dependency layer and aligns with NIST AI RMF MANAGE-2.2 (manage AI system risks throughout the lifecycle).

Framework mapping

ControlATT&CK / ATLASNIST AI RMFNIST CSF
SHA-pinned GitHub ActionsT1195.002 defenseGOVERN-5.2GV.OV-01
Model artifact hash verificationAML.T0010 defenseMAP-1.6DE.AE-02
Minimum workflow permissionsT1195.001 blast-radiusGOVERN-5.2GV.OV-01
Behavioral model regression testsAML.T0104 detectionMANAGE-2.2RS.MA-01
Dependency hash lockingT1195.002 defenseMANAGE-2.2DE.CM-01
AI CI/CD hardening checklist:
✅ All GitHub Actions pinned to full commit SHAs
✅ Model artifact SHA-256 verified before load
✅ Workflow permissions set to read-all minimum
✅ Dependency hash locking with --require-hashes enforced in CI
✅ Behavioral probe battery run on every model update
✅ Supply chain audit log retained — see verifiable audit methodology
Agentic AI Security series: Part 1 — API Key Security · Part 2 — LLM Guardrails · Part 3 — Supply Chain Attacks (this page) · Part 4 — Endpoint Detection · Part 5 — Memory Forensics

BlindOracle marketplace agents are supply-chain audited

Every agent on the marketplace holds a verifiable ERC-8004 passport. Supply chain integrity is part of the onboarding attestation.

See the marketplace

Related reading