AI Code Ownership Policy: Who Is Accountable for Agent-Written Code
Mark aistrategy.guide as a preferred source Our AI strategy guides show up more often, with a Preferred badgeHow to write an AI generated code policy that names a human owner for every agent-written change: accountability and DRIs, review requirements by risk tier, audit trail, licensing and IP points to raise with counsel, and sample policy clauses you can adapt.
An AI generated code policy has one job: make sure every change that reaches production has a named human who owns it. Everything else in the policy (review tiers, labelling, licensing checks, audit records) exists to make that ownership real rather than nominal. Most first-generation policies I see fail the same way. They ban or permit tools, list approved vendors, and say nothing about who answers for the code once an agent has written it and another agent has reviewed it.
That gap is widening. When agents write the change and AI reviewers check it, a pull request can pass through the whole pipeline with a human only clicking merge. James Stanier’s “Put a name on it” makes the case for named DRIs in the AI era, and the logic is simple: accountability that is shared between a person and two tools is accountability nobody holds. This page covers how to assign it, how to tier review by risk, what to record, which IP questions to take to counsel, and sample clauses to adapt.
This is a governance page, not legal advice. The licensing section summarises public sources so you can brief your lawyers; it does not replace them.
Who owns a change an agent wrote?
The person who caused it to exist. A policy should name one directly responsible individual (DRI) for every change, and the default is the engineer who started the agent’s task or opened the pull request. That person answers for the change exactly as if they had typed it: correctness, security, licence compliance, and the on-call consequences.
Three roles sit around every agent-written change, and the policy should name each.
| Role | Who | Accountable for |
|---|---|---|
| Change owner (DRI) | The engineer who initiated the agent work or opened the PR | The change itself, its intent, and fixing it if it breaks |
| Approving reviewer | A human with merge rights on the affected code | The quality of the review, at the depth the risk tier requires |
| Tool owner | A named engineering lead per tool | The agent’s and AI reviewer’s configuration, rule files and permissions |
Two things are never owners: the agent, and the vendor. An agent cannot be paged, disciplined or asked why. A vendor’s terms will not make it accountable for your production behaviour. The third role is the one most policies miss. Someone must own each AI reviewer’s rule file and each agent’s instruction file, because those files decide what gets flagged and what gets written. A learned preference in a review tool that nobody can read is a policy nobody approved.
Autonomous agents that open pull requests on their own, from a schedule or a ticket, still need a DRI. Assign it to the person who owns the automation, and require that person’s name on every PR it opens.
How should review requirements scale with risk?
Tie the review requirement to what the change touches, not to who or what wrote it. Treating all AI code as high risk produces a review queue nobody can drain; treating it all as low risk lets an agent’s guess about authentication reach production. Define tiers by path and by type of change, enforce them in branch protection and CODEOWNERS, and let the agent’s self-assessment play no part in the tier.
| Tier | Typical scope | Review requirement |
|---|---|---|
| 0: Trivial | Docs, comments, test-only changes, dependency patch bumps with passing CI | AI review plus one human approval; may be the DRI’s lead in batch |
| 1: Standard | Feature code inside a service, no schema, auth or public API change | AI review plus one human approval from a code owner of the path |
| 2: Elevated | Public APIs, data models, migrations, cross-service calls, performance-critical paths, new dependencies | Human code-owner approval, an intent note listing assumed decisions, and an ADR if the change is architectural |
| 3: Critical | Authentication, authorisation, payments, cryptography, personal-data handling, deletion paths, infrastructure permissions | Two human approvals, one from security or the domain owner; AI review findings must be resolved or explicitly waived by a human |
Two rules make the tiers work. First, the AI reviewer is never the required approver above tier 0. That aligns with how the tools ship: Claude Code Review never approves or blocks, and GitHub Copilot’s reviews do not count toward required approvals unless an admin turns that on. Second, the tier comes from path rules, so an agent cannot lower its own bar. The intent-note template on architecture decision records for AI-generated code carries the tier and the deliberate-versus-assumed split reviewers need for tiers 2 and 3.
What should the audit trail record?
Enough to answer, months later, four questions: who owned this change, which tool produced it, who approved it, and what the reviewer saw. Most of that already exists in the pull request if the policy requires it.
- Authorship label. A commit trailer naming the agent (
Co-Authored-By: <agent>is a common convention, and some agents add it by default), or a PR label such asai-generated. - Tool and version. Which agent, which model where the tool exposes it, which configuration. Instruction and rule files are versioned in the repository, so the commit hash covers them.
- Session or task link. The agent session, ticket or automation run that produced the change, linked in the PR description.
- Intent note. For tier 2 and 3, the deliberate and assumed decisions, written before review.
- Review record. The human approvals (branch protection logs these) and the AI reviewer’s findings with how each was resolved.
- Waivers. Any tier-3 finding merged without a fix, with the name of the human who waived it and why.
Keep retention aligned with your existing SDLC records. If you are in scope for SOC 2 or ISO 27001, these records are change-management evidence you will be asked for anyway. The CISO’s AI governance responsibilities page covers where that evidence sits in a wider control set.
What licensing and IP questions should go to counsel?
Three questions, each with public sources you can hand to your lawyers. None of this is legal advice.
Can the organisation claim copyright in AI-generated code? In the US, the Copyright Office’s report “Copyright and Artificial Intelligence, Part 2: Copyrightability” (January 2025) concluded that, with current generally available technology, prompts alone do not provide sufficient human control to make the user the author of the output, while human selection, arrangement and creative modification of AI output can be protected. In Thaler v. Perlmutter, the D.C. Circuit held in March 2025 that the Copyright Act requires a human author, and the Supreme Court declined to hear the case in March 2026. Other jurisdictions differ. For code, which is usually heavily edited and combined with human work, the practical question for counsel is how much of your codebase’s value depends on copyright as opposed to trade secrets and contracts.
Who owns the output under the vendor contract? Read the terms of each tool. Anthropic’s commercial terms, for example, state that the customer owns its outputs and that Anthropic assigns to the customer any rights it has in them. An assignment of whatever rights exist does not create rights that copyright law withholds.
What happens if the output reproduces someone else’s code? Several vendors offer IP indemnities with conditions. Anthropic’s commercial terms indemnify against claims that outputs from authorised, paid use infringe third-party IP, but exclude, among other things, claims arising from modifications to outputs, from combining outputs with technology Anthropic did not provide, and from use the customer knew or should have known infringes. GitHub offers IP indemnity for Copilot Business and Enterprise subject to conditions that include its setting for suggestions matching public code. In software almost every output is modified and combined, so ask counsel how much these indemnities cover in your actual workflow. Operationally, keep your existing licence scanning and software composition analysis running on all code regardless of author, and turn on public-code matching filters where your tools offer them.
Sample policy clauses
Adapt these to your organisation’s language. They assume your existing SDLC policy already covers branch protection and code owners.
1. Scope. This policy applies to any source code, configuration, infrastructure definition or test written or modified wholly or partly by an AI system, including coding agents, IDE assistants and automated pull-request agents.
2. Ownership. Every change has one named human change owner. By default this is the person who initiated the AI system’s work or opened the pull request. For changes opened automatically by an agent, the owner is the person accountable for that automation. The change owner is accountable for the change to the same standard as for code they wrote themselves.
3. Non-delegation. An AI system cannot be a change owner, a code owner or a required approver for changes above Tier 0.
4. Risk tiers. Review requirements follow the tier table in Appendix A. Tiers are assigned by repository path and change type through code-owner and branch-protection rules, not by the AI system or the change owner.
5. Disclosure. Commits or pull requests produced with material AI assistance carry an authorship trailer or label and link to the originating session, task or automation run where one exists.
6. Intent. For Tier 2 and Tier 3 changes, the pull request includes an intent note listing deliberate decisions and decisions assumed by the AI system. Architectural decisions are recorded as ADRs; AI systems may draft ADRs with status Proposed but may not accept or modify Accepted ADRs.
7. AI review. AI review findings are advisory. For Tier 3, every Important or equivalent finding is resolved or waived in writing by a human approver, with the reason recorded on the pull request.
8. Tool configuration. Each approved AI system has a named tool owner who maintains its instruction and rule files in version control, reviews any learned preferences the tool exposes, and approves changes to its repository permissions.
9. Licensing. Licence scanning and software composition analysis apply to all code regardless of author. Where a tool offers filtering of suggestions matching public code, it is enabled unless the tool owner and legal approve an exception.
10. Data. AI systems are used only under the data classification permitted for the repository, through accounts and plans approved by security.
11. Records. Pull-request records, approvals, AI review findings and waivers are retained under the existing change-management retention schedule.
For a broader template covering employee use of AI beyond code, ctaio.dev’s AI policy template is a useful starting point; this policy can sit underneath it as the engineering annex.
How do you roll this out without stalling delivery?
Start with clauses 2, 3 and 5, which cost almost nothing: name the owner, keep AI out of the required-approver set, label the commits. Then encode tiers 2 and 3 in CODEOWNERS and branch protection for the handful of paths that matter most. Add intent notes once the tiers are working. The expensive mistake is the reverse order, a forty-page policy with no enforcement in the repository, which engineers route around within a quarter.
Review volume will rise as agents write more code, which is the bottleneck covered in AI code review. Tiering is how the policy keeps human attention on the changes that can actually hurt you. For choosing the AI reviewer that feeds those humans, see CodeRabbit alternatives, and for the wider governance programme, the governance hub and the enterprise AI governance framework.
Verdict: an AI code policy that does not put a human name on every change is a tool list. Name the owner, tier the review by what the change touches, and keep the record.
Sources & methodology
- U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability (January 2025), summary via Copyright Alliance
- Thaler v. Perlmutter, D.C. Circuit, 18 March 2025; certiorari denied 2 March 2026 (Reed Smith summary)
- Anthropic Commercial Terms of Service, sections on output ownership and indemnification
- GitHub Copilot trust and legal resources on IP indemnity conditions
- Anthropic: Claude Code Review and GitHub Docs: Copilot code review, approval behaviour of AI reviewers
- James Stanier, “Put a name on it” (The Engineering Manager), on DRIs in the AI era, as featured in Tech Manager Weekly #504 (19 October 2026)
- Methodology: legal points summarise public primary and secondary sources as of 19 October 2026 and are not legal advice. The tier table and clauses are an original framework for this page, free to adapt.
