Should every agent-generated change carry provenance?

I think every code change produced with an AI agent should carry a compact, machine-readable provenance record: model and version, agent/session ID, tools invoked, dependency lookups, files inspected, test and lint results, timestamp, and a hash of the final diff.

That could make review and debugging materially better—especially when a regression appears weeks later—but only if it stays an index into useful evidence. A giant transcript of every search, retry, prompt, and file read will become repository noise. Retaining prompts and context also creates privacy and data-locality problems, including accidental exposure of secrets or business information.

So I’m unsure whether this would improve safety or just create reassuring metadata that nobody checks. Would you require provenance records for production codebases? What minimum fields would you actually keep?

The diff hash and exact test results are the useful core. I’d also want the tool-call sequence summarized, not dumped. If the record cannot answer “what did the agent use to make this change?” in a few seconds, it belongs in cold storage, not the pull request.

I’d separate usefulness from assurance. A record can improve debugging and establish what was attempted; it does not establish that the code is safe or that the record is authentic. For the latter, the capture path needs trust and tamper resistance, not just JSON committed beside the code.

For a one-line typo fix, mandatory ceremony would be absurd. For production changes, I’d accept a small trailer containing model/version, session ID, files touched, dependency versions, and checks run. Link to the verbose log only when someone needs it.

The privacy issue is bigger than it first appears. “Files inspected” can reveal architecture, customer names, or secrets in filenames, while prompts and context may contain even more. I’d retain a redacted summary locally and make detailed logs opt-in with a short retention period.

Teams adopt what sits in the existing workflow. If provenance is automatically attached to the change and searchable during review, some value is plausible. If it creates another dashboard, I’d bet on compliance theater. The friction budget is very small.

This sounds like build logs wearing a fashionable hat. Keep the fields that help reproduce or explain a change; discard the diary. Nobody needs an archaeological record of an agent thinking out loud.

I’d require it for regulated or high-impact production repositories, but not necessarily every internal script. The policy should specify retention, access, and redaction as carefully as the fields. Otherwise auditability quietly becomes a new data-leak surface.

The strongest case is incident response: knowing which model, inputs, tools, and checks were involved can narrow the investigation. But making the record mandatory may also make developers avoid agents for small safe changes. Risk-tiered requirements seem more credible than universal ones.