Quick path
In this article
Quick read: what changed, why it matters, and what to do next.
You run git log on a clean morning and the last line of the newest commit reads:
Co-authored-by: Claude <noreply@anthropic.com>
Then you open the PR on GitHub and there it is in the contributors strip, a little avatar sitting next to yours, as if a teammate named Claude joined the project overnight and shipped some code with you.
It didn't. Nobody hired it, nobody can put it on a reviewer rotation, and nobody can ask it to certify that it had the right to submit the change. The line looks like a name tag. It's doing the job of a provenance record. Closing that gap is the entire job here.
The question the footer is actually trying to answer isn't "who else is on the team." It's narrower and more useful: did AI materially help write this change, and where is that written down so the next person doesn't have to guess?
A tiny line, debated in public
Artsy, the art-market company, ran exactly this argument in the open. On May 27, 2026, they opened an RFC titled "disclose LLM usage in commits or PRs", and merged it on June 8. The proposal is deliberately small: adopt a lightweight convention for marking commits, or PRs, that were produced with significant LLM assistance, recording the provider and optionally the model.
The first draft reached for Co-authored-by, because that's the trailer everyone already knows. The discussion talked them out of it. By the time it merged, the example in the PR body had become:
Assisted-by: Claude:Opus-4.5
Joey Aghion made the case for the switch plainly in the thread: Assisted-by was compelling because it keeps responsibility visibly and exclusively with the human contributor, even though GitHub's UI doesn't count it as a contributor. That last clause is the feature, not the bug. The whole point is that the tool does not get an avatar. He also argued for merging it so the team could start to see how much trouble, or value, it actually provides, which is a refreshingly honest way to adopt a convention.
What I like about the thread is that nobody pretended it was clean. The team poked at the real edges:
- Commit or PR? A trailer per commit is precise but noisy. A note on the PR is easier but blurs which change the AI touched.
- What about Cursor's auto mode, where the tool picks a model and never tells you which one? You can't record a model string you were never given.
- Won't people just automate it with a Claude hook or a shell alias, so the trailer appears whether or not the help was significant?
- Aren't nearly all our commits AI-assisted now anyway? If the label is always on, does it still mean anything?
Those aren't reasons to skip it. They're the actual design problem, and they're the same four questions every team will hit the week they try this.
Why a trailer, and why this one
A git trailer isn't a vibe. Git supports structured key: value lines at the foot of a commit message on purpose, and documents how to parse them. That's the difference between disclosure you can grep and disclosure that lives in a sentence somewhere in a PR description nobody reads twice. A trailer is queryable. Six months from now you can actually answer "which commits in this release had AI help" without spelunking through review threads.
The reason Co-authored-by is tempting is that GitHub already documents it for commits with multiple authors. It's right there, it works, it renders nicely. But it was built for people, and it makes a person-shaped claim. Bence Ferdinandy put the objection bluntly back in December: "Don't abuse Co-authored-by for marking AI assistance." Co-authorship says this entity shares authorship and accountability. A model can't hold accountability, so the claim is false the moment you write it.
And this is not the signature conversation. GitHub will mark a commit verified when a cryptographic signature checks out. That tells you a key vouched for the commit. It tells you nothing about whether a model helped write it. Signature is "who stands behind this." Provenance is "what went into this." Keep them in separate drawers.
Artsy isn't alone
This isn't one company's house style. Open source has been sorting the same line out loud for months. James Fredley's All Things Open piece, "Assisted-by: How open source projects are drawing the line on AI contributions" from May 11, 2026, walks through a range of responses, from outright bans to enforced disclosure, and notes that the projects choosing to allow AI help with rules keep landing on the same trailer: Assisted-by:. The list of projects that have published guidance is not fringe. It includes the Linux Kernel, Fedora, Rocky Linux, OpenTelemetry, the Apache Software Foundation, LLVM, QEMU, and others.
The Linux Kernel version is the most spelled-out: Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]. It's also explicit about a hard line: an AI agent must never add a Signed-off-by tag, because that tag certifies the Developer Certificate of Origin, and only a human can certify they had the right to submit the contribution. OpenTelemetry's examples look like Assisted-by: Claude Opus 4.5. Fedora and Rocky both recommend the trailer when assistance was significant.
Read across all of them and the consensus is quietly consistent: write down that AI helped, name the tool, optionally name the model, and keep every signature, certification, and ounce of accountability firmly on the human.
A nutrition label, not a name tag
Here's the mental model worth keeping, because it tells you what to put on the label and, more importantly, what to leave off.
A name tag says I am a member of this team. That's what Co-authored-by: Claude accidentally claims, avatar and all.
A signature says I, a human with a key, vouch for this. That's the verified badge, and it stays human.
A nutrition label just lists what went into the thing. It doesn't vote, doesn't sign, doesn't join the team, and doesn't pretend the ingredients had opinions. It's information for whoever picks the change up next.
Assisted-by is the nutrition label. So the label should carry: that AI assistance was material to this change, which tool provided it, and, when the tool tells you, which model. It should not: turn the tool into a contributor, stand in for your sign-off, masquerade as a signature, or demand a model string the tool refuses to expose. If Cursor's auto mode won't say which model it picked, the honest label is the tool name and "auto," not a guess. A nutrition label that lists ingredients the cook never saw is worse than one that admits "proprietary blend."

The AI assistance trailer policy
You don't need a governance program to get the benefit. You need a half-page in the repo that says when the label goes on and what it says, so it's a habit instead of a debate per commit. Here's the shape. Fill in the right column for one repo and you're done.
Scroll sideways to see all 3 columns.
| Field | What it answers | A starting answer |
|---|---|---|
| Trigger | When does the label go on | When AI materially shaped the change: it wrote or rewrote real logic, not when it autocompleted a variable name |
| Placement | Commit or PR | Per commit when one commit is clearly AI-shaped; PR-level note when help was spread across the branch |
| Format | What the line looks like | Assisted-by: TOOL:MODEL (e.g. Assisted-by: Claude:Opus-4.5); tool-only when the model is hidden |
| Fields | What you record | Tool always, model when the tool reveals it, nothing that pretends to be a person |
| Stays human | What the AI never touches | Signed-off-by, the DCO certification, the verified signature, the reviewer's name |
| Honesty rule | What to do under auto mode | Record the tool and auto; never invent a model string you weren't given |
| Don't | The line you won't cross | No Co-authored-by for tools, no auto-stamping every commit so the label stops meaning anything |
Two rows do most of the work, and they're the two people skip. Trigger is where you decide what "material" means before you're arguing about it on a Tuesday, so the label means something instead of riding on literally everything. And Stays human is the row that keeps this honest: the trailer adds context, it never moves accountability off a person. Everything else is formatting.
One nice side effect: once the trailer is consistent, git log --grep='Assisted-by' becomes a real answer to a real question, and your reviewers get a signal they can actually filter on.
Where the label sits
If you've read us before, this is downstream of the work, not another gate in front of it.
The AGENTOWNERS contribution policy is the door: it decides whether an AI-authored change gets into the repo at all, before anyone reads the diff. Review lanes decide who looks at the change once it's inside. Work receipts are the evidence trail for what an agent actually did on a job.
The Assisted-by trailer is a different beast. It's not a gate and it's not a receipt you file somewhere else. It's the label that travels with the change, baked into history, so it's still there long after the PR thread is archived and everyone who remembers the context has moved on. The door decides if the change gets in. The lanes decide who reads it. The trailer is what the change says about itself, forever.
Bring one repo
Don't write an AI disclosure framework. Add one trailer convention to one repo, the one where, a year from now, you'd actually want to know which changes had AI help.
Decide what counts as material. Pick commit-level or PR-level and commit to it. Drop a commit template in the repo so the line is one keystroke, not a thing to remember. Write the auto-mode rule down so nobody fakes a model string. Then leave the certifying, signing, and owning exactly where it already lives: with the person who hit merge.
The next time you run git log and see a line at the foot of a commit, you want it reading like an ingredient list, not introducing a teammate who was never there.
If you want a hand turning that into something your team will actually keep, we'll help you write the convention for one repo, with the practical controls in AI workflow controls and the wiring in process automation.
AI provenance help
Write your Assisted-by convention
BaristaLabs helps teams add a lightweight AI-assistance trailer to one repo, so a reviewer can tell what went into a change without a person having to remember.
Best fit when your team is starting to accept AI-assisted commits, bot-written PRs, or agent-produced changes in repos that matter.
Practical AI Workflow Notes
Want more practical AI operations ideas?
Get short notes on applying AI inside real small-business workflows — from document handling and customer follow-up to internal reporting, compliance, and automation guardrails.
Turn this idea into a pilot
Which workflow should go first?
Use the readiness check to compare impact, effort, risk, owner, and next step before booking a call.
- 3-5 minutes
- Deterministic score
- No sensitive data
Share this post
