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.

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

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

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.

About this template

This section explains the template. It is on the web page only, not in the downloads.

The policy is built around one idea: an AI tool may write the change, but a person approves it and automation checks the evidence. Sections 4 and 5 decide what goes into a tool. Section 6 limits what an agent can do on its own. Sections 7 and 8 decide what comes out. Section 10 makes the whole thing provable later.

To adopt it, fill in the brackets, then turn each rule in sections 6 and 8 into a setting: branch protection, a code owners file, a CI check. A rule nobody enforces will drift. The CODEOWNERS starter covers the protected paths, the AI code review checklist gives reviewers section 7 in 25 checks, and the pull request template and the postmortem template fill in the blanks sections 7 and 11 point to.

If you use AI CodeOps, several rules are settings there. A workspace policy can allow a session's file changes and pull requests, hold them for an approval, or deny them, by file path or repository, and can stop automatic deploys by environment (policy rules). Every code change a session makes opens a review request, and the person who started the session can't cast the approving vote while someone else can approve (approvals). The release gate your CI calls checks tests, open findings, disallowed licenses and staging promotion. The audit log, and a signed evidence pack per change, keep the records in section 10.