AI contribution policy for engineering teams: who signs for code provenance
An AI contribution policy is the document that says who takes responsibility for code a model produced, how that origin is declared in a pull request, and what a reviewer may close without reading. This page holds a template with a check behind every rule, and the decisions published projects made before you.
dfzoo AI Engineering writes AI contribution policies for engineering teams and open source projects, together with the pull request template, commit trailer convention and CI checks that make the policy hold. The policy settles four questions: who signs for code they did not type, where AI assistance is declared, what the author owes before review, and what the reviewer may reject unread. Every rule in the template is paired with who it binds and how it is checked by machine, because a policy that lives only in a document does not change the review queue. The policy feeds the risk register and the approved-tools list from the governance baseline, and a sampling audit of labelled pull requests verifies that it is followed.
Who this guide is written for.
- CTOs and VPs of Engineering whose teams already ship AI-assisted code and have no written rule for who signs it
- Open source maintainers receiving generated pull requests and looking for rules they can enforce instead of arguing about
- Engineering managers asked by legal or security for a document that says how AI-assisted code enters the codebase
- Vendor management teams accepting deliverables from contractors who use coding agents
Four questions the policy has to answer
Provenance disputes in 2026 are about responsibility, not about tools. The threads at the top of r/programming and r/opensource ask the same thing from two sides: the maintainer wants to know who answers for a 13,000-line generated pull request, and the engineer who inherited an almost entirely generated project wants to know whose name is on it. A September 2026 study of 281 AI policies in the 2,000 most-starred GitHub repositories and a set of well-known projects (Hora, Robbes and Zacchiroli) found that 83.3% permit AI in code contributions and 48.8% require disclosure. The working part of a policy is its conditions, and a usable policy is a list of conditions with a check behind each one.
- Who signs. The human who opens the pull request certifies origin, under the Developer Certificate of Origin or the company's equivalent, and takes the bug, the regression and the licence question with it. A tool never signs: the Linux kernel policy states that AI agents must not add Signed-off-by tags, because only a human can certify the DCO.
- What is declared and where. One scheme per organisation: a commit trailer, a field in the pull request template, or a label, chosen deliberately, not inherited from a tool default.
- What the author owes before asking for review. Understanding they can defend without the tool, tests they ran, a change within the size limit.
- What the reviewer may close without reading. Written down, so the review queue is what the policy protects and closing is a rule, not a personal decision.
Where the declaration goes: trailer, template field, label
Three mechanisms exist and they answer different questions. In the same study, among policies that require disclosure, the pull request description is the place named in 64.7% of cases and the commit message in 26.7%. Most teams end up needing two of the three.
Two conventions collide and the policy has to pick one. GitHub's Copilot cloud agent authors its commits as Copilot, with the human who started the task as co-author. Kubernetes prohibits listing AI as a co-author, because a tool cannot sign the contributor licence agreement, and turned on the CLA check for co-authors, so that such pull requests are flagged as not ready to merge. A company repository meets the same question the moment a customer contract requires an identified author, and the answer has to be configured in the tools, not only written in the policy.
| Mechanism | Who reads it | What it is good for | How it is checked |
|---|---|---|---|
| Commit trailer (Assisted-by: LLM in the Linux kernel; Generated-by: recommended by the Apache Software Foundation) | Tooling, and anyone reading the history later | Provenance per commit that survives squashes and forks; input for a machine-readable provenance file | A commit-msg hook and a CI lint with the list of allowed trailers |
| Field in the pull request template: tool, extent, what was verified by hand | The reviewer, before opening the diff | The explanation in the author's own words; the place where understanding is shown | CI fails when the field is empty or still holds the template text |
| Label (ai-assisted) | Dashboards, search, the audit sample | Counting, filtering, drawing the sample for a periodic audit | A bot sets the label from the template field; nobody has to remember |
What published projects decided
The lines below are read from the projects' own documents, not from commentary about them. They span a full ban to disclosure on request, and each is internally consistent: the rule matches the check the project is able to run.
| Project | Rule | Where it is written |
|---|---|---|
| Linux kernel | Permitted. Assisted-by: LLM trailer; agents must not add Signed-off-by; the human submitter reviews everything and certifies the DCO | Documentation/process/coding-assistants.rst |
| Kubernetes | Permitted with disclosure. No AI co-author or co-signing on commits; CLA check enabled for co-authors, flagging the pull request as not ready; reviewers engage with humans and review comments are not answered by a tool | Contributor blog, June 2026 |
| Apache Software Foundation | Permitted when the tool's terms grant rights to the output. Generated-by: token in the commit message; the contributor notifies the foundation if incompatibly licensed code is found later | ASF Generative Tooling Guidance |
| curl | Permitted for code that meets every normal requirement. AI use in security reports must be disclosed; made-up reports get an immediate ban | docs/CONTRIBUTE.md, section On AI use in curl |
| Ghostty | Permitted with full disclosure of tool and extent. The human must be able to explain the change without the tool; first-time contributors open a vouch request in their own words | AI_POLICY.md |
| Gentoo | Forbidden since April 2024 on copyright, quality and ethical grounds; enforced by trust rather than detection | Council AI policy |
| QEMU | Declined when content is believed to derive from AI generators, on DCO grounds. AI for research, static analysis and debugging is out of scope | docs/devel/code-provenance.rst |
| GitHub Copilot cloud agent | Commits authored by Copilot with the human as co-author. The person who asked for the pull request cannot approve it; Actions workflows wait for approval from someone with write access | GitHub Docs, responsible use of agents |
Understanding, tests, size: what the reviewer may close unread
The author's obligations decide whether review time is spent on the code or on finding out what the code is. Ghostty puts it in one sentence: if you cannot explain what your changes do and how they interact with the rest of the system without the tool, do not contribute. In a company the same rule has a practical form: the template field asks for the why in the author's words, and the reviewer may ask one question that has to be answered from understanding, with the session log closed.
Size is the second obligation, and it needs a number, not a mood. Google's engineering practices put 100 lines as usually reasonable and 1,000 as usually too large for one change, leaving the rest to the reviewer's judgement. Generated changes cross that upper bound easily, because adding is cheap for the tool. The policy sets a hard limit for AI-assisted pull requests and a route for the exception: a design note and a split plan.
Rules for closing unread keep the queue moving without turning each decision into a dispute. curl reports that below 5% of its security reports in 2025 were valid before it ended its bug bounty, and a GitHub product manager opened a public discussion at the turn of January and February 2026 on letting maintainers restrict or disable pull requests. The rule-based close is the lighter answer to the same pressure. What the reviewer may close without opening the diff:
- No linked issue or accepted proposal, for external contributions
- Size over the limit with no split plan
- The declaration field empty, or filled with text the reviewer recognises as generated
- Review comments answered by pasting tool output instead of a reply from the author
- Tests the author states were run, which CI shows never executed
Policy template: rule, who it binds, how it is checked
The table is the deliverable in short form. Each row is one rule, the group it applies to, and the check. A rule without a check does not go into the document.
| Rule | Who it binds | How it is checked |
|---|---|---|
| The person opening the pull request signs for origin and content; tools do not sign and are not listed as co-authors | Everyone, maintainers and contractors included | Commit trailer lint rejects AI co-author trailers; the CLA or DCO check covers co-authors |
| AI assistance is declared in the template field: tool, extent, what was verified by hand | Everyone | CI fails on an empty or unchanged field; label set by bot |
| The author can explain the change without the tool | Everyone; the reviewer may test it with one question | Reviewer checklist item; an unanswered question blocks merge |
| AI-assisted pull requests stay under the size limit or carry a split plan | Everyone | CI size gate on the diff, with an exception label and a design note |
| Tests run locally are named and also run in CI | Everyone | CI is the source of truth; the template lists the commands |
| Review comments are answered by a person | Contributors and maintainers | The reviewer may close after one tool-pasted reply |
| Only tools from the approved list, with output rights checked | Employees and contractors | Approved-tools list from the governance baseline; a contract clause for vendors |
| Reviewers who use AI to review sign the review as their own | Reviewers | The same declaration field on the review |
| The policy is reviewed on a schedule and after any incident | Engineering lead, as owner | Entry in the risk register with the review date |
How the policy connects to the risk register and the governance baseline
The policy does not stand alone. It is one of the artifacts in the governance baseline, next to the AI usage policy, the approved-tools list and the evaluation cadence, and it gives the risk register concrete entries: an unverified generated change merged, licence-incompatible output in the codebase, review capacity exhausted by volume, attribution that a contract does not accept. Each entry names the check from the template as its control.
Verification is a sample, not a belief. A periodic audit draws pull requests carrying the label, checks that the declaration matched the diff, that the author's explanation held up and that the tests named were the tests run, and reports the share that did not. It is the same sampling method as an independent evaluation of AI-assisted code, applied to the process instead of the code.
Where this goes wrong, and what we do about it.
- 1The trailer the editor added, and the policy that forbids it
In April 2026 VS Code changed the default of git.addAICoAuthor so that commits received a Co-authored-by: Copilot trailer; a defect attributed non-Copilot completions to Copilot as well, and the default went back to off in version 1.119 (microsoft/vscode issue #314311). For two releases, attribution in commit history was decided by an editor setting rather than by the author. A team whose policy forbids AI co-authors, as Kubernetes does, or whose customer contract requires an identified author, finds this in the history after the fact.
What we do about itWe pick one attribution scheme with you, write it into the policy, and configure it where commits are made: editor settings, the agent's commit identity, a commit-msg hook that rejects trailers outside the allowed list. Then we scan the history for the trailers that already got in and record the decision about them.
What stays with you: attribution scheme in the policy, repository hook and CI lint, plus a history scan report listing the affected commits - 2A disclosure threshold written as 'significant'
Policies say that 'significant' or 'substantial' AI use must be disclosed. The study of the 1,000 most-starred repositories (Hora and Robbes, July 2026) names exactly these words as the recurring ambiguity. With no observable trigger two things happen at once: careful engineers declare everything, so the label carries no information, and the rest declare nothing, because accepting a completion never felt significant.
What we do about itWe replace the adjective with triggers you can observe: any diff hunk accepted from a tool without edits, any agent session, any tool from the list. Then we calibrate the threshold against your recent pull requests and show what share would have needed a declaration, so the rule is adjusted before it is announced, not after it is ignored.
What stays with you: decision table for the declaration, plus a calibration report on your recent pull requests - 3The author signs, the agent answers the review
A reviewer asks why a function changed. The author's knowledge of the change is the agent's summary, so the reply is pasted from the agent, the follow-up question gets the next summary, and the review becomes a conversation between the reviewer and a tool with a person forwarding messages. Kubernetes wrote its rule for this case: reviewers engage with humans, and review comments are not answered by a tool. The 13,000-line pull requests maintainers discussed in early 2026 are the extreme form: nobody could have answered.
What we do about itWe put the explanation field in the template and the one-question right in the reviewer checklist, and we size-gate AI-assisted pull requests so that a question is answerable. When the review stalls on a tool-pasted reply, the checklist says close, and the policy stands behind the reviewer.
What stays with you: pull request template with the explanation field, and the reviewer checklist with the close rules - 4The policy says 'review everything' and the queue is the bottleneck
A policy that raises the bar for authors changes nothing about how many pull requests arrive. curl saw the valid share of its security reports drop below 5% in 2025 and ended its bug bounty; GitHub opened a discussion on letting maintainers restrict pull requests. In a company the same pressure looks like review latency climbing while everyone follows the document, because the document put all of its rules on the author and none on the intake.
What we do about itWe move the mechanical rules to the intake: linked issue, size, declaration field, tests in CI, checked by a bot before a person spends a minute. Then we measure time to first review and the share closed without review, monthly, so the limit is tuned on numbers, not on frustration.
What stays with you: intake checks in CI and a monthly report with time to first review and the share closed by rule - 5The DCO signed for output nobody checked the rights to
The Developer Certificate of Origin has the contributor certify that they created the contribution or have the right to submit it under the licence. The Apache Software Foundation spells out what that means for generated code: the tool's terms must grant rights to the output, and the output must not carry third-party code under an incompatible licence. Signing without having checked either is common, because the tool list was never written down and nobody read the terms for this clause.
What we do about itWe add an output-rights column to the approved-tools list, with the clause and the date it was read, and we run licence scanning on files carrying the label so that reproduced code surfaces before release. The policy names who is told when it does, as the ASF guidance requires of its contributors.
What stays with you: approved-tools list with an output-rights column, and a licence scan wired to the ai-assisted label
What stays with you.
- AI contribution policy: one document, rule / who it binds / how it is checked, covering employees, contractors and outside contributors
- Pull request template with the declaration field and the explanation field, plus the commit trailer convention
- Repository configuration: commit-msg hook, CI checks for trailers, size, declaration and tests, label bot
- Reviewer checklist with the rules for closing unread
- Calibration report of the disclosure threshold on your recent pull requests
- Risk register entries for AI-assisted contributions, each mapped to a control from the policy
- Approved-tools list extended with an output-rights column
- One-page summary for managers and for the contributor guide
How we work.
- 11. Reading the current state
We scan the commit history for AI trailers and co-authors, measure pull request sizes and review latency, and read what your contributor guide and contracts already say. The output is a table of facts, not an opinion.
Days 1-3 - 22. Policy draft and threshold calibration
We write the rules with the check behind each one and calibrate the disclosure trigger against your recent pull requests, then review the draft with engineering, legal and, where relevant, the maintainers.
Week 1-2 - 33. Tooling and rollout
We configure the template, the hook, the CI checks and the label bot, run them in report-only mode for one cycle, then switch them to blocking. The reviewer checklist goes out with a short session for reviewers.
Week 2-3 - 44. Handover and first audit
We hand over the policy, the configuration and the register entries, and come back after the first full cycle to draw a sample of labelled pull requests and report how the rules held.
Week 3, then after the first cycle
The rest of this cluster.
Prompt cache forensics and spend limits
How to attribute LLM cost to a call, session and feature, how Anthropic, OpenAI and Google bill prompt caching, what quietly breaks the cached prefix, and where an alert ends and a hard stop begins.
Measuring the real effect of AI in a team
Why faster ticket closure is not evidence, what the 2025-2026 controlled experiments measured, how to design a baseline, paired metrics and a comparison group, and which per-person metrics to avoid.
Comparing AI code review tools
Why vendor rankings of AI code review tools are not comparisons, which metrics they leave out (precision per class, off-diff comments, invented findings, cost per PR), and a protocol for your own PRs.
Where this turns into a service.
Where the dates and numbers come from.
- Linux kernel documentation: AI Coding Assistants (Assisted-by tag, Signed-off-by rule)
- Developer Certificate of Origin 1.1
- Hora, Robbes, Zacchiroli: "We Permit the Use of AI, but [...]": The Landscape of AI Policies in Popular Open Source Projects (arXiv 2609.07542, September 2026)
- Hora, Robbes: AI Policy, Disclosure, and Human in the Loop: How Are Contribution Guidelines Adapting to GenAI? (arXiv 2605.16706, July 2026)
- Kubernetes contributor blog: Open source maintainership in the age of AI (26 June 2026)
- Apache Software Foundation: Generative Tooling Guidance
- curl: Contributing, section On AI use in curl
- Ghostty: AI Usage Policy
- Gentoo Council: AI policy (14 April 2024)
- QEMU documentation: Code provenance
- GitHub Docs: Responsible use of GitHub Copilot agents
- GitHub Blog: GitHub Copilot, meet the new coding agent
- microsoft/vscode issue #314311: update on Co-authored-by: Copilot in commit messages
- Google Engineering Practices: Small CLs
- Daniel Stenberg: The end of the curl bug-bounty (26 January 2026)
- The Register: GitHub considers letting maintainers restrict pull requests (3 February 2026)
Questions teams ask.
Talk to an engineer.
Describe where you are with your AI contribution policy. A reply within one business day.