How Rossoctl traces signed AI agent cards back to their build pipelines
Red Hat’s upstream prototype verifies Sigstore bundles during Kubernetes reconciliation, complementing SPIFFE runtime identity without yet blocking unsigned legacy cards.
Red Hat engineers are testing a two-layer trust model for AI agent cards: Sigstore provenance records which build pipeline produced a card, while SPIFFE/SPIRE checks the identity of the workload serving it at runtime.
The distinction addresses a specific gap in agent-to-agent systems. A legitimate Kubernetes workload can still serve a card that was replaced in a registry, artifact store or ConfigMap after the build. Runtime identity authenticates the workload; it does not establish the origin of the card’s claims, endpoints or tool definitions.
The binding starts in CI
In the prototype, a GitHub Actions workflow requests an OIDC token and uses Sigstore’s Fulcio certificate authority to obtain a short-lived signing certificate. The workflow signs the agent card through the sigstore-a2a library and attaches SLSA provenance naming the source repository, commit and workflow. The signature, certificate and provenance are recorded through Rekor’s transparency log.
That creates the build-time binding: a verifier can check not only that the card has not changed, but also whether it came from the repository and workflow allowed by policy. The design avoids a long-lived signing key that a platform team would otherwise have to store and rotate.
Rossoctl verifies during reconciliation
Rossoctl, an upstream Kubernetes operator for AI agent lifecycles, performs the corresponding checks when it reconciles an AgentCard resource. If the document contains a Sigstore bundle, the controller uses sigstore-go to verify the Fulcio certificate and signature, match the signer against the expected repository and workflow, confirm the Rekor entry, and extract the SLSA source and commit metadata.
Before digest verification, the controller canonicalizes the card’s JSON with RFC 8785 so formatting differences do not alter the hash. It then writes verification details—including the signer identity and Rekor log index—to the AgentCard custom resource status. That gives platform teams an in-cluster audit surface connecting the deployed card to its build record.
The Sigstore check does not replace Rossoctl’s SPIFFE/SPIRE layer. SPIRE establishes whether the running workload is entitled to its cryptographic identity; Sigstore establishes whether an approved pipeline produced the card. The prototype keeps those questions independent because either layer can be valid while the other is compromised.
What remains experimental
Red Hat’s rollout model is audit-first. With Sigstore audit mode enabled, failed checks appear in logs, Kubernetes events and resource status but do not stop activation. When enforcement is enabled, a present-but-invalid bundle leaves the card not ready. A card with no bundle is still allowed, permitting incremental migration of older pipelines.
Verification also runs in the reconciliation loop rather than at admission time. The authors describe admission rejection, private Sigstore deployments for air-gapped environments, image-signature checks through SPIRE and composed attestors as possible follow-on work. Capability validation is separate: provenance can show who built a card, but not whether an agent can actually perform every capability it declares.
The work is an upstream Rossoctl experiment. Red Hat explicitly says the technology is under active development and is neither a supported product feature nor a promise of future inclusion. For platform teams, its present value is as a concrete design for joining CI provenance, Kubernetes reconciliation and runtime workload identity without pretending that any one of those controls answers the whole agent-trust problem.
sources
comments · 0