Summary
As AI- and agent-generated code enters software supply chains, existing provenance (SLSA build provenance, commit signing) does not capture how an artifact was produced by an AI pipeline: human-vs-AI authorship, the model, the prompt fingerprint, the acceptance contract that was checked, and the human sign-offs.
Some projects are responding by banning AI contributions outright for lack of provenance — e.g. QEMU's contribution policy, and NetBSD treating LLM output as presumed-tainted. A neutral, verifiable attestation format could let projects govern AI contributions instead of banning them.
This issue shares an early approach with the OpenSSF community to gather feedback, spark discussion, and find sensible next steps.
Related work
The openfab/generation predicate builds on existing supply-chain provenance: in-toto attestations and DSSE, SLSA build provenance,SPDX/CycloneDX SBOMs, and the TODO Group's Agentic AI working group on AI provenance. The gap it targets is the missing piece — AI-vs-human authorship plus the model/prompt/acceptance context, as a first-class signed predicate.
A concrete starting point
OpenFab — Apache-2.0 and vendor-neutral — has defined a draft in-toto predicate, openfab/generation, as a basis for discussion:
Carried in a DSSE-signed in-toto Statement and bound to the artifact's file digests, the predicate records:
- per-file / per-range human-vs-AI authorship
- the model and prompt fingerprint (a sha256, not the prompt text)
- the embedded acceptance contract — the exact checks — so verification is
forge-agnostic and works offline
- N-of-M human sign-offs (a behavioral gate)
It is positioned as a sibling to SLSA provenance, not a part of it.
Question for the TAC
Is there interest in an "AI authorship / AI-BOM" attestation predicate as a community-governed standard? The predicate design and the threat/abuse model that OpenFab addresses can be presented on request.
Summary
As AI- and agent-generated code enters software supply chains, existing provenance (SLSA build provenance, commit signing) does not capture how an artifact was produced by an AI pipeline: human-vs-AI authorship, the model, the prompt fingerprint, the acceptance contract that was checked, and the human sign-offs.
Some projects are responding by banning AI contributions outright for lack of provenance — e.g. QEMU's contribution policy, and NetBSD treating LLM output as presumed-tainted. A neutral, verifiable attestation format could let projects govern AI contributions instead of banning them.
This issue shares an early approach with the OpenSSF community to gather feedback, spark discussion, and find sensible next steps.
Related work
The
openfab/generationpredicate builds on existing supply-chain provenance: in-toto attestations and DSSE, SLSA build provenance,SPDX/CycloneDX SBOMs, and the TODO Group's Agentic AI working group on AI provenance. The gap it targets is the missing piece — AI-vs-human authorship plus the model/prompt/acceptance context, as a first-class signed predicate.A concrete starting point
OpenFab — Apache-2.0 and vendor-neutral — has defined a draft in-toto predicate,
openfab/generation, as a basis for discussion:Carried in a DSSE-signed in-toto Statement and bound to the artifact's file digests, the predicate records:
forge-agnostic and works offline
It is positioned as a sibling to SLSA provenance, not a part of it.
Question for the TAC
Is there interest in an "AI authorship / AI-BOM" attestation predicate as a community-governed standard? The predicate design and the threat/abuse model that OpenFab addresses can be presented on request.