What belongs in an AI coding policy for development teams?

Eight sections cover the working cases: sanctioned tools and accounts; data rules per classification level; task rules (written intent before agent runs); verification duties per change; evidence and audit trail; agent permission limits (no auto-commit); exceptions and how to request them; and ownership with a review cadence. Everything else - philosophy, tool tutorials, legal essays - belongs somewhere else. A policy that fits on two screens gets read; one that fills forty pages gets signed and ignored.

How is this different from your AI coding governance article?

The governance article is the overview: why control matters, the building blocks, how to introduce them, with a one-screen mini policy as illustration. This page is the deep dive on one building block - the policy document itself: a full section-by-section template with the reasoning per section and the adaptation notes for team size and regulation level. Read the overview first if governance is new territory; start here if you already know you need the document.

Do small teams really need a written policy?

A five-person team does not need a policy department - it needs the same eight decisions made once and written down, which takes about an hour with the template. The written form matters even at small scale for three reasons: onboarding stops being oral tradition, client and auditor questions get a document instead of a shrug, and the rules survive the person who invented them. Scale the ceremony down, not the decisions.

How do we introduce a policy without triggering resistance?

Write it with the people it binds, not for them - a one-hour session where the team fills in the template beats a decree from above. Anchor every rule to a failure mode people recognize (secrets in prompts, unreviewed agent merges) rather than to authority. And keep the enforcement mechanical where possible: a verification gate that runs per change enforces itself, while a rule that depends on manual vigilance becomes optional under deadline pressure.

How often should the policy be reviewed?

Quarterly is the honest default in 2026 - tool capabilities, vendor terms and the legal frame all move fast enough that an annual cycle guarantees staleness. The review is small: does the tool list still match reality, did any incident or near-miss expose a gap, did vendor terms or regulation change. Assign one named owner; policies without an owner do not get reviewed, they get rediscovered after an incident.

What makes a policy enforceable instead of decorative?

Every rule needs a mechanism, and the template forces that question per section: tool rules enforce through managed accounts, data rules through filters and local processing, task rules through the agent workflow, verification rules through a gate that runs per change, evidence rules through reports generated as a byproduct. The test: if every developer forgot the policy tomorrow, which rules would still hold? Those are your enforced rules - the rest is documentation of intent.

Governance

The AI Coding Policy Template

Last updated: 2026-07-026 min read

An AI coding policy needs eight sections: sanctioned tools, data rules per classification, task rules for agent runs, verification duties per change, evidence, agent permission limits, exceptions, and ownership with a review cadence. The complete template is on this page – ungated, ready to adapt. The design principle behind it: every rule carries its enforcement mechanism, because a rule that depends on memory becomes optional under deadline pressure.

Contents

Why a policy - and why this one is short

The numbers behind the need are stark in their mismatch: 84% of developers use AI tools, while only 48% consistently verify what those tools produce – in most teams, the rules exist as folklore. Our governance overview covers the full control picture; this page carries the one artifact everything else hangs on. It is deliberately short. Policies fail by length: the forty-page version gets signed once and never opened, and its authors mistake the signature for adoption.

The eight sections, and why each earns its place

Tools & accounts. What is sanctioned, on which account tier – because consumer logins are the classic data-protection violation.
Data rules. What may reach which tool, by classification level – the section your DPO and clients will read first.
Task rules. Agent runs get written intent with boundaries before the run – the anchor for everything checkable.
Verification. What must pass per change, and that validation is not authored by the generating model.
Evidence. A record per run, stored with the code – your audit trail growing as a byproduct.
Agent permissions. Advisory by default, no auto-commit, no production access – the section incidents have made non-negotiable.
Exceptions. How to request one, who approves, where it is logged – because a policy without an exception path gets bypassed instead of amended.
Ownership & review. One named owner, quarterly review – unowned policies are rediscovered after incidents, not before.

The template

ai-coding-policy.md

Example – adapt to your team

# AI Coding Policy · <team> · v1.0 · owner: <name> · review: quarterly

## 1 Tools & accounts
Sanctioned: <Claude Code, Cursor, Copilot> on company accounts only.
Consumer/free tiers: prohibited for work. New tools: ask <owner>.

## 2 Data rules
Public/internal code: allowed in sanctioned tools.
Confidential (client code, infra/secrets/*, prod data): local
processing only - never into cloud prompts or context.
Personal data in prompts/fixtures/logs: prohibited (see DPO note).

## 3 Task rules (agent runs)
Every agent run has a written task BEFORE it starts:
goal · boundaries (files/dirs it may touch) · acceptance criteria.
No task, no run - "quick fixes" included.

## 4 Verification (per change)
Must pass before review: build · types · tests relevant to the change.
Validation must not be authored by the generating model/session.
Change is checked against the task (scope + criteria).

## 5 Evidence (per run)
A run record is stored with the code: task, tool+version, diff scope,
validations + results, skips, approver.

## 6 Agent permissions
Agents are advisory by default: propose, never apply unattended.
No auto-commit. No direct writes to protected branches.
No production systems, credentials, or customer data access.

## 7 Exceptions
Request to <owner> with reason + expiry date. Logged in <register>.
Expired exceptions auto-revert to policy.

## 8 Incidents
AI-attributed defect or data slip: report to <channel> within 24h.
Blameless review; policy gap check is part of every postmortem.

Adaptation notes: a five-person team can merge sections 7 and 8 into two lines; a regulated team extends section 2 with its classification scheme and section 5 with retention rules. What should survive every adaptation is the structure of section 4 and 6 – verification per change and advisory-by-default agents are the two rules that carry the most risk when they erode.

Common failure modes

The forty-page policy. Completeness feels responsible and reads as noise. Every section that does not change behavior dilutes the ones that must.
Ban-everything. With 84% adoption, prohibition does not stop usage – it stops disclosure. The BSI/ANSSI line – enable with rules, verify output – is both safer and enforceable.
Rules without mechanisms. “Developers should carefully review AI code” is a wish. A gate that runs per change is a rule. Write only rules you can back with a mechanism, and name the mechanism in the policy.

Where Reality Graph fits

Sections 3 through 6 of the template describe, almost line by line, what Reality Graph mechanizes: written tasks with boundaries, verification of each run against them, an evidence report per run, advisory-by-default with no auto-commit as architecture rather than promise. The policy stands on its own without any specific tool – Reality Graph turns its middle sections from manual discipline into defaults.

This template gives you

Eight sections with the reasoning per section
The full document in-page - no download gate
An enforcement mechanism named per rule
Adaptation notes for small and regulated teams

It does not give you

Legal review - your counsel reads it before it binds anyone
A policy that works unadapted - the placeholders are real work
Enforcement by itself - mechanisms must actually be wired up
Coverage of AI beyond coding - scope it or extend it deliberately

If these boundaries fit how your team wants to ship:

Get early access See how it works

FAQ

What belongs in an AI coding policy for development teams?: Eight sections cover the working cases: sanctioned tools and accounts; data rules per classification level; task rules (written intent before agent runs); verification duties per change; evidence and audit trail; agent permission limits (no auto-commit); exceptions and how to request them; and ownership with a review cadence. Everything else - philosophy, tool tutorials, legal essays - belongs somewhere else. A policy that fits on two screens gets read; one that fills forty pages gets signed and ignored.
How is this different from your AI coding governance article?: The governance article is the overview: why control matters, the building blocks, how to introduce them, with a one-screen mini policy as illustration. This page is the deep dive on one building block - the policy document itself: a full section-by-section template with the reasoning per section and the adaptation notes for team size and regulation level. Read the overview first if governance is new territory; start here if you already know you need the document.
Do small teams really need a written policy?: A five-person team does not need a policy department - it needs the same eight decisions made once and written down, which takes about an hour with the template. The written form matters even at small scale for three reasons: onboarding stops being oral tradition, client and auditor questions get a document instead of a shrug, and the rules survive the person who invented them. Scale the ceremony down, not the decisions.
How do we introduce a policy without triggering resistance?: Write it with the people it binds, not for them - a one-hour session where the team fills in the template beats a decree from above. Anchor every rule to a failure mode people recognize (secrets in prompts, unreviewed agent merges) rather than to authority. And keep the enforcement mechanical where possible: a verification gate that runs per change enforces itself, while a rule that depends on manual vigilance becomes optional under deadline pressure.
How often should the policy be reviewed?: Quarterly is the honest default in 2026 - tool capabilities, vendor terms and the legal frame all move fast enough that an annual cycle guarantees staleness. The review is small: does the tool list still match reality, did any incident or near-miss expose a gap, did vendor terms or regulation change. Assign one named owner; policies without an owner do not get reviewed, they get rediscovered after an incident.
What makes a policy enforceable instead of decorative?: Every rule needs a mechanism, and the template forces that question per section: tool rules enforce through managed accounts, data rules through filters and local processing, task rules through the agent workflow, verification rules through a gate that runs per change, evidence rules through reports generated as a byproduct. The test: if every developer forgot the policy tomorrow, which rules would still hold? Those are your enforced rules - the rest is documentation of intent.

Keep reading

GovernanceThe EM Guide to AI Code QualityThroughput stays green while quality erodes - the four leading indicators from git and PR data, their warning signs and interventions, and the operating rhythm that steers without micromanaging.GovernanceJuniors + AI: The Seniors BottleneckAI raises the floor of production, not the ceiling of judgment - review load concentrates upward, and cutting junior hiring consumes future seniority. The mechanism, the data, the workflow that relieves.All articlesThe whole collection – 51 cited, dated guides on verifying AI-generated code.