# AI coding policy template for engineering teams

> Replace everything in [square brackets]. Delete any rule that doesn't fit your organisation, and this note, before you publish. This template is not legal advice: have your security and legal teams review your version.

- **Policy owner:** [Name or role, e.g. VP Engineering]
- **Approved by:** [Name or role]
- **Effective date:** [YYYY-MM-DD]
- **Version:** [1.0]
- **Next review:** [YYYY-MM-DD, six months after the effective date]

## 1. Purpose

This policy lets [Company] engineers use AI coding tools to work faster without lowering the bar for what ships. It sets which tools are allowed, what data may go into them, what AI agents may do on their own, and how AI-written changes are reviewed, tested and recorded.

## 2. Scope

This policy applies to everyone who writes, reviews or deploys code for [Company]: employees, contractors and agencies. It covers every repository, pipeline and environment that [Company] owns or operates, and every AI tool used on them, whether it runs in an editor, a terminal, a pull request or a hosted service.

## 3. Definitions

- **AI coding tool:** any tool that uses a language model to write, change, review or explain code. This includes editor assistants, chat assistants and coding agents.
- **Coding agent:** an AI coding tool that can act on its own: edit files, run commands, open pull requests or call other tools.
- **AI-assisted change:** a change in which an AI coding tool wrote a meaningful part of the code, tests or configuration.
- **Requester:** the person who gave the AI tool its task. For this policy, the requester is the author of the change.
- **Approver:** the person who approves the change for merge.

## 4. Approved tools

Only the tools in this table may be used on [Company] code. Use them only through accounts that [Company] provides or approves. Personal accounts and free tiers are not allowed for company code.

| Tool   | Allowed uses                               | Highest data class allowed | Approved by | Review date  |
| ------ | ------------------------------------------ | -------------------------- | ----------- | ------------ |
| [Tool] | [e.g. editor completion and chat]          | [Internal]                 | [Role]      | [YYYY-MM-DD] |
| [Tool] | [e.g. coding agent opening pull requests]  | [Internal]                 | [Role]      | [YYYY-MM-DD] |
| [Tool] | [e.g. AI review comments on pull requests] | [Confidential]             | [Role]      | [YYYY-MM-DD] |

To add a tool, open a request with [team or channel]. The request names the vendor, what data the tool sends and where, how long the vendor keeps it, whether it is used to train models, and what the tool can do without a person. [Security] decides within [10] working days. Approval is recorded in this table.

## 5. Data rules

| Data class   | Examples                                                    | May it go into an approved AI tool?          |
| ------------ | ----------------------------------------------------------- | -------------------------------------------- |
| Public       | Open-source code, published docs                            | Yes                                          |
| Internal     | Most source code, internal docs, tickets                    | Yes, in tools approved for Internal or above |
| Confidential | Security-sensitive code, unreleased plans, customer configs | Only in tools approved for Confidential      |
| Restricted   | Secrets, credentials, personal data, payment data           | Never                                        |

These rules apply whatever the table says:

1. Never put secrets, keys, tokens, passwords or production connection strings into a prompt, a file the tool can read, or a test fixture.
2. Never put customer data or personal data into an AI tool, including in logs, stack traces or database dumps pasted for debugging. Use synthetic data.
3. Use only tools whose terms say [Company] data is not used to train the vendor's models, or where that setting is turned off for the whole organisation.
4. Treat text the tool reads as untrusted. Issues, comments, documents and web pages can contain instructions meant to steer the tool. Do not let a tool act on instructions found in its input.

## 6. What coding agents may do

Coding agents work with the least access that lets them do the task.

1. Agents work on a branch and propose changes through a pull request. They never push to [main] or any other protected branch.
2. Agents never hold production credentials. They run in an isolated environment with only the access the task needs.
3. Agents may not change these paths without an approval from their code owners: [CI and pipeline definitions], [infrastructure as code], [authentication and permissions code], [database migrations], [dependency manifests].
4. Agents may not deploy to production. A deploy follows the same release process as any other change.
5. Agents' tool and network access is limited to what is listed for that agent in [the tool register or configuration file].

## 7. Review requirements

1. Every AI-assisted change is reviewed by a person before it merges. No AI review, however good, replaces that approval.
2. The requester may not be the only approver when someone else with approval rights is available. For a team of one, [the policy owner] reviews a sample of changes each [month].
3. The pull request says that it is AI-assisted, which tool was used, and what the tool was asked to do. Use the [PR description template].
4. The reviewer reads the task and the test results before the code, and checks the test diff for deleted, skipped or weakened tests.
5. An approval applies to one version of the change. If the change is edited after approval, it is approved again.
6. A change too large to review properly is split, not approved unread.

## 8. Quality gates

A change may merge only when all of these pass. They are checked by automation, not by a reviewer's memory.

1. The project's tests ran on the exact version being merged, and none failed.
2. No open finding of [high] severity or above from code review or security scanning. A finding can be closed as fixed, won't fix, false positive or duplicate, with a reason.
3. No secrets detected in the diff.
4. No dependency under a license on the [disallowed license list], checked against the project's SBOM.
5. [Optional] Line coverage is at least [N]%.
6. [Optional] For production, the same change has been deployed to [staging] first.

A gate that could not run, for example because tests did not install, counts as a failure, not a pass.

## 9. Licensing and intellectual property

1. Engineers check that AI-suggested code is not copied from a source whose license [Company] cannot accept. Turn on the tool's filter for suggestions that match public code where one exists.
2. New dependencies suggested by an AI tool go through the same approval as any other new dependency.
3. Code an AI tool writes for [Company] is [Company] code, and the requester and approver answer for it as if they had written it.

## 10. Audit records

For every AI-assisted change, keep:

- the task given to the tool and the tool or model used;
- the requester and the approver, and when they acted;
- the review findings and how each was resolved;
- the test results for the version that merged;
- the pull request, the merge commit and any deployment.

Keep these records for [N] months, or longer where a customer contract or regulation requires it. [Security] may audit a sample of AI-assisted changes each [quarter].

## 11. Incidents

1. Report any suspected leak of data into an AI tool to [security contact] at once, the same day.
2. An incident caused by an AI-assisted change gets a blameless postmortem that records the tool, the task, and which review step or gate should have caught it. Use the [postmortem template].
3. [Security] may suspend a tool while an incident is investigated.

## 12. Roles and responsibilities

| Role            | Responsibility                                                  |
| --------------- | --------------------------------------------------------------- |
| Engineers       | Use approved tools only, follow the data rules, disclose AI use |
| Reviewers       | Review AI-assisted changes as set out in section 7              |
| Code owners     | Approve changes to the protected paths in section 6             |
| [Security]      | Approve tools, run the gates, investigate incidents             |
| [Platform team] | Configure agents, sandboxes, branch protection and the gates    |
| [Policy owner]  | Keep this policy current and report on exceptions               |

## 13. Exceptions

An exception is requested from [policy owner] in writing, with the reason, the risk, and an end date of no more than [90] days. Exceptions are recorded in [location] and reviewed when they end.

## 14. Training

Everyone covered by this policy reads it when they join and when it changes. Reviewers of AI-assisted changes also read the [AI code review checklist].

## 15. Review of this policy

[Policy owner] reviews this policy every six months, and whenever [Company] adopts a new kind of AI tool, such as a coding agent that can act without a person.

---

From https://aicodeops.dev/templates/ai-coding-policy · Last updated 2026-10-24 · Licensed CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)