Rossoctl binds AI agent cards to CI provenance with Sigstore
The upstream prototype combines build-time attestations with SPIFFE workload identity, while leaving unsigned legacy cards in a migration path.
Red Hat’s Emerging Technologies team has described an upstream Rossoctl integration that signs AI agent cards in CI and verifies their provenance when the operator reconciles them on Kubernetes. The work targets a gap left by runtime workload identity: a legitimate pod can still serve an agent card that was altered after its build pipeline produced it. The project is pre-product engineering, not a supported Red Hat feature.
Two trust checks for one artifact
The engineering post separates two questions. SPIFFE/SPIRE establishes which workload is serving an agent card at runtime. Sigstore establishes which CI workflow created that card and whether the artifact changed afterward.
In the prototype flow, GitHub Actions uses its OIDC identity to obtain a short-lived Fulcio certificate. The pipeline signs the card through the sigstore-a2a library, attaches SLSA provenance such as the source repository, commit and workflow, and records the signing event in Rekor. The operator then verifies the bundle with sigstore-go, checks the expected repository and workflow identity, confirms the Rekor entry and exposes the signer and log index in the AgentCard custom resource status.
The implementation canonicalizes the card with JSON Canonicalization Scheme before digest verification. That matters because equivalent JSON can otherwise produce different byte sequences and therefore different hashes.
Migration favors observation before blocking
Rossoctl’s rollout design distinguishes an invalid signed card from a card that has not yet adopted signing. In audit mode, verification failures become logs, Kubernetes events and status conditions without preventing activation. When enforcement is enabled, a card with a present but invalid Sigstore bundle is marked not ready. Cards with no bundle remain usable, allowing teams to add signing pipeline by pipeline.
That choice lowers immediate migration risk, but it also means enforcement is not complete until organizations separately remove or constrain the unsigned-card path. The reconciler-based check also operates after the resource exists rather than rejecting it through an admission webhook.
What platform teams should take from it
The useful pattern is the split between build provenance and workload identity. Signing an agent card does not prove that the running workload is legitimate; workload identity does not prove that its declared tools and routing metadata came from an approved pipeline. Rossoctl’s experiment composes both controls and leaves capability validation—the question of whether an agent actually behaves within its claims—as a separate layer.
The Rossoctl operator remains upstream work. The Red Hat post explicitly says the technology is under active development and is neither part of a supported product nor a roadmap commitment.
sources
- Who really built that? Supply-chain provenance for AI agent identitynext.redhat.com
- Rossoctl operatorgithub.com
comments · 0