SLSA provenance is the answer to the question "can you prove where this artifact came from." It is a cryptographically signed attestation about a build event — what source was used, what builder ran, what inputs went in, what outputs came out. Without SLSA, supply chain security is a promise. With SLSA, it is a receipt you can verify in the field, years after the build. The whole mechanism rests on actually verifying the signature, parsing the attestation against its schema, and using the structured fields to answer security questions. Griffin AI does all three. Mythos-class tools do none of them well, and the result is a product that talks about provenance without participating in it.
What SLSA provenance contains
A SLSA provenance document follows the in-toto statement schema with a specific predicate for build provenance. The fields are precise: subject (the artifact being described, with its digest), predicate_type (the schema URI), builder (the identity of the system that ran the build), buildType (the kind of build), invocation (the parameters the builder received), buildConfig (the steps the builder executed), metadata (timing, completeness flags, reproducibility claims), and materials (the inputs to the build with their own digests). Each of these fields has a defined shape in the SLSA spec. Griffin AI's parser implements the spec. A Mythos-class tool treats the document as JSON it can describe in English. The difference shows up the moment you try to use provenance for verification rather than exposition.
Signature verification is a capability, not a description
SLSA provenance is typically signed with Sigstore using a short-lived certificate issued by Fulcio. Verification means checking the signature against the certificate, checking the certificate against the Rekor transparency log, and checking that the signing identity matches an expected workload identity. Griffin AI performs all three checks at ingestion time and records the verification outcome as a property on the provenance node. If the signature fails, the provenance is flagged as unverified and the downstream reasoning knows not to trust it. A Mythos-class tool describes the provenance as if it were verified because verification is a cryptographic operation and the tool is a language model. Describing a signature is not verifying it, and the difference becomes material the first time an attacker ships a forged attestation.
The materials graph and dependency confusion
The materials field in SLSA provenance lists the inputs to the build, each with its own URI and digest. For a container build, materials typically include the base image, every layer source, every build-time dependency, and the source code itself. Griffin AI parses materials into a graph of input edges pointing to the built artifact, which means you can ask "show me every artifact in production that was built from a materials set containing a specific bad input." That is a graph query over the provenance layer. Mythos-class tools cannot answer that question because materials are a list in their representation, not a graph, and the cross-artifact join is impossible. When an upstream input turns out to be compromised — XZ Utils 5.6.0 being the canonical recent example — the only way to find every build that consumed it is a structured materials query.
Builder identity and why it matters
The builder.id field in SLSA provenance is supposed to identify the specific builder instance that produced the artifact. For GitHub Actions this is a workflow URL at a specific ref. For Google Cloud Build it is a build project and trigger ID. For Tekton it is a pipeline run identifier. Griffin AI maps these to the trust policy configured by the security team — "builds from our GitHub organization's release workflow on main are trusted; builds from forks are not." A Mythos-class tool reads the builder ID as a string and has no mechanism to evaluate trust. The language model might produce prose that says "this was built by GitHub Actions," which is not a trust decision. Structured evaluation against a trust policy is.
The SLSA level and what it actually claims
SLSA defines four levels of increasing rigor. Level 1 is documented build. Level 2 adds version control and hosted builds. Level 3 adds hardened builds and non-forgeable provenance. Level 4 adds two-person review and hermetic builds. These levels are claims about the build environment, and a provenance document's level claim is meaningful only if the builder actually enforces the requirements of that level. Griffin AI maintains a policy that says "accept SLSA Level 3 claims only from approved builders with verified hardening," and provenance that fails this check is downgraded. Mythos-class tools report the claimed level as prose without evaluating whether the builder supports that level, which means an attacker could claim Level 3 in their attestation and the tool would report it as Level 3.
Hermetic builds and reproducibility
Level 4 SLSA includes hermetic build requirements — the build must declare its inputs exhaustively and cannot fetch anything at build time that is not in the materials list. Griffin AI checks for hermeticity indicators in the metadata and flags attestations that claim hermeticity without the supporting fields. Reproducibility claims are similarly verifiable — if two independent builds of the same source produce different output digests, the reproducibility claim is false. A Mythos-class tool reports the claimed hermeticity as an attribute and does not cross-check it. This is the recurring pattern: the language model surfaces the claim, the engine verifies it.
Attestation chains across the supply chain
A mature supply chain has provenance chains, not individual attestations. The base image has provenance. The intermediate image built on top has provenance pointing to the base image's digest. The final image has provenance pointing to the intermediate. Griffin AI walks these chains at ingestion, verifying each signature and each materials reference as it goes. If any link in the chain fails, the terminal artifact is marked as having a broken provenance chain. A Mythos-class tool, when shown a chain, typically describes the outer attestation and ignores the chain structure because chain-walking is a graph operation. Broken chains pass unnoticed.
The GitHub Artifact Attestations and Sigstore bundles
GitHub now emits artifact attestations as Sigstore bundles — a packaging format that combines the attestation, the signing certificate, the transparency log inclusion proof, and the timestamp into a single artifact. Griffin AI's ingestion extracts each component of the bundle and verifies them against the respective trust anchors. A Mythos-class tool reads the bundle as opaque JSON and summarizes what it can see. The bundle format was designed specifically to make verification tractable for machines, and a tool that does not perform that verification is providing the user with false assurance.
The policy surface that provenance enables
Once provenance is structurally ingested, policy becomes trivial. "Require SLSA Level 3 for production deployments." "Reject artifacts whose builder is not in the approved list." "Flag deployments whose provenance chain has an unverified link." "Alert when an artifact ships without any provenance at all." Each of these is a one-line policy evaluated against typed fields. Griffin AI exposes the full policy surface. Mythos-class tools, because their provenance representation is prose, cannot enforce field-level policy and default to summary outputs that a human reviews manually. Manual review does not scale to the deployment cadence of a modern platform.
What to verify before claiming SLSA compliance
Pick a deployed artifact from your production pipeline. Find its SLSA provenance. Ask your AI tool five questions: is the signature valid, is the builder identity trusted, does the materials list include any unexpected inputs, is the provenance chain complete back to source, and does the claimed SLSA level match the builder's actual capabilities. Griffin AI answers each with a verified boolean and supporting evidence. Mythos-class tools produce prose that sounds like an answer. Compare the two outputs against the ground truth — the Sigstore verification tool plus the Rekor CLI — and decide which architecture you want enforcing your supply chain posture.
Provenance is a receipt, not an essay
The SLSA standard was designed around verifiability. Its value is cryptographic, not narrative. Any tool that reads provenance without verifying signatures, walking chains, and evaluating trust policies is participating in theater. Griffin AI does the mechanical work. That is why formal inventory inputs produce formal outputs in the provenance domain as clearly as they do anywhere in the SBOM ecosystem.