Code Provenance for AI-Generated Commits

A coding agent runs inside a checkout that already has a git configuration. It reads user.name and user.email from that configuration, exactly as any other process would, and stamps them onto every commit it makes. Nothing in git objects to this. The result is a history in which an agent's work is indistinguishable from a person's, signed with a person's name, and attributed to a person by every tool that reads the log.

That is not a cosmetic problem. git blame is how most teams answer "who understands this code" a year later, and the answer is now wrong. Incident review asks who introduced a regression and gets a name that never read the diff. Contribution metrics inflate. Compliance evidence that rests on "every change is attributable to a named individual" is technically satisfied and substantively hollow. And when the volume of generated code grows, the damage compounds silently, because nothing errors - the history simply becomes less true, one commit at a time.

Provenance is the fix, and it is narrower than it sounds. Provenance does not mean proving the code is good. It means being able to answer three questions about any line in the repository: what produced it, who accepted it, and what evidence exists for both. Everything below is in service of those three questions.

Both the MIT license and Apache 2.0 require attribution and preservation of the license text. That is the whole deal: you may do nearly anything with the code provided the notice travels with it. When a model trained on public repositories reproduces a recognizable chunk of an MIT-licensed project into your codebase, what arrives is the expression without the notice. The license has been violated, quietly, by a permissive license - which is the version people assume is safe. Copyleft is the sharper edge of the same mechanism, because there the obligation attached to distribution is considerably heavier than a header comment.

Liability for that sits with the distributor, not the generator. If shipped code reproduces someone else's copyrighted expression, shipping it is the infringing act, and "the model produced it" does not move the exposure elsewhere. Innocence is not a defense to infringement under US law; at most it reduces the award, since 17 U.S.C. Section 504(c)(2) lets a court lower statutory damages where the infringer was not aware and had no reason to believe the act was infringement. Not knowing is worth a discount, not an exit.

One warning about how this risk gets quantified in public. Several widely repeated figures about the share of generated code carrying licensing irregularities trace back to nothing - no study, no dataset, no methodology, just a sentence in a marketing post that everyone subsequently cited. Treat unattributed percentages in this area as unusable. The case for taking licensing seriously rests on the mechanism, which is not in dispute: models are trained on public code, they sometimes reproduce recognizable spans of it, and notices do not survive the trip.

Co-authored-by: is real and is recognized by GitHub, which renders the additional author on the commit. The format is exact - Co-authored-by: name <[email protected]> - and it is documented in GitHub's guide to commits with multiple authors.

Generated-by: is not a standard and should not be presented as one, but it is not invented either. The Apache Software Foundation's generative tooling guidance states that "when providing contributions authored using generative AI tooling, a recommended practice is for contributors to indicate the tooling used to create the contribution", and that this "should be included as a token in the source control commit message, for example including the phrase 'Generated-by: '". That is one foundation-level recommendation with an example format - no specification, no defined value format, no tooling that recognizes it. Note also that the ASF spells it with a lowercase b. Its value is that it is greppable, and that is genuinely worth something; it is not an assurance of anything.

The reason no agreed AI trailer exists is that git itself defines no fixed vocabulary. As git interpret-trailers documents, trailers are free-form key-value lines in the RFC-822 style; Signed-off-by, Acked-by and Reviewed-by are conventions that stuck, not schema. The practical upshot is liberating: a team can adopt an internal trailer today, enforce it in a commit hook, and query it forever, without waiting for anyone to bless it.

feat(billing): add proration for mid-cycle plan changes

Splits the invoice at the change boundary and credits the unused
remainder of the previous plan.

# Recognised by GitHub - credits the agent service account as an author
Co-authored-by: build-agent-07 <[email protected]>

# EMERGING CONVENTION, not a standard - ASF recommended practice only
Generated-by: internal-coding-agent v3.4

# Local conventions - free-form, but greppable and hook-enforceable
Reviewed-by: Reviewer Name <[email protected]>
Signed-off-by: Reviewer Name <[email protected]>

Metadata that is never queried is just noise in the log. The test of whether a trailer convention is worth adopting is whether someone can answer a real question with it months later - which files did agents touch, which generated commits went in without a named reviewer, what changed in this release that no human wrote from scratch.

# Commits on main in the last quarter carrying a generated-by trailer
git log --since="3 months ago" --grep="Generated-by:" \
        --format="%h  %an  %s" main

# Parse the trailer block of one commit into key/value pairs
git show -s --format=%B HEAD | git interpret-trailers --parse

# Which files has the agent service account touched?
git log --author="build-agent-07" --name-only --format="commit %h"

# Generated commits that never picked up a Reviewed-by trailer
git log --grep="Generated-by:" --format="%H" \
  | xargs -I{} sh -c 'git show -s --format=%B {} \
      | grep -q "^Reviewed-by:" || echo "unreviewed: {}"'

The current SLSA Source Track, spec v1.2, has approved status and four levels: L1 Version controlled, L2 History & Provenance, L3 Continuous technical controls, and L4 Two-party review. Under Identity Management its language is that "activities conducted on the SCS SHOULD be attributed to authenticated identities" - a SHOULD, deliberately.

The phrase people quote when they want something firmer, "strongly authenticated actor", does not appear in v1.2. It comes from the retired SLSA v0.1 requirements, under Verified history, where it was required at levels 2 and 3: "Every change in the revision's history has at least one strongly authenticated actor identity (author, uploader, reviewer, etc.) and timestamp." If you cite that wording, cite it as superseded and note that the current Source Track softened it. A page about provenance that misattributes a provenance specification would be arguing against itself.

The direction of travel is unchanged either way. Both versions want changes traceable to identities that mean something, and an agent committing as a borrowed human identity satisfies neither in substance.

A service account per agent creates real account-management work, and it breaks assumptions elsewhere. CODEOWNERS rules, protected-branch policies and review-approval flows are frequently written on the assumption that every actor is a person, and a machine author can either be blocked outright or - worse - can satisfy an approval requirement that was meant to guarantee a second pair of human eyes. Work through those rules before rolling the account out, not after.

Trailers decay. A convention that nobody queries becomes decoration within a quarter, and one that is applied inconsistently is worse than none, because it implies an absence means something. If you adopt a trailer, enforce it in a hook and build the query someone will actually run. Keyless signing adds a dependency on external availability. And every one of these controls adds a step to a workflow whose whole appeal was speed.

The honest limit is worth stating last. None of this tells you whether the code is correct, safe, or good. Provenance answers where code came from and who stands behind it - nothing more. A perfectly attributed, cryptographically signed commit can still be wrong. What provenance buys is the ability to find out fast, and to answer questions later that are otherwise unanswerable at any price. That is a narrow benefit, and it is a real one.