Who Actually Wrote the Code Your Agent Just Merged?

The commit says a human wrote it. The human didn't.

Run git blame on anything your team shipped this quarter and the output will lie to you with a straight face. Line 47, authored by a senior engineer, committed Tuesday at 2:14 PM. Except that engineer was in a planning meeting, and the code was written, staged, and pushed by a Cursor background agent operating under their credentials. The git log is clean. The signature checks out. The attribution is fiction.

This is not a hypothetical. Somewhere in mid-2026, autonomous coding agents crossed from demo toy to default workflow. GitHub's agents, Cursor's background runners, and Anthropic-style agents are now opening branches, resolving review comments, and merging pull requests without a human touching a keystroke. And the entire industry is busy arguing about whether the code they produce is good while almost nobody is asking the more dangerous question: can we still prove who wrote it?

git authorship was never evidence

Here is the uncomfortable part, and it has nothing to do with AI. The author field in a git commit is a string. You set it yourself. git commit --author="Linus Torvalds <torvalds@linux-foundation.org>" will happily attribute your code to Linus, and git will not blink. Commit signing with GPG or Sigstore raises the bar slightly: it proves a key touched the commit. It does not prove a human wrote the lines, or that the person who holds the key typed a single character of the diff.

We treated git authorship, PR reviewer approval, and IDE telemetry as a record of who did the work. It was always a soft social convention held together by the assumption that the person with commit access was the person doing the typing. That assumption was load-bearing for a decade and nobody stress-tested it, because until now the counterfactual (someone else silently authoring under your name) required deliberate fraud.

Agents didn't create the gap. They industrialized the thing that was always possible and made it the normal path. When a bot commits on your behalf a hundred times a day, the convention isn't bent, it's meaningless.

Why this bites, and where

For a weekend side project, nobody cares. The problem is everything with legal, security, or IP weight, which is precisely where attribution suddenly has to hold up under adversarial scrutiny.

• SBOM and attestation mandates. The executive-order-driven attestation requirements landing this year assume you can trace a component to its origin. SLSA provenance attests to the build pipeline; it says nothing about authorship of the source that entered it. An SBOM that lists a first-party module authored by "your team" when 90% of it came from an agent is technically a false attestation, and you signed it.
• Copyright claims. The US Copyright Office has been explicit: registrable authorship requires demonstrable human authorship. If you cannot show which lines a person actually wrote, you cannot cleanly claim protection on them. "git says Jane wrote it" is not a chain of evidence a court will respect once the other side subpoenas Jane's calendar.
• Incident forensics. A supply-chain compromise lands and you need to reconstruct who introduced the vulnerable path and when. If half your history is agent commits wearing human names, your forensic timeline is built on sand. You cannot answer "was this a mistake or a malicious insertion" when the actor field is unreliable by design.

This is the same trust erosion we flagged in a different layer when we wrote Exploring the Trust Factor: What Vercel's Valuation Means: we keep pouring confidence into tools without asking what the tools can actually prove. The valuations went up. The evidentiary floor stayed exactly where it was.

Declarative attribution vs. evidentiary provenance

Here is the distinction the whole field is going to have to learn, and fast.

Declarative attribution is a claim. The commit declares an author. The PR declares a reviewer. The changelog declares a contributor. Every one of these is a statement someone (or something) asserts, with no independent record backing it. It is the software equivalent of a witness saying "trust me."

Evidentiary provenance is a record generated by the act itself, tamper-evident, and independent of the actor's own claim. Chain of custody at a crime scene is the model: it is not "the detective says this is the murder weapon," it is a timestamped, sealed, unbroken record of the object from the scene to the courtroom. Break the chain and the evidence is inadmissible. The strength is in the record, not the assertion.

Software authorship needs to move from the first category to the second. And notice this is orthogonal to the "is it AI or human" detector arms race. Detectors are probabilistic guesses about a finished artifact. Provenance is a deterministic record of how the artifact came to exist. One is a coin flip with good marketing; the other is admissible.

What a real proof-of-authorship layer looks like

If you are writing your org's policy for agents in the SDLC right now (and if you are an eng leader, you should be), stop trying to patch the author field and start thinking in terms of an evidence layer that sits underneath it.

1. Capture the act, not the artifact. The only unforgeable signal of human authorship is the process of composition: keystroke-level timing, edit sequences, the pauses and revisions that a human produces and a paste-from-agent does not. A finished diff can be faked. The temporal signature of a human writing it is far harder to synthesize convincingly.
2. Separate agent commits from human commits explicitly. Give agents their own identities and their own keys. Never let a bot commit under a human's name for the convenience of a clean git blame. Co-authored-by trailers are a start; a distinct, non-repudiable agent identity is the real fix.
3. Bind provenance to a hash, not a promise. Whatever record you generate, anchor it to a cryptographic hash of the exact bytes it describes, so the claim and the code cannot drift apart. This is the same primitive that makes SBOM attestations meaningful, applied one layer earlier, at authorship.
4. Make the record externally verifiable. Provenance that only your CI can read is a convention again. It needs to be checkable by an auditor, a court, or a downstream consumer who does not trust you.

None of this requires you to slow down or ban agents. It requires you to stop conflating "a commit exists" with "a person is accountable for it." Those were always two different facts. We just got away with pretending they were one.

The takeaway

Audit your history now, before an auditor, a plaintiff, or an incident responder does it for you. Figure out which commits attributed to humans were actually written by agents. If the answer is "we can't tell," that is your finding, and it is a serious one. As we argued in Are Your AI Tools Legally Compliant? The Case for Verification, the moment attribution carries legal weight, "trust me" stops being an acceptable answer.

Proving human authorship keystroke by keystroke, anchored to a verification hash, is exactly the evidentiary layer we built ByMyOwnHand to produce; it is chain of custody for the words and the code a person actually writes. Start by writing something that matters where the proof travels with it. Your git blame won't cover you much longer.