Agentic AI Security, Part 1: Supply Chain, Golden Images, and Admission Control

This long-form article merges modules 1–3 of the Agentic AI Security Curriculum into one place: why digest pinning and private mirrors matter for agent and MCP platforms, how golden images and CI signing reduce drift, and how admission controllers enforce policy before workloads run. Each section links to the original module on ClawQL Docs for deeper diagrams and commands.

Supply Chain Security: Why Pinning Versions and Running Your Own Mirror Registry Matters

Original module on ClawQL Docs: Supply Chain Security: Why Pinning Versions and Running Your Own Mirror Registry Matters.

The software supply chain is the single largest and most dangerous attack surface in any production-grade agentic AI and MCP platform. A single compromised dependency, container image, or model weight can give an attacker persistent access to your cluster, your documents, your Memory 2.0 knowledge graph, and your users’ sensitive data.

This module explains why relying on public registries without controls is unacceptable for production deployments that include LLM agents, tools, and sensitive data and shows exactly how to build a secure, mirrored, and verifiable supply chain using Harbor, Cosign, Trivy, Syft, and strict pinning.

The Supply Chain Threat Landscape

Supply-chain attacks have become sophisticated and frequent:Dependency confusion attacks, where attackers publish malicious packages with the same name as your internal ones. Typosquatting and name collisions with popular packages. Compromised official base images on Docker Hub or GitHub Container Registry. Model weight poisoning through malicious Ollama or Hugging Face models containing hidden triggers. Living-off-the-land persistence once inside a container.

In an MCP-based or tool-calling agentic system, the impact is amplified. A compromised tool can execute arbitrary code in the sandbox, access the full document pipeline (Tika → Presidio → Paperless), or exfiltrate data through the intelligent gateway.

Core conclusion: You cannot outsource trust to the public internet. You must control every artifact from source to running pod.

Harbor as the Single Trust Root

A common enterprise pattern is to designate a private registry (for example Harbor, ECR with pull-through cache, or ACR) as the single source of truth for all artifacts: container images, Helm charts, model weight manifests, SBOMs, and Cosign signatures.

Harbor provides a private registry with replication, pull-through caching, built-in vulnerability scanning, and native support for SBOM storage. All production workloads should be configured to pull exclusively from that internal registry.

Key Harbor configuration principles:

Allowlist-only resolution enabled. Replication rules to mirror only approved upstream artifacts. All images and manifests must be signed before being accepted.

Allowlist-Only Resolution and Version Pinning

This is the foundational control.Never do this in production:Pulling directly from Docker Hub, npm, PyPI, or GitHub. Using floating tags such as :latest or :main. Allowing version ranges like ^1.2.0.

Always do this:Use exact digest pinning (e.g., nginx@sha256:abc123…). Or use a pinned version combined with mandatory Cosign signature verification.

Helm umbrella charts, GitOps, or an in-cluster operator often enforce equivalent rules through configuration flags such as:

security:
  supplyChain:
    registryMirror: "registry.internal.example"
    allowlistOnly: true
    requireDigest: true
    requireCosign: true

Scanning, SBOM Generation, and Signing

Every artifact that enters Harbor must be scanned and accompanied by a Software Bill of Materials (SBOM).

Tools commonly used in hardened CI/CD pipelines:

Trivy: OS and language vulnerability scanning. OSV-Scanner: Ecosystem-specific vulnerability checks. Syft: SBOM generation (SPDX and CycloneDX formats). Cosign: Keyless signing via Sigstore (no long-lived keys to manage or steal).

Typical CI pipeline step:

trivy image --exit-code 1 --severity CRITICAL,HIGH $IMAGE:latest
syft packages $IMAGE:latest -o spdx-json > sbom.spdx.json
cosign sign --keyless $IMAGE@${DIGEST}

All SBOMs are stored alongside their images in Harbor for long-term forensic and compliance needs.

Credential Leak Prevention

Even the best registry is useless if secrets enter the repository.Strong pipelines often use a two-layer defense:Gitleaks as a mandatory pre-commit hook plus CI gate. TruffleHog for full historical repository scans on every push or pull request.

These tools block AWS keys, Vault tokens, database credentials, and other secrets before they ever reach the main branch.

Practical implementation checklist

Mirror only approved upstream artifacts into Harbor on a nightly schedule. Enforce allowlist-only resolution and digest pinning everywhere in Helm charts and the Operator. Require Cosign keyless signing on all images and manifests. Scan every build with Trivy + OSV-Scanner and block merges on critical findings. Store SBOMs with every release for full traceability months later.

Automate as many of these controls as possible in your charts, operators, or policy-as-code repos.

Key Takeaways

Public registries represent an unacceptable risk for production agentic platforms. A private mirror registry (Harbor) with allowlist-only resolution is the foundation of all other security layers. Strict pinning, SBOMs, and Cosign signing turn every artifact into a verifiable, tamper-evident unit. Credential scanning prevents the most common initial compromise vector.

This supply chain foundation is the prerequisite for every subsequent module in this curriculum.

Next module: Building Golden Images – Automated Scanning, Hardening, and Distroless Pipelines.

Further reading (vendor-neutral)

These resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.

Building Golden Images: Automated Scanning, Hardening, and Distroless Pipelines

Original module on ClawQL Docs: Building Golden Images: Automated Scanning, Hardening, and Distroless Pipelines.

Once you have secured your supply chain with a private mirror registry (Module 1), the next critical layer is building golden images — minimal, hardened, immutable container images that form the foundation of every production agent or platform workload. This module explains how to create, scan, sign, and deploy golden distroless images with read-only root filesystems and full provenance.

Why Golden Distroless Images Matter

Most container images are far larger than necessary and contain unnecessary tools that increase the attack surface. A compromised package manager or shell in a running pod gives attackers easy persistence and lateral movement options.

A sensible hardening philosophy is simple: make images as small as possible. Remove everything that is not required at runtime. Make the root filesystem read-only. Verify every image before it ever runs.

This approach dramatically reduces the blast radius if a container is compromised.

Core Hardening Principles

1. Distroless Base Images
Use Google’s official distroless images or Chainguard distroless as the foundation. These contain only the bare runtime (e.g., glibc, ca-certificates, and your application binary) with no shell, no package manager, and no unnecessary utilities.2. Read-Only Root Filesystem
Set securityContext.readOnlyRootFilesystem: true on every pod. Combined with distroless, this prevents attackers from writing new binaries, installing tools, or modifying system files even if they achieve code execution.3. Multi-Stage Builds
Typical hardened pipelines use multi-stage Dockerfiles:dockerfile

Stage 1: Builder

FROM golang:1.24-alpine AS builder WORKDIR /app COPY . . RUN go build -ldflags="-s -w" -o /clawql-api ./cmd/api

Stage 2: Golden Runtime

FROM gcr.io/distroless/static-debian12 COPY --from=builder /clawql-api /usr/local/bin/clawql-api USER 65532:65532 ENTRYPOINT ["/usr/local/bin/clawql-api"]

4. Minimal Attack Surface

No shell (sh, bash) No package managers (apt, apk, yum) No debug tools (curl, wget, strace) Static binaries where possible

Automated Scanning and Signing

Every golden image goes through a mandatory pipeline before being promoted to Harbor:Build → Multi-stage Dockerfile Scan → Trivy (critical/high vulnerabilities blocked) + OSV-Scanner Generate SBOM → Syft (stored alongside the image) Sign → Cosign keyless signing via Sigstore Push → Only to internal Harbor with allowlist enforcement

Example CI pipeline snippet

- name: Build Golden Image
  run: |
    docker build -t $IMAGE:$TAG .
    trivy image --exit-code 1 --severity CRITICAL,HIGH $IMAGE:$TAG
    syft packages $IMAGE:$TAG -o spdx-json > sbom.spdx.json
    cosign sign --keyless $IMAGE@${DIGEST}
    docker push $IMAGE:$TAG

Golden image standards (checklist)

Production services should follow these rules:Base: gcr.io/distroless/static-debian12 or chainguard/static Non-root user (UID 65532) Read-only root filesystem enforced in Helm charts and Kyverno policies No writable layers except explicitly mounted volumes (e.g., /tmp if absolutely required, mounted as tmpfs) Full SBOM and Cosign signature required

The clawql-full-stack Helm chart includes these defaults under security.goldenImages.

Kyverno Policy Enforcement

A cluster-wide Kyverno policy enforces golden image standards at admission time:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-golden-images
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-distroless-and-readonly
      match:
        resources:
          kinds: ["Pod"]
      validate:
        message: "All pods in scope must use golden distroless images with read-only root filesystem"
        pattern:
          spec:
            securityContext:
              readOnlyRootFilesystem: true
            containers:
              - image: "registry.internal.example/*@sha256:*"

Key Takeaways

Golden distroless images with read-only root filesystems are one of the most effective ways to limit attacker capabilities. Multi-stage builds, automated scanning, SBOM generation, and Cosign signing ensure every image is minimal and verifiable. These images form the foundation for all subsequent controls (admission policies, sandboxing, and runtime protection). Never run images with shells or package managers in production MCP workloads.

This module builds directly on Module 1 (Supply Chain) and is the prerequisite for Module 3 (Cluster Admission Control).

Next module: Cluster Admission Control – Enforcing Image Signing and Policy at Deploy Time.

Further reading (vendor-neutral)

These resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.

Cluster Admission Control: Enforcing Image Signing and Policy at Deploy Time

Original module on ClawQL Docs: Cluster Admission Control: Enforcing Image Signing and Policy at Deploy Time.

With a secure supply chain and golden distroless images in place (Modules 1 and 2), the next layer is preventing non-compliant workloads from ever starting. Cluster admission controllers act as the final gatekeeper, rejecting unsigned, unverified, or insecure images before they are scheduled.

This module focuses on Kyverno as an admission controller and shows how to enforce image signing, golden image standards, and runtime policies at deploy time.

Why Admission Control Is Essential

Even with strong supply chain practices, misconfigurations or human error can still introduce risky workloads. Admission webhooks provide a last-line defense by inspecting pod specs in real time and rejecting them if they violate policy.In hardened deployments, this ensures:Only images from your private Harbor registry are allowed. Every image must be Cosign-signed and digest-pinned. Model weight verification and golden image rules are enforced. No pod can run with excessive privileges or writable root filesystems.

Kyverno verifyImages Admission Policies

Kyverno is a common choice as the primary admission controller. It supports cryptographic verification of container images and model artifacts.

Core Policy: Require Signed Images

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-signed-images
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: verify-cosign-signature
      match:
        resources:
          kinds: ["Pod"]
      validate:
        message: "All containers must be signed with Cosign and pulled from Harbor"
      imageVerify:
        - imageReferences: ["registry.internal.example/**"]
          verify:
            - type: "cosign"
              keyless:
                issuer: "https://token.actions.githubusercontent.com"
                subject: "https://github.com/clawql/*"

This policy rejects any pod using unsigned images or images from external registries.

Extending Verification to Model Weights

Model weights are a common blind spot. This module extends admission control to verify them via init containers:

# Example init container pattern enforced by policy
initContainers:
  - name: verify-weights
    image: registry.internal.example/clawql/weight-verifier:latest
    command:
      - cosign
      - verify-blob
      - --key
      - /etc/signing-keys/cosign.pub
      - --signature
      - /weights/manifest.sig
      - /weights/manifest.json
    volumeMounts:
      - name: model-weights
        mountPath: /weights

A dedicated Kyverno policy ensures every inference pod includes this verification step.

Cluster-Wide vs Namespace Exemptions

Many teams apply a cluster-wide default-deny posture with limited exemptions:openclaw and clawql namespaces: strict enforcement. Temporary exemption namespaces (e.g., for debugging) require explicit approval and short TTL. All exemptions are logged and reviewed quarterly.

Integration with Golden Images and Supply Chain

The admission policies work together with Guides 1 and 2:Only images built through the golden pipeline (distroless + read-only root) are allowed. Digest pinning and SBOM presence are validated. Non-compliant pods are rejected before scheduling, preventing drift.

Helm Chart Defaults

The clawql-full-stack chart enables these policies automatically when security.fullBundle: true.

Key Takeaways

Admission controllers like Kyverno provide the final enforceable gate before any workload runs. Cryptographic verification (Cosign) combined with allowlist policies eliminates unsigned or tampered images. Extending policies to model weights closes a critical gap missed by traditional container scanning. Cluster-wide enforcement with minimal exemptions maintains a strong, auditable security posture.

This module completes the build-time and deploy-time foundations. All later runtime protections (sandboxing, zero trust, MCP proxying) build on top of these admission guarantees.

Next module: Principle of Least Privilege – Scoped Identities and Limiting Blast Radius.

Further reading (vendor-neutral)

These resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.

Canonical curriculum and module-by-module versions: Agentic AI Security Curriculum (ClawQL Docs)

Related links