Supply-Chain Security for Agent Sandboxes

"Your agent is only as secure as the least audited dependency in its container image."

Guard, Supply-Chain-Aware AI Agent

1. Why Agent Sandboxes Need Supply-Chain Hardening

Agentic AI systems differ from traditional software in a critical way: the agent decides at runtime which packages to install, which APIs to call, and which code to execute. A coding agent asked to "build a data visualization" might install matplotlib, pandas, seaborn, and a dozen transitive dependencies. A research agent might pull a specialized NLP library the developer never anticipated. Each installed package is an attack surface: it might contain a known vulnerability (CVE), a malicious post-install script, or a dependency confusion payload that hijacks a private package name.

Traditional applications lock their dependencies at build time, audit them once, and deploy a fixed artifact. Agent sandboxes, by contrast, assemble their dependency set dynamically. This means the security posture of an agent sandbox can change between one task and the next. A sandbox that was safe for yesterday's task might be compromised by today's task if the agent installs a package with a newly disclosed vulnerability. Supply-chain hardening provides the tooling to detect, prevent, and recover from these risks.

The threat is not theoretical. In 2024, the Trivy project itself experienced a CI compromise where a malicious pull request attempted to inject code into the build pipeline. Dependency confusion attacks (where an attacker publishes a malicious package to PyPI or npm using the same name as a private internal package) have targeted organizations including Apple, Microsoft, and Tesla. For agent systems that install packages on behalf of users, these attacks are especially dangerous because the agent, not the developer, is making the installation decision.

2. SBOM Generation with Syft

A Software Bill of Materials (SBOM) is a complete inventory of every software component in a container image or filesystem. It lists each package, its version, its source, and its license. SBOMs serve two purposes in agent security: (1) they provide the input for vulnerability scanners (you cannot scan what you have not inventoried), and (2) they create an audit trail of exactly what software was present in the sandbox when a task executed.

Syft (from Anchore) is the standard open-source tool for generating SBOMs. It supports multiple output formats (SPDX, CycloneDX, Syft JSON) and can scan container images, directories, and archives. Syft detects packages from multiple ecosystems: APK (Alpine), APT (Debian/Ubuntu), RPM (RHEL/Fedora), pip (Python), npm (Node.js), Go modules, Rust crates, and Java JARs.

#!/usr/bin/env bash
# Generate an SBOM for the agent-runner container image

# Install Syft (one-time setup)
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Scan the container image and produce a CycloneDX JSON SBOM
syft packages registry.example.com/agent-runner:latest \
 -o cyclonedx-json \
 > sbom-agent-runner.cdx.json

# Inspect the SBOM: count packages by ecosystem
echo "Package counts by type:"
cat sbom-agent-runner.cdx.json | \
 python3 -c "
import json, sys, collections
bom = json.load(sys.stdin)
types = collections.Counter(
 c.get('purl', '').split('/')[0].replace('pkg:', '')
 for c in bom.get('components', [])
 if c.get('purl')
)
for t, count in types.most_common():
 print(f' {t}: {count}')
"

For agent sandboxes with dynamic dependencies, generate the SBOM after the agent installs its packages but before the agent executes the task code. This captures the complete dependency set for that specific task. Store the SBOM alongside the task execution log so you can retrospectively audit which packages were present when a particular task ran.

3. Vulnerability Scanning with Trivy

Trivy (from Aqua Security) is a comprehensive vulnerability scanner for containers, filesystems, git repositories, and Kubernetes clusters. Given an SBOM or a container image, Trivy matches each package against vulnerability databases (NVD, GitHub Advisory Database, OS-specific advisories) and reports known CVEs with severity ratings (CRITICAL, HIGH, MEDIUM, LOW). Trivy also detects misconfigurations (e.g., running as root, exposed secrets) and license violations.

#!/usr/bin/env bash
# Scan the agent-runner image for vulnerabilities

# Scan container image directly
trivy image registry.example.com/agent-runner:latest \
 --severity CRITICAL,HIGH \
 --format json \
 --output trivy-report.json

# Alternatively, scan from an existing SBOM
trivy sbom sbom-agent-runner.cdx.json \
 --severity CRITICAL,HIGH \
 --format table

# Scan a filesystem (useful for scanning the sandbox after package install)
trivy fs /sandbox/workspace \
 --scanners vuln,secret,misconfig \
 --severity CRITICAL,HIGH

# Exit code 1 if vulnerabilities found (useful for CI gates)
trivy image registry.example.com/agent-runner:latest \
 --exit-code 1 \
 --severity CRITICAL

For agent sandboxes, integrate Trivy scanning at two points. First, scan the base image during CI to ensure it ships without known vulnerabilities. Second, scan the sandbox filesystem after the agent installs packages but before task execution. If the post-install scan finds a critical vulnerability, the sandbox runtime can block execution and return an error to the user, explaining that a required package has a known security issue.

import subprocess
import json

def scan_sandbox(workspace_path: str) -> dict:
 """Scan the agent sandbox workspace for vulnerabilities after package install."""
 result = subprocess.run(
 [
 "trivy", "fs", workspace_path,
 "--scanners", "vuln,secret",
 "--severity", "CRITICAL,HIGH",
 "--format", "json",
 "--quiet",
 ],
 capture_output=True,
 text=True,
 )

 report = json.loads(result.stdout) if result.stdout else {"Results": []}

 # Aggregate findings
 critical = []
 high = []
 for target in report.get("Results", []):
 for vuln in target.get("Vulnerabilities", []):
 entry = {
 "id": vuln["VulnerabilityID"],
 "package": vuln["PkgName"],
 "installed": vuln["InstalledVersion"],
 "fixed": vuln.get("FixedVersion", "not yet"),
 "title": vuln.get("Title", ""),
 }
 if vuln["Severity"] == "CRITICAL":
 critical.append(entry)
 else:
 high.append(entry)

 return {
 "safe": len(critical) == 0,
 "critical_count": len(critical),
 "high_count": len(high),
 "critical": critical,
 "high": high,
 }

# Usage in the sandbox runtime
scan = scan_sandbox("/sandbox/workspace")
if not scan["safe"]:
 raise SecurityError(
 f"Sandbox blocked: {scan['critical_count']} critical vulnerabilities found. "
 f"First: {scan['critical'][0]['id']} in {scan['critical'][0]['package']}"
 )

4. Image Signing and Verification with Cosign

Vulnerability scanning tells you whether a container image contains known vulnerabilities. Image signing tells you whether the image is the one you built, or whether it was tampered with in transit or at rest. Cosign (from the Sigstore project) provides keyless signing and verification of container images using short-lived certificates issued by Fulcio and recorded in the Rekor transparency log. "Keyless" means there is no long-lived signing key to manage; instead, Cosign uses OIDC identity (e.g., your CI system's workload identity) to obtain an ephemeral signing certificate.

#!/usr/bin/env bash
# Sign and verify the agent-runner container image with Cosign

# Sign the image (keyless mode, uses OIDC identity from CI)
cosign sign registry.example.com/agent-runner:latest

# Verify the signature, checking that it was signed by the expected identity
cosign verify registry.example.com/agent-runner:latest \
 --certificate-identity "https://github.com/yourorg/agent-runner/.github/workflows/build.yml@refs/heads/main" \
 --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

# Attach the SBOM as an attestation to the image
cosign attest \
 --predicate sbom-agent-runner.cdx.json \
 --type cyclonedx \
 registry.example.com/agent-runner:latest

# Verify the SBOM attestation
cosign verify-attestation \
 --type cyclonedx \
 --certificate-identity "https://github.com/yourorg/agent-runner/.github/workflows/build.yml@refs/heads/main" \
 --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
 registry.example.com/agent-runner:latest

In the agent sandbox deployment pipeline, configure the container runtime (Kubernetes admission controller, Docker content trust, or a custom policy engine) to reject any image that lacks a valid Cosign signature. This prevents deployment of unsigned or tampered images, even if an attacker gains write access to the container registry.

5. The SLSA Framework: Provenance and Build Integrity

SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a framework for ensuring the integrity of software artifacts throughout the build and delivery process. SLSA defines four levels of increasing assurance:

• SLSA Level 1: Build process is documented (provenance exists but is not verified).
• SLSA Level 2: Build is executed on a hosted platform with signed provenance (tamper-evident).
• SLSA Level 3: Build is executed on a hardened platform with non-falsifiable provenance (tamper-resistant). The build environment is ephemeral and isolated.
• SLSA Level 4: Hermetic builds with two-person review of all changes. The highest assurance level, requiring reproducible builds and verified source provenance.

For agent sandbox images, SLSA Level 3 is a practical target. GitHub Actions and Google Cloud Build both support SLSA Level 3 provenance generation through the slsa-github-generator and slsa-verifier tools. The provenance document records which source repository was built, which commit was checked out, which builder was used, and which build steps were executed. This document is signed and attached to the container image as an in-toto attestation.

# .github/workflows/build-agent-runner.yml
# GitHub Actions workflow with SLSA Level 3 provenance

name: Build Agent Runner
on:
 push:
 branches: [main]

jobs:
 build:
 runs-on: ubuntu-latest
 permissions:
 contents: read
 packages: write
 id-token: write # Required for keyless signing

 steps:
 - uses: actions/checkout@v4

 - name: Build container image
 run: |
 docker build -t registry.example.com/agent-runner:${{ github.sha }} .

 - name: Generate SBOM
 uses: anchore/sbom-action@v0
 with:
 image: registry.example.com/agent-runner:${{ github.sha }}
 format: cyclonedx-json
 output-file: sbom.cdx.json

 - name: Scan for vulnerabilities
 uses: aquasecurity/trivy-action@master
 with:
 image-ref: registry.example.com/agent-runner:${{ github.sha }}
 severity: CRITICAL,HIGH
 exit-code: "1"

 - name: Push image
 run: docker push registry.example.com/agent-runner:${{ github.sha }}

 - name: Sign image and attach SBOM
 uses: sigstore/cosign-installer@v3
 - run: |
 cosign sign registry.example.com/agent-runner:${{ github.sha }}
 cosign attest --predicate sbom.cdx.json --type cyclonedx \
 registry.example.com/agent-runner:${{ github.sha }}

 provenance:
 needs: build
 uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v2.0.0
 with:
 image: registry.example.com/agent-runner
 digest: ${{ needs.build.outputs.digest }}

6. CI Hardening: Immutable Images and Pinned Dependencies

Beyond scanning and signing, the CI pipeline itself must be hardened against supply-chain attacks. Key practices for agent sandbox images include:

Immutable base images. Pin the base image to a specific digest, not a mutable tag. FROM python:3.12-slim@sha256:abcd1234... ensures that every build uses the exact same base image. A tag like python:3.12-slim can be updated by the image publisher at any time, silently introducing new packages or vulnerabilities.

Pinned dependencies. Lock all Python dependencies with pip freeze or a lockfile tool (pip-tools, Poetry, uv). Lock all system packages with version-pinned apt-get install commands. This ensures reproducible builds: the same Dockerfile always produces the same image, regardless of when or where it is built.

Minimal images. Use distroless or Alpine-based images that contain only the runtime dependencies. Fewer packages mean a smaller attack surface. An agent-runner image does not need a compiler, a shell, or system administration tools. If the agent needs to install packages at runtime, provide a curated set of allowed packages rather than unrestricted pip access.

# Dockerfile for a hardened agent-runner sandbox
# Stage 1: Build dependencies in a full image
FROM python:3.12-slim@sha256:f5a1c3e5b2d8... AS builder

WORKDIR /build
COPY requirements.lock .
RUN pip install --no-cache-dir --target=/deps -r requirements.lock

# Stage 2: Runtime with minimal base
FROM gcr.io/distroless/python3-debian12@sha256:a9b8c7d6...

# Copy only the installed packages, no build tools
COPY --from=builder /deps /deps
ENV PYTHONPATH=/deps

# Copy the sandbox runtime code
COPY sandbox_runtime/ /app/

# Run as non-root
USER nonroot:nonroot

# No shell available in distroless; exec form only
ENTRYPOINT ["python3", "/app/main.py"]

7. Security Scanning on Model Hubs

Supply-chain security for agent systems extends beyond code packages to the models themselves. Model files, particularly those serialized with Python's pickle format, can contain arbitrary executable code that runs during deserialization. A malicious model file downloaded from a public hub can execute a reverse shell, install a backdoor, or exfiltrate environment variables the moment it is loaded with torch.load() or pickle.load(). This risk applies to any agent system that downloads models at runtime or uses community-contributed model weights.

Hugging Face's malware scanning infrastructure provides the first line of defense. Every file uploaded to the Hugging Face Hub is scanned for known malware signatures, suspicious pickle opcodes, and embedded executable payloads. Models flagged as unsafe are quarantined and marked with a warning banner. Hugging Face also promotes the safetensors format, which stores only tensor data (no executable code) and is immune to pickle-based deserialization attacks. When possible, always prefer safetensors over pickle-based formats (.bin, .pt, .pkl) for model weights.

For defense beyond what the hub provides, third-party scanning tools offer deeper inspection and can be integrated into your own CI pipeline or sandbox runtime:

Dependency hygiene for model deployments. Pin model versions by commit hash or revision ID, not by mutable branch names like main. Verify file integrity with SHA-256 checksums after download. Maintain a Software Bill of Materials (SBOM) that includes model files alongside code dependencies, documenting the exact model revision, its source repository, and the scanner results at ingestion time. For organizations with strict compliance requirements, generate hash attestations for every model artifact entering production.

Continuous monitoring post-deployment. Model drift detection serves a dual purpose: it flags both performance degradation and potential security compromise. If a model's output distribution shifts unexpectedly (without corresponding changes in input distribution or model version), this may indicate that the model file was tampered with, that a dependency was silently updated, or that the serving infrastructure was compromised. Integrate drift detection metrics into your observability stack alongside traditional security monitoring. Alert on both statistical drift (KL divergence, PSI) and behavioral drift (unexpected tool calls, new output patterns) as potential security signals.

8. Threat Model: Real-World Supply-Chain Incidents

Understanding real-world attacks helps motivate the defenses covered in this section. The following incidents illustrate the diversity of supply-chain threats that affect agent sandboxes.

Dependency confusion (2021). Security researcher Alex Birsan demonstrated that major companies (Apple, Microsoft, PayPal, Tesla, and others) were vulnerable to dependency confusion attacks. The attack exploits package managers that check public registries before private ones. By publishing a malicious package to PyPI with the same name as an internal package, an attacker can trick pip into installing the public (malicious) version. For agent systems that install packages by name, this attack is especially relevant: the agent may request a package that matches an internal name, and the public registry returns a malicious payload.

Event-Stream compromise (2018). An attacker gained maintainer access to the popular npm package event-stream (downloaded 2 million times per week) and injected a targeted backdoor that stole cryptocurrency wallet credentials. The malicious code was hidden in a new dependency (flatmap-stream) added in a minor version update. This incident demonstrates why SBOM tracking and dependency auditing are essential: the malicious dependency appeared as a routine transitive addition that would not trigger any version-pinning violation.

Codecov CI compromise (2021). Attackers modified the Codecov Bash Uploader script (used in thousands of CI pipelines) to exfiltrate environment variables, including CI secrets, API tokens, and signing keys. This is a direct threat to agent sandbox build pipelines: if the CI pipeline is compromised, the attacker can inject malicious code into the agent-runner image, and the signed provenance will attest to the compromised build as legitimate.

Lab: Hardened Agent-Runner Container

#!/usr/bin/env bash
# verify-agent-runner.sh
# Run this before deploying the agent-runner to production

set -euo pipefail

IMAGE="registry.example.com/agent-runner:latest"
EXPECTED_IDENTITY="https://github.com/yourorg/agent-runner/.github/workflows/build.yml@refs/heads/main"
EXPECTED_ISSUER="https://token.actions.githubusercontent.com"

echo "Step 1: Verify image signature..."
cosign verify "$IMAGE" \
 --certificate-identity "$EXPECTED_IDENTITY" \
 --certificate-oidc-issuer "$EXPECTED_ISSUER"
echo "Signature verified."

echo "Step 2: Verify SBOM attestation..."
cosign verify-attestation "$IMAGE" \
 --type cyclonedx \
 --certificate-identity "$EXPECTED_IDENTITY" \
 --certificate-oidc-issuer "$EXPECTED_ISSUER" \
 | jq -r '.payload' | base64 -d | jq '.predicate' > verified-sbom.json
echo "SBOM attestation verified. $(jq '.components | length' verified-sbom.json) components found."

echo "Step 3: Scan for vulnerabilities..."
trivy image "$IMAGE" --severity CRITICAL,HIGH --exit-code 1
echo "No critical or high vulnerabilities found."

echo "All checks passed. Image is safe for deployment."

Exercises