Provenance & Attribution

A production incident starts the way most of them do: a null check that should have been there wasn’t, and a customer hit the gap at 2 a.m. The on-call engineer runs `git blame`, finds the offending line attributed to a teammate’s commit from six weeks earlier, and pings them half expecting a five-minute answer. The teammate stares at the diff for a while and says, honestly, that they don’t remember writing it — because they didn’t, not in the sense the question assumes. They opened an AI coding session, described the retry logic they wanted, accepted the diff, and pushed it under their own name, the way the tooling expected them to. Git recorded exactly what it was built to record: an account, a timestamp, a message. It recorded none of what the engineer actually needed to know.

That gap used to be rare enough to shrug off. It isn’t anymore. A codebase now routinely has lines a human wrote unassisted, lines an AI agent wrote and a human merged untouched, and lines an AI drafted that a human then materially edited — three different provenance states doing three different jobs in the same file, none of them visible from the commit history alone. The question “who wrote this” has quietly become a question with three possible answers and no field in git built to record which one applies.

What git blame doesn’t know

Git’s authorship model was built for a world where the account on a commit did the reasoning behind it. `git blame` answers “whose commit touched this line last,” which stands in for “who is responsible for it” only as long as those two things stay the same. The closest thing git has to a structured answer for shared authorship is the `Co-authored-by` trailer — a line in the commit message, recognized by GitHub well before agentic coding existed, that credits a second contributor without changing who technically made the commit. It works, and it is real: GitHub surfaces co-authored commits in contributor graphs and profile activity, provided the trailer uses an email tied to the co-author’s account. It is also entirely opt-in. Nothing forces an agent, or the person driving it, to add the trailer, and most AI-generated diffs today ship without one — which is why this Library’s own commit practice adds it by convention rather than by tooling, a discipline problem dressed up as a solved one.

Vendors have started building around the gap rather than waiting for git to close it. GitHub’s own coding agent automates branch creation, commit messages, and pushes for the pull requests it opens, and the product’s own documentation frames this as a transparency feature, with every step happening in a commit and viewable in logs. That is a real improvement over an untracked diff pasted into an editor — but it is also a closed, single-vendor answer. A team running Claude Code, Cursor, and a GitHub-native agent side by side gets three different bespoke logs in three different formats, none of which talk to each other, and a squash-merge can still collapse an entire session’s step-by-step record into one anonymous commit.

The first serious attempt at an open, cross-vendor answer arrived in January 2026, when Cursor published Agent Trace as a public RFC — a vendor-neutral schema for recording, per file and per line range, whether a given span of code came from a human, an AI agent, a mix of both, or an unknown source, tied to the tool and conversation that produced it. The specification is early — version 0.1.0, still accepting suggestions — but the roster of organizations shaping it, including Anthropic, Cloudflare, Cognition, and Vercel, signals that the industry has stopped treating this as a hypothetical problem. The RFC states its own motivation plainly: as agents write more of the code, understanding what came from AI versus humans stops being a curiosity and starts being infrastructure.

Three postmortems, one line of code

Provenance metadata matters beyond satisfying curiosity about a byline, and it matters most in exactly the moment a team is least equipped to reconstruct it: incident review. A bug that shipped is one of at least three different failures wearing the same commit hash. It might be ordinary human error — someone, AI-assisted or not, missed something a careful review would have caught. It might be a systematic model failure mode — the same agent, given similar instructions, reliably drops the same category of edge case, and this incident is not the first time, just the first time anyone noticed the pattern. Or it might be a prompt or context failure — the agent behaved reasonably given what it was told and shown, and the actual defect sits in the specification or the harness that fed it incomplete information. All three produce an identical-looking diff. None of them get an identical-looking fix.

Without a record of which agent, model, and session produced the line — and what it was asked to do — a postmortem can only describe the symptom: commit abc123 introduced the regression. That description supports exactly one remedy, the generic one: add a review step, ask people to be more careful next time. It cannot support the remedy that actually matches a model failure mode, which is a change upstream — to the system prompt, the harness’s guardrails, or the tools the agent is given — applied once, instead of a review comment repeated indefinitely against every future instance of the same mistake. A team that cannot tell these three failures apart will keep treating a harness problem as a training problem, and keep being surprised when the same bug returns wearing a different commit hash.

As agents write more code, it’s important to understand what came from AI versus humans.

Agent Trace RFC, on why the specification exists

Provenance, not just authorship

None of this needs a new name. Agent-authored change tracking and audit trail are already the right words for it, and provenance — a record of where something came from and what happened to it since — is a term this problem borrows directly from archives and, more recently, from the standards built for AI-generated media. The Coalition for Content Provenance and Authenticity already ships a mature version of this idea for images, audio, and video: a signed manifest recording who created a piece of content, what tool made it, and every meaningful edit since, with a member ecosystem the coalition put at more than six thousand organizations and affiliates as of early 2026. Code has no equivalent yet with anything close to that adoption — C2PA’s own documentation scopes itself to media assets, not software — which reads less like a gap in the standard than a gap in how seriously the software industry has taken a problem the media industry was forced to solve first.

One piece of this record already has a name elsewhere in this Library: Decision Memory, the practice of persisting an agent’s choices as queryable records of what was decided, why, and what it superseded. Decision Memory and provenance answer adjacent but different questions. Decision Memory explains why a choice was made. Provenance explains who — or what — made it, using which model, in which session, under whose review. A postmortem with both can reconstruct the actual chain: the goal a session was given, the decision it made in service of that goal, and the identity of the process that made it. A postmortem with neither has a commit hash and a guess.

The provenance stack

Building this deliberately means treating provenance as a stack of layers, each answering a narrower question than the one above it, and each backed by a real mechanism rather than a policy nobody enforces.

The layers compose rather than compete, and most teams today have reliably instrumented exactly one of them — the commit layer, because version control forces it whether anyone plans for it or not. The operation layer is the newest entrant with real institutional backing: OpenTelemetry’s GenAI semantic conventions define standard fields for exactly this, `gen_ai.agent.id` and `gen_ai.conversation.id` to identify which agent and which session, `gen_ai.tool.name` for what it called — though the working group itself still marks these attributes at “development” stability, which is a polite way of saying: real, useful, and not yet something to build a compliance program on without a fallback.

What a session record already knows

None of this requires believing a given AI agent is more or less trustworthy than a given engineer. It requires deciding, in advance of the incident that will otherwise force the question, that a line of code’s origin is data worth keeping rather than folklore to be reconstructed under pressure by whoever happens to still remember the session.

What to build, if you’re building this

1. Capture session, model, and tool identity automatically, at the point the change is made — not through commit-message discipline, which decays under deadline pressure exactly when it matters most.
2. Store the diff with the record, not a paraphrase of it. A postmortem needs to see what changed, not read someone’s summary of what changed.
3. Treat `Co-authored-by` as the floor, not the ceiling. It is real, it is already supported everywhere, and it is not sufficient on its own to answer which model, which session, or which prompt.
4. Separate “AI-authored, unreviewed” from “AI-authored, then human-reviewed” as distinct states. Review status is itself provenance, and collapsing the two erases the difference between a diff nobody looked at and one somebody vouched for.
5. Watch for the pattern, not just the incident. One postmortem naming a model failure mode is a data point. Three postmortems naming the same failure mode, across different sessions, is a harness bug wearing a disguise.