Comparison · Strix vs Sigstore
Strix vs Sigstore: build-time provenance vs runtime action provenance.
Sigstore signs build-time artifacts — what code shipped, from which source, signed by whom. Strix signs runtime actions — what an AI agent did, under what policy, approved by whom. Adjacent primitives at different points in the trust chain — most regulated AI deployments need both.
Answers the question: “Is Sigstore enough to attest AI agent behavior, or do I need Strix?”
Execution control for AI systems
Intercept, evaluate, sign every state-changing action.
Open-source standard for signing, verifying, and protecting software artifacts
The bottom line
Both products exist for a reason. Here's when each is the right call.
- You need to sign and verify runtime actions — what an AI agent did, when, under what policy.
- Your auditor wants action-level evidence with policy + actor + intent + context bound into the signature.
- You need three-state decisions (ALLOW / DENY / INTERCEPT) and single-use execution tokens.
- You need a capability registry + risk-tier-based policy + auditor-friendly canonical schema.
- You need EU AI Act Article 12 / 14 / 28 alignment for AI agent execution, not for code provenance.
- You need to sign software artifacts at build time — container images, npm packages, Python wheels.
- Your problem is supply-chain integrity — proving who built the code that shipped to production.
- You need a public transparency log of signing events (Rekor) integrated with CI/CD.
- You want keyless signing tied to OIDC identity (Fulcio).
- You're aligning to SLSA, in-toto, or CNCF / OpenSSF supply-chain standards at the build layer.
Feature-by-feature
Each row is a specific capability. We've tried to be honest — there are categories where the other side wins.
| Capability | Strix | Sigstore |
|---|---|---|
Point in the trust chain | Runtime — every AI agent action signed at execution time | Build time — software artifacts signed at release time |
What gets signed | 13-field canonical record: capability, actor, intent, context, policy version, evidence hash, proof-chain hash, etc. | Container image digest, package hash, build attestation, SLSA provenance |
Cryptography | Ed25519 + public JWKS (RFC 7517) | ECDSA (typically) + X.509 certificates via Fulcio + Rekor transparency log |
Public verifier | @strixgov/verifier on npm — offline, no Strix account | cosign verify — offline, no Sigstore account |
Public transparency log | /log page (in roadmap); JWKS published | Rekor — production, searchable, append-only, billions of entries |
Three-state decisions | ALLOW / DENY / INTERCEPT built in | Not in scope — signing happens or it doesn't |
Single-use execution tokens | HMAC-signed, atomic redemption, revocable | Not in scope |
Capability registry | Yes — risk-tiered, queryable | Not in scope |
Foundation status | Applying to LF AI & Data sandbox | OpenSSF graduated — vendor-neutral, broad maintainer base |
Adoption maturity | v1.9.4 published May 15, 2026; growing | Production at scale — millions of weekly verifies; npm, Python, GitHub all integrated |
AI agent action coverage | First-party — designed for this exact problem | Not in scope — Sigstore doesn't address runtime AI behavior |
Compliance mapping (AI-specific) | NIST AI RMF, EU AI Act Art. 12/14/28, AARM mapped end-to-end | SLSA, in-toto, supply-chain — different compliance domain |
Open source | Permissive OSS; verifier + tool-gateway on npm | Apache 2.0; OpenSSF-graduated; vendor-neutral |
When to use which
Concrete scenarios. If your situation looks like one of these, the recommendation should be obvious.
I need to attest that the container image running in production was built from a specific source commit by a known identity.
That's exactly Sigstore's domain. Cosign + Fulcio + Rekor are purpose-built for build-time provenance. Strix doesn't address this problem.
I need to attest that an AI agent's action was policy-approved, by which actor, under what intent, with what context — at the moment it ran.
Sigstore would sign the binary that contains the AI agent code. Strix signs the action the agent took. Different points in the trust chain.
We're a federal contractor with SLSA Level 3 supply-chain requirements AND an EU AI Act Article 12 record-keeping obligation for our AI agents.
Run them together. Sigstore (or in-toto / SLSA) at the build layer — what code shipped. Strix at the runtime layer — what the AI did. Same trust philosophy, different points in the chain.
We're an open-source project that publishes container images and we want consumers to verify image provenance.
Sigstore cosign is the standard. Strix doesn't compete here.
My auditor accepts SLSA provenance for the build but wants action-level evidence for what the running AI did. SLSA doesn't cover that.
Correct. SLSA is build-time. Action-level provenance is what Strix produces — same cryptographic discipline, different scope.
Common questions
Why doesn't Strix use Sigstore as the signing primitive?+
Two reasons. First, Sigstore's keyless model (Fulcio short-lived X.509 certs tied to OIDC) is designed for build-time human-identity signing — not for application-managed runtime signing where the signing key is owned by an organization and the canonical record format is locked. Second, Strix's canonical 13-field payload is tightly scoped to AI agent execution and the verifier is a small, offline, npx-installable surface — adding the full Sigstore client stack would expand the verifier's surface significantly. The cryptographic discipline (Ed25519 with public-key publishing) is similar in spirit; the operational shape is different.
Does Strix have a Rekor-equivalent transparency log?+
Roadmap. The /log page (in flight) is the public-facing transparency surface. A federated Merkle-inclusion-proof log (Rekor-style) is a discrete engineering project tracked at docs/security/SIGNING-TRANSPARENCY-LOG-DECISION.md — explicit decision pending.
Why publish a comparison with Sigstore?+
Sigstore is the most-cited adjacent primitive in our category-position doc. Auditors reading our public materials reach for the comparison naturally. The honest framing is: adjacent primitives at different points in the chain; most regulated AI deployments need both.
Will Strix integrate with Sigstore?+
Practical shape: a Strix evidence record could include a Sigstore-signed build attestation hash in its context block — proving 'this AI agent action was taken by a binary whose build provenance is attested by cosign + Rekor.' That's the chain we'd build if a customer's audit story crossed both domains.
What about in-toto / SLSA / Witness?+
All build-time supply-chain primitives. in-toto is a framework, SLSA is a maturity model, Witness (TestifySec) is an in-toto implementation. None overlap with Strix's runtime action scope — they sit at the build layer where Sigstore sits.
Production governance. Zero bypasses. One evidence trail.
Strix is running in production today — 127 capabilities defined, every decision recorded. See the governance kernel in action in 15 minutes.
Currently in private beta — limited spots available.
npx @strixgov/verifier@latest 5686