The Provenance Gap in Agent-Written Code

Attestations of agent-written code capture only the terminal verification run — the controls that ran, their results, the governing configuration, and the final commit — while discarding the failed attempts, intermediate code states, and diagnostic path that preceded a green result, according to a Swamp analysis of the provenance gap in agent-owned verification-and-repair loops. Swamp's own attestations record every control with its result and duration, the commit hash, and sha256 checksums of the governing configuration, but still omit which failures the agent hit, how it interpreted them, and what intermediate changes it made and discarded. The piece cites a February Stanford Law CodeX publication framing agent-produced software as a liability void at the vendor-to-customer boundary, while arguing that at the practitioner level the person who instructed the agent, defined the verification criteria, and chose to ship remains accountable.

The Provenance Gap in Agent-Written Code When an agent owns the verification-and-repair loop, what record of that process survives? The attestation captures the terminal state. The iterations that preceded it — the failures, the fixes, the diagnostic path — vanish the moment verification succeeds. Part three of a series on agents and CI, following AI Broke the Assumptions Behind CI and The Feedback Loop Is Moving Out of CI . Earlier in this series, I argued that agents can own the verification-and-repair loop before a change reaches the merge boundary. That creates a new question: once an agent has tried, failed, repaired, and eventually produced a green result, what record of that process survives? Most attestations record the terminal verification run: the controls that ran, their results, the governing configuration, and the final commit. They do not preserve the failed attempts, intermediate code states, or diagnostic path that preceded it. When something goes wrong with agent-produced code, does the person responsible have enough evidence to understand what happened? What vanishes When an agent owns the verification-and-repair loop, the iteration history disappears. The agent produces an initial implementation. Tests fail. It interprets the failures, modifies the implementation, reruns. More failures. More fixes. Eventually everything passes. The attestation records the terminal state: all checks green at this commit. At Swamp, our attestations capture every control that ran with its result and duration, the commit hash, and sha256 checksums of the configuration that governed the run. That records more than most agent setups produce, and it covers configuration integrity and the terminal verification result. What it does not capture is the path the agent took to arrive there — which failures it encountered, how it interpreted them, what intermediate changes it made and discarded. For shipping purposes, the terminal result is what matters. Tests pass, linter is clean, review found nothing. Ship it. For governance purposes, the terminal result answers a narrow question. When a production incident traces back to an agent-produced change, the questions are about the path. Did the agent encounter a related failure during verification and work around it rather than fixing the root cause? Did the review flag the problematic pattern but the agent addressed it incorrectly? Did the verification configuration miss the relevant test category entirely? Every incident review asks these questions about human-produced code too. The difference is that human developers leave traces: commit history, PR conversations, Slack threads, the reviewer's memory of what they were worried about. Agent verification loops leave a final commit and an attestation of the terminal run. Accountability is not the hard part The constant friction I see: "If Claude writes the code, who is accountable for it?" The person who instructed the agent is accountable for what it produces, the same way you are accountable for what you ship regardless of what tools produced it. Stanford Law's CodeX centre published a piece https://law.stanford.edu/2026/02/08/built-by-agents-tested-by-agents-trusted-by-whom/?ref=stack72.dev in February framing this as a liability void, with responsibility diffusing across engineers, model providers, and vendors. At the vendor-to-customer boundary, they have a point — the legal frameworks for warranting agent-produced software are genuinely underdeveloped. But at the practitioner level, accountability is not ambiguous. The person who gave the instruction, defined the verification criteria, and chose to ship the result owns the outcome. The harder problem is whether that person can actually do their job. If you are responsible for agent-produced code and something goes wrong in production, you need to be able to answer specific questions about what the agent did, what it tried, what failed, and why it concluded the change was safe. For teams using coding agents today, that evidence largely does not exist. At Swamp, we run a software factory too. Agents implement, verify, and review changes; humans intervene when the loop needs input and govern the policies that direct it. That makes the missing record more important, not less. When something goes wrong, the person accountable for a change needs to be able to see what the agent tried, what failed, and how it reached a green result. StrongDM's " Software Factory https://www.strongdm.com/blog/the-strongdm-software-factory-building-software-with-ai?ref=stack72.dev " illustrates the trajectory. Agents write the code. Agents test it against a digital twin environment. No human reviews the code. The published description does not discuss audit trails for agent decisions, rollback procedures, or how specification errors propagate — which does not mean those capabilities are absent, but it leaves unclear how the iteration process would be audited when something goes wrong. That is the gap. Every team using coding agents is somewhere on this spectrum, and the economics push toward less human involvement, not more. What iteration provenance is and is not It is worth being precise about what iteration provenance adds to the two properties the previous posts established. Configuration integrity answers: did the expected rules and prompts govern the run? The attestation carries checksums of review prompts, workflow definitions, and configuration files. CI can hash the files at the verified commit and confirm they match. Result integrity answers: did the controls actually execute and produce the claimed outcome? This is not fully provable from the attestation alone — the previous posts were explicit about that limitation, and for controls where result integrity requires a higher level of assurance, running them on independent infrastructure is the right call. Iteration provenance answers a different question: what happened along the way? Which failures did the agent encounter, what code changes did it make in response, and how did the sequence of attempts lead to the final state? Iteration provenance does not prove that a run was honest or that the agent's interpretation of a failure was correct. It makes the process auditable after the fact. When an incident review needs to understand whether the agent encountered and mishandled a relevant failure, a structured iteration record is the difference between being able to investigate and having nothing to work with. What the accountable person needs If you are the person responsible for agent-produced code, what does a useful iteration record contain? Identity and configuration content: which agent system, which model version, which instruction set governed the run. A review prompt is executable policy — changing it changes what the reviewer checks for. At Swamp, review prompts and workflow definitions are versioned files in the repo. Checksums in the attestation confirm the configuration matches what is checked in, but when an agent’s output is in question, the governing prompts and rules need to remain durably recoverable. Checksums in the attestation confirm the configuration matches what is checked in, but when an agent's output is in question, you need the actual content of the prompts and rules that governed it to remain durably recoverable, not just confirmation that they matched. Iteration history: the sequence of verification failures and corresponding code changes, captured as structured data. Not full conversation transcripts. The structured record should link observed failures to the code changes and retries that followed — without treating the agent's own explanation as proof of root cause. An agent's diagnostic reasoning is a useful input to an investigation, not a reliable conclusion. A recent survey on execution provenance in LLM agents https://arxiv.org/abs/2606.04990?ref=stack72.dev draws a useful distinction between execution provenance the complete record of an agent run and evidence tracing the projection onto what evidence supported what decisions . The governance layer needs the evidence-tracing view, not the complete execution trace. Verification coverage metadata: which checks ran, what categories of failure they could have caught, and what they could not. A green test suite does not tell you whether the tests covered the changed code paths, or whether the change introduced behaviour that no existing test exercises. Without that metadata, you cannot distinguish "verified and safe" from "verified against an incomplete set of checks." Review provenance: which review prompt governed the review, what the reviewer examined, what it flagged, how flagged items were resolved. Human code review has always been an unstructured conversation. Agent review, governed by versioned prompts, can produce structured evidence of what the review actually checked — but only if you capture it. The toolbox points the wrong way The supply chain security community has spent over a decade building provenance infrastructure. in-toto https://in-toto.io/?ref=stack72.dev defines software supply chains as steps performed by authorised functionaries, with cryptographic linking from step to step. SLSA https://slsa.dev/spec/v1.0/levels?ref=stack72.dev defines progressive levels of build provenance, from L1 provenance exists, even unsigned through L3 hardened build environment with tamper controls . Google's Binary Authorization for Borg https://cloud.google.com/docs/security/binary-authorization-for-borg?ref=stack72.dev enforces provenance policy at the deployment boundary. Sigstore https://www.sigstore.dev/?ref=stack72.dev removed the key management barrier that kept most open-source projects from signing anything. This infrastructure is mature and solves real problems. It also shares an assumption: code is written by humans, built by machines, and the interesting provenance questions concern the build and deployment chain. The authoring step is either outside scope or handled by a single assertion: a human submitted this through code review. When the authoring step has internal structure worth recording, the provenance chain needs to extend backward. The architectural concepts already exist: expected policy versus actual evidence, authorised actors, cryptographic step-linking, progressive assurance levels. Applying them to the agent verification loop is an extension, not an invention. The smallest useful record Start by making a completed agent run reconstructable after the fact. For each attempt, retain the input and output commit or diff, the checks that ran and the failures they returned, the model and configuration that governed the run, and a link to the attempt that followed. Tie the sequence to the final attestation. This does not require recording a full conversation transcript. It requires enough structured evidence that, when a final change needs explaining, someone can follow the path from the first implementation through each failed attempt to the green result. Signing that record makes later tampering detectable. Running controls in a hardened environment gives stronger assurance that the record reflects what actually happened. Both matter, but neither helps much if the iteration history was discarded in the first place. The chain extends backward The evidence consumed at the merge boundary needs to cover more than the terminal verification result. It needs to retain enough of the path to that result that a responsible person can investigate a change when it matters. A final attestation can establish that the required controls passed for a particular commit. It cannot show whether the agent encountered a relevant failure earlier, what change it made in response, or whether that response addressed the underlying problem. Those are the questions an incident review will need to answer. Agent-owned verification changes the authoring process. The record of that process needs to become a first-class artifact of a software change: retained alongside the code, the tests, and the final attestation. If an agent is allowed to repair its own work until it reaches a green result, the history of those repairs cannot disappear when the checks pass.