NIST's recent update to SP 800-218 (the Secure Software Development Framework) and the accompanying Software Supply Chain Security Guidance has material implications for our artifact signing procedures, particularly around the provenance and integrity assertions we make. While the core mechanics of using Sigstore's `cosign` or similar tools remain stable, the expectations for the *content* and *attestations* we link to those signatures have evolved. The guidance now explicitly pushes for a stronger binding between the artifact, its SBOM, and a verifiable build provenance.

For runtime deployments of agents—which we must treat as high-risk due to their autonomy and tool-calling capabilities—this means our signing process can no longer be a simple signature on a container image. We must generate and sign in-toto attestations that form a verifiable chain. The critical update is the emphasis on *non-falsifiable* provenance. A simple GitHub Actions workflow trigger is insufficient; we need evidence of the build environment's security controls.

Consider our standard agent container build. The updated expectation is a signing routine that includes:

1. **SBOM Generation & Signing:** The SBOM (using CycloneDX for depth) must be generated *during* the build, not after, and signed as an attestation linked to the image digest.
```bash
# Example: Generate and sign SBOM attestation for an agent image
cosign attest --predicate agent-image.bom.cdx.json
--type cyclonedx
--key cosign.key
us-west2-docker.pkg.dev/my-project/agent-runtime/agent-core@sha256:...
```

2. **Provenance Attestation:** Using the SLSA generator for your CI (e.g., SLSA GitHub Generator) to produce a detailed provenance predicate, then attesting it.
```bash
# Attach the SLSA provenance attestation
cosign attest --predicate provenance.json
--type slsaprovenance
--key cosign.key
us-west2-docker.pkg.dev/my-project/agent-runtime/agent-core@sha256:...
```

3. **Runtime Verification:** Before an agent workload is launched, the verification must now check for the *presence and validity* of these specific attestations, not just the image signature. This moves us from "is this the right image?" to "was this built in the mandated secure way, and does its bill of materials match?".

The primary impact is operational: our CI/CD pipelines must be instrumented to produce these structured predicates, and our deployment/orchestration logic must verify them. For agent systems, where a poisoned dependency could lead to prompt injection or tool-misuse at scale, this granular, attestation-based verification is precisely the context isolation we need at the supply chain level. The question is whether your current signing pipeline outputs machine-verifiable claims about build integrity, or just a cryptographic seal on the final tarball.