Owner: [name, role] · Agreed: [date] · Next review: [date, three months from now]
1. Why we have this
We use AI tools to move faster, and we stay responsible for everything we ship. This policy sets out which tools we use, what they may see, and how AI-written changes get reviewed. It covers everyone who commits to [repositories or services], including contractors.
2. Approved tools
| Tool | Approved for | Account type | Notes |
|---|---|---|---|
| [e.g. GitHub Copilot] | [Code completion in the IDE] | [Company business plan only] | [Our plan does not train on our code] |
| [e.g. Claude Code / Codex / Cursor] | [Agent tasks in local checkouts] | [Company account] | [See section 6 for agent rules] |
| [e.g. Company chat assistant] | [Questions, explanations, drafts] | [Company SSO] |
Personal accounts and tools not on this list are not used with [company] code or data. To propose a new tool, ask [owner]. We aim to answer within [two weeks].
3. What never goes into an AI tool
Whatever you paste or let an agent read may leave your machine. Never share:
- Secrets: API keys, tokens, passwords, connection strings,
.envfiles, private keys, and logs or stack traces that contain any of them. - Personal and customer data: real names, emails, phone numbers, addresses, account records, support tickets, production database dumps.
- [Restricted code or data: e.g. payments, security-critical modules, code licensed from a third party, anything under NDA].
Use fake data of the same shape instead, for example ana@example.com for a customer's address. If something was shared by mistake, tell [security contact] the same day and rotate any secret involved. Nobody is blamed for reporting it.
4. Every change has a human owner
- The person who opens the pull request owns the change, whether they typed it, an assistant suggested it or an agent wrote it. "The AI wrote it" is never an explanation for a bug.
- The owner must be able to explain every line. If you cannot explain it, do not submit it.
- The owner runs the full test suite before asking for review, not only the new tests.
5. Review
- Say when AI wrote a substantial part of a change. Add
[AI-assisted]in the PR description, with a sentence on what it did, for example "agent wrote the migration and tests; I rewrote the validation". This is not a penalty. It tells the reviewer where to look. - Reviewers use a checklist: the AI code checklist or our own version of it. Pay most attention to new dependencies, changed or deleted tests, and changes outside the scope of the request.
- Changed tests need a reason. A PR that edits or deletes an existing assertion must say which decision allows it.
- Keep PRs small: about [400] changed lines at most, excluding generated files. Split larger AI-generated changes before review.
- Review by risk:
| Risk | Examples | Required |
|---|---|---|
| Low | Copy, styling, logs, internal scripts | One reviewer |
| Medium | Changes to existing user-facing features | One reviewer using the checklist; the owner's own tests included |
| High | Data writes or migrations, authentication and access, input validation, payments, shared libraries, infrastructure | Two reviewers, one of them [a senior engineer / code owner]; risky cases tried by hand on [staging] |
- Reply time: a first review comment within [one working day] for low and medium changes and [four working hours] for high-risk ones. Approval can take longer.
6. Agents
Coding agents can run commands and edit many files, so they get tighter rules.
- Agents run in [local checkouts / disposable environments], never with production credentials or production database access.
- Agents may [open draft PRs] but may not merge, deploy, change CI configuration or edit secrets.
- Agent-opened PRs record who started the agent, which tool and model it used, and what it had access to. [Use the PR template field / commit trailer.]
- Repository instructions for agents live in [
AGENTS.md/CLAUDE.md]. Changes to those files are reviewed like code. - Review permission prompts before you approve them. Do not use "allow everything" modes on [company] repositories.
7. Licensing and dependencies
- New dependencies an assistant suggests get the same check as any other: confirm the package exists, is the one intended, is maintained and has a licence compatible with [our licence policy].
- If a tool flags that a suggestion matches public code, [follow the tool's guidance / remove it / ask owner].
8. Measuring whether it helps
Each [month or quarter], [owner] reviews:
- time from PR opened to first review, and to merge
- rework: changes reverted or fixed within [14] days of merging
- change failure rate: deploys that cause an incident or need a rollback
- a two-question team pulse: "Do AI tools save you time?" and "Do you trust what you merge?"
We do not measure lines of code, the number of PRs, or each person's AI usage, and we do not use these figures in individual performance reviews.
9. Changing this policy
Anyone can propose a change to [owner] or in [channel]. We revisit the whole policy on the review date above, because the tools change faster than most policies do.
Template by Ghost in the Repo, ghostintherepo.com. Free to copy, adapt and use in your team.