Code Provenance and Signing for AI-Generated Apps

Code provenance signing is the practice of attaching a verifiable, cryptographically signed record to a piece of software that answers two questions: where did this artifact come from, and has anything changed it since. Provenance is the record, and the signature is what makes it trustworthy. For AI-generated apps, written and rewritten by models rather than reviewed by hand, that pairing stops being a build-time nicety and becomes the only way to know what is actually running.

What provenance and signing mean today#

The software supply-chain community has spent years standardizing this. SLSA (Supply-chain Levels for Software Artifacts) defines provenance as verifiable information describing where, when, and how an artifact was produced. It is an attestation that a specific build platform generated a specific output from specific inputs, so a consumer can verify the artifact was built as expected rather than swapped or tampered with in transit.

Underneath that, in-toto provides the attestation format: a signed statement making transparent what steps were performed, by whom, and in what order. Signing itself has gotten dramatically easier. Sigstore issues short-lived certificates tied to an identity, records every signing event in a public transparency log, and lets teams sign artifacts without holding long-lived private keys. Alongside these, a Software Bill of Materials inventories the components inside an artifact, and NIST's Secure Software Development Framework (SP 800-218) folds provenance and integrity verification into a baseline every producer is now expected to meet.

The shared assumption across all of them is a clean, discrete moment: a build happens, an artifact is produced, it gets signed, and then it ships and runs more or less unchanged. Verification is a checkpoint you pass through on the way to release.

Where AI-generated code breaks the model#

Agent-generated software does not sit still. An app is generated, an agent patches it, a model regenerates a route, a dependency gets swapped, config is rewritten, often many times a day and sometimes with no human in the loop for any single change. The comfortable question "was this artifact signed at build time?" gets replaced by a harder one: what is actually running right now, and is it exactly what was approved?

That gap is where drift lives, and drift is silent. A signature on last week's build tells you nothing about the version an agent redeployed an hour ago. Provenance that stops at the CI pipeline can't watch a running app quietly diverge from the artifact someone reviewed and signed off on. Nothing throws an error. The app keeps serving traffic and touching real data, and it has stopped matching the thing you approved.

Provenance has to reach the runtime#

The fix keeps SLSA, in-toto, and Sigstore and extends what they do past the build and into execution. Concretely, that means three things. Sign the approved app, producing a signed provenance record for the exact version a human or policy blessed. Bind that signature to what runs, so the runtime knows the signed identity of the workload it is executing and never has to assume the right thing was deployed. And verify continuously, checking the running app against its signature on an ongoing basis, so the moment what is executing drifts from what was signed, it gets caught.

That turns provenance from a document you file into a control you enforce. A signed SBOM and a build attestation are necessary, and on their own they describe a past event. Extending signing to the runtime makes the signature a live invariant. If the code no longer matches the attestation, that becomes a condition to block on immediately, before the drifted app does anything with your data, and it never waits for the next audit.

For AI-generated software, that continuous check is the whole point. You cannot review every version a fleet of agents produces. You can insist that only a signed, approved version is allowed to run, and that any deviation stops on contact. Provenance moves from trusting the code to trusting the boundary that verifies it.