On this page
AI code provenance is the record of which agent, and often which model and prompt, produced a piece of code, and you can get it three ways. The three are: a trailer such as Co-authored-by in the commit message, a tool like Git AI that records agent sessions as you work, or inference from existing git history. Recorders are the most precise, and only inference covers commits that already exist. In our 28-repo study, agent commits were no more likely to introduce bugs than human commits in the same repo, so the useful question is where agent code sits.
| Method | How it records | Granularity | Covers commits from before you started? | What hides it | Examples (checked 2026-10-06) |
|---|---|---|---|---|---|
| Commit trailers | A line at the end of the commit message, added by the agent or the developer | Commit | Yes, if the trailer was written then | Turning it off, editing it out, a squash message that drops it | Co-authored-by (Claude Code adds it by default), Assisted-by (Linux kernel rule) |
| Session recorders | A hook in the agent records each edit, then attaches it to the commit, often as a git note | Line | No, only after install | Agents without a hook, edits made outside the hook, history-rewriting tools | Git AI (Apache-2.0), agentdiff (Apache-2.0), Agent Blame (Apache-2.0), Semantica (MIT) |
| A shared trace format | A JSON record per change, in a format any tool can write and read | Line or file | No | Tools that do not write it | Agent Trace, an open spec at RFC v0.1.0 |
| Inference from history | Reads bot accounts, service emails, footers, trailers and notes already in git | Commit | Yes | Squashes that strip markers, pasted code with no marker | repowise, research detectors |
Scroll the table sideways to see every column.
What AI code provenance means
git blame tells you who committed a line, but it does not tell you whether that person typed it or an agent did. Now that coding agents write a real share of the code in real repositories, that gap matters for code review, for incident work and for compliance questions such as "which parts of this product did a model write?"
Provenance is the record that closes the gap. At its simplest it is one bit per commit that says agent or human. At its most detailed it is per line, saying that this line came from this agent, running this model, in this session, from this prompt.
It also helps to record how much the agent did. A bot agent working alone (Devin, the Copilot coding agent), a developer steering Claude Code, and a trailer on a mostly human commit behave differently, so a tool that lumps them together hides the signal you want.
Commit trailers: Co-authored-by, Assisted-by, Generated-by
A trailer is a Key: value line at the bottom of a commit message. Git has supported them for years, and GitHub already reads Co-authored-by to show more than one author on a commit.
Agents use them in two ways. Some add them for you: Claude Code's documentation says commits get a git trailer such as Co-Authored-By by default, and its attribution setting can change or hide it. Some projects ask humans to add them: the Linux kernel's guidance for coding assistants asks for an Assisted-by: LLM [TOOL1] [TOOL2] tag, and says AI agents must not add Signed-off-by, because only a human can certify the Developer Certificate of Origin.
Trailers are cheap and they travel with the commit, which is why most write-ups recommend them first. Their weakness is that they are voluntary and they live in a free-text field:
- The developer can turn them off or delete them, and no one will know.
- A squash merge produces a new commit message. If the person merging trims the trailer lines, the marker is gone from the main branch.
- They say an agent was involved, but they do not say which lines it wrote. A commit with a
Co-authored-by: Claudeline might be 5% agent or 100% agent.
Our view is that trailers are worth turning on everywhere, because they cost nothing and they are the only marker that already exists in old history.
Tools that record agent sessions: Git AI, agentdiff and others
The second approach hooks into the agent itself. When the agent edits a file, a hook writes down what it changed, and at commit time the tool folds those records into an attribution log and attaches it to the commit. Because the agent reports its own edits, nothing is guessed.
The descriptions below come from each tool's own docs and repository:
- Git AI is an open source git extension. Agents call
git ai checkpointas they write, and on commit, line-level attribution is stored in git notes underrefs/notes/ai, linking each AI line to its agent, model and session. Its docs say attribution survives rebase, squash, cherry-pick, merge, stash, reset and amend, and listgit mv,filter-branchandfilter-repoas cases it cannot track. It supports a dozen local agents plus background agents such as Devin and Codex Cloud, has about 2,800 GitHub stars, and offers a separate teams version. - agentdiff records which agent wrote which line through per-agent hooks (Claude Code, Cursor, Copilot, Codex, Windsurf, OpenCode, Gemini), signs each record with ed25519, and stores it under its own git refs. Its README is clear that it cannot attribute code written before you run
agentdiff init. - Agent Blame, from Mesa, stores line-level attribution in git notes and shows it next to
git blame, with Chrome and Firefox extensions. It supports Cursor, Claude Code and OpenCode, and states that it prefers missing a case over a false attribution. - Semantica installs git hooks, keeps its lineage data in a local
.semantica/folder, and supports Claude Code, Codex, Cursor, Kiro, Gemini CLI and Copilot.
Several companies are also moving toward a shared format. Agent Trace is an open specification, currently an RFC at version 0.1.0, published by Cursor, with Cognition, Cline, Vercel and others as partners. It defines a JSON trace record that links code ranges to the model and conversation that produced them, and it deliberately leaves storage open: local files, git notes or a database.
Session recorders give the best answer available, with two costs: every developer and agent needs the hook, and none of them can tell you about the code your agents wrote last year.
Inferring provenance from the git history you already have
The third approach reads what agents leave behind anyway. Agent service accounts commit under recognisable identities (copilot-swe-agent[bot], devin-ai-integration[bot]). Some agents write exact footer phrases such as "Generated with Claude Code". Trailers carry service email addresses. Git AI notes and Agent Trace files, where a repo has them, are explicit records a reader can pick up.
repowise takes this approach. Its detector is a set of regular expressions over the commit records it already parses, with no network calls and no model involved. It reads bot accounts and service emails, message footers, Co-authored-by, Assisted-by and Generated-by trailers, refs/notes/ai notes and .agent-trace/traces.jsonl records. Every pattern is tied to a service identity, never a bare name, so a human contributor called Devin is not mistaken for the Devin agent. The detector is built this way because a false "agent wrote this" does more harm than a miss.
Inference works on your whole existing history from the first run, and it needs nothing installed on anyone's laptop, so it also covers contractors and past contributors.
Its main limit is that it can only see agents that left a mark. Code pasted from a chat window and committed under a person's name looks human. Squash merges that drop trailers lose the signal, and the local detector does not call the GitHub API, so pull-request clues like agent branch names are out of scope there. Treat the result as a floor and a way to point review at risky code, not as an audit. The agent provenance feature page shows how it appears next to each file.
To see how precise this approach can get, for the study below we built a detector that read eight signals (the local ones plus merged pull-request evidence) and blind-validated it on 124 commits with six independent reviewers. It reached 96.2% precision, and six of the eight signal types were perfect. The one real failure mode was a human pushing a follow-up commit inside an agent's pull request, which we mark as lower confidence so it can be filtered.
Which approach should you use?
They answer different questions, so most teams will want more than one.
- Turn on trailers now. They are free, they are already in most agent defaults, and they are the only thing your future inference will be able to read. Ask people not to strip them on squash.
- Add a session recorder if you need line-level answers going forward, for audits or for reviewing exactly which lines an agent produced. Pick one that writes git notes or Agent Trace records, so other tools can read the data later.
- Use inference for everything before that, and for repos you cannot instrument. It is the only way to see the agent share of the last year of commits.
Is code written by agents buggier?
People usually want provenance because they assume agent code is riskier. We tested that assumption by blaming every bug fix back to the commit that introduced it, across 28 public repositories and 112,382 commits, comparing agent and human commits in the same repo and controlling for change size.
The full write-up is in Is AI-written code buggier than human code?. In short, the study found no evidence that agent commits introduce more bugs than human commits in the same repo, and the point estimates leaned protective. Human-driven agents came in at an odds ratio of 0.57 (95% CI 0.42 to 0.76), though under a stricter blame method that moved to 0.79 with an interval that just touches 1.0. Agent-written lines also survived longer, by 17.9 percentage points.
The caveats matter. The study only covered reviewed, merged commits. Only detected agent code counts as agent code, so every agent number is a floor, and the agent era was about twelve months deep when we measured.
For provenance, this means the raw share of agent code is a weak signal on its own, and the more useful question is where agent code sits. Agent-written code in a low-health file that one person owns is worth a closer look; agent-written code in a well-tested, shared module mostly is not. That is why repowise shows provenance next to each file's health score and owner, and does not report it as a standalone percentage. repowise's health score (1 to 10) rates how likely a file is to cause bugs and how hard it is to change, using static checks plus git history; the repo score is the average across files, weighted by lines of code.
How we measured
Tool descriptions come from each project's own docs and GitHub repository, read on 2026-10-06; star counts and licences come from the GitHub API that day. We did not install or benchmark the session recorders, so nothing here compares their accuracy. The repowise detector description comes from its open source code (agent_provenance.py in the repowise repo). The precision and bug numbers come from our 28-repo study, collected in June 2026 over roughly the first twelve months of agents merging code. That corpus is not a random sample of all software, and the study only sees agents that left a mark.
FAQ
- What is agent provenance?
- Agent provenance is the record of which AI agent produced a change, and sometimes which model, session and prompt. It can sit at the commit level, as a trailer or a bot author, or at the line level, as a note attached to the commit by a recording tool. The goal is to tell agent-written code from human-written code after the fact.
- Can you detect AI-written code from git history alone?
- History alone gives a partial answer. Bot accounts, service emails, footers such as "Generated with Claude Code" and
Co-authored-bytrailers are all readable from history, and a detector anchored to those identities can be very precise: ours reached 96.2% on 124 blind-reviewed commits. It cannot see code that left no mark, such as a snippet pasted from a chat window and committed by a person. - What is Git AI and how does it work?
- Git AI is an open source git extension under the Apache-2.0 licence. Supported agents report the lines they write through checkpoints, and on commit Git AI saves a line-level authorship log as a git note under
refs/notes/ai, which syncs on push and fetch like any other ref. It only records code written after you install it. - Does a squash merge remove the Co-authored-by trailer?
- It can. A squash merge writes a new commit message, and whether the trailers survive depends on what ends up in that message. If the person merging edits them out, history-based detection loses the marker for that change. Session recorders that rewrite their notes after a squash, as Git AI says it does, avoid this.
- Is tracking AI-written code a form of developer surveillance?
- It does not have to be. Provenance can be read from commits alone, with no keystroke logging, and the useful unit is the file and the agent, so no person needs to be named. Used to rank risky code for review, it is a codebase signal. Used to rank engineers by output, it becomes a productivity ledger, which is a different and worse use of the same data.
