The AI Coding Policy Template
Last updated: 2026-07-024 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
Each section carries a rule and the mechanism that enforces it - from written intent with boundaries before an agent run to advisory-by-default agents with no auto-commit. The test that decides whether a section stays: name how it is enforced, or cut it.
| The rule | Its enforcement mechanism | |
|---|---|---|
| 1 · Tools & accounts | Only sanctioned tools on company accounts; consumer and free tiers are prohibited for work.Editorial reading · 2026-07 | Managed accounts and SSO - the account tier is enforced at login, not by goodwill.Editorial reading · 2026-07 |
| 2 · Data rules | Data reaches tools by classification; confidential code and personal data stay local-only.Editorial reading · 2026-07 | Filters and local processing - the data class decides, not the developer under deadline.Editorial reading · 2026-07 |
| 3 · Task rules | Every agent run has a written goal, boundaries and acceptance criteria before it starts.Editorial reading · 2026-07 | The agent workflow gives a run nothing to check against until the task is written down.Editorial reading · 2026-07 |
| 4 · Verification | Build, types and change-relevant tests pass per change, not authored by the generating model.Editorial reading · 2026-07 | A verification gate that runs per change enforces itself, unlike a rule that asks for vigilance.Editorial reading · 2026-07 |
| 5 · Evidence | A run record - task, tool, diff scope, validations, approver - is stored with the code.Editorial reading · 2026-07 | The report is a byproduct of the run, not a document someone writes up afterwards.Editorial reading · 2026-07 |
| 6 · Agent permissions | Agents are advisory by default: no auto-commit, no protected-branch writes, no production access.Editorial reading · 2026-07 | The limits are set in the tool's permissions, so they hold without anyone remembering them.Editorial reading · 2026-07 |
| 7 · Exceptions | Exceptions are requested with a reason and an expiry date, and logged in a register.Editorial reading · 2026-07 | Expired exceptions auto-revert to policy; the register doubles as the audit trail.Editorial reading · 2026-07 |
| 8 · Ownership & review | One named owner; a quarterly review of the tool list, incidents and vendor terms.Editorial reading · 2026-07 | A calendared review with a named owner - unowned policies are simply never reviewed.Editorial reading · 2026-07 |
Who owns which section
A policy binds only when each section has a named owner. This is the accountability the document assumes - four roles carrying the eight sections between them; map it to your own titles.
| Policy owner | Developers | Change approver | Data-protection contact | |
|---|---|---|---|---|
| OwnsWhich policy sections this role keeps current | The whole document - the tool list (§1), the exception register (§7) and the review cadence.Editorial reading · 2026-07 | Sections 3 and 4 in daily practice - a written task before each agent run and the checks that follow.Editorial reading · 2026-07 | Section 6 at the gate - advisory-by-default agents, no auto-commit, a human accept or reject.Editorial reading · 2026-07 | Section 2 - the data classes, what may reach which tool, and the personal-data rules.Editorial reading · 2026-07 |
| DecidesThe call this role is the one to make | What is sanctioned, who gets an exception, and when the quarterly review happens.Editorial reading · 2026-07 | Whether a change is ready to propose for review - never whether it merges itself.Editorial reading · 2026-07 | Whether a verified change merges, with the evidence report in front of them.Editorial reading · 2026-07 | Which classification a data class gets and where local-only processing is mandatory.Editorial reading · 2026-07 |
| Accountable when it failsWhat lands on this role when a rule slips | A stale tool list, or a policy no one reviewed until after an incident.Editorial reading · 2026-07 | Running an agent with no written task, or skipping the per-change verification.Editorial reading · 2026-07 | Merging on trust without checking the change against its task and boundaries.Editorial reading · 2026-07 | Confidential code or personal data reaching a cloud prompt or context window.Editorial reading · 2026-07 |
| Absent, and it shows up asThe failure mode when the role is left unassigned | The policy is rediscovered after an incident instead of maintained before one.Editorial reading · 2026-07 | Rules live as folklore; intent stays in prompts and evaporates after the run.Editorial reading · 2026-07 | Acceptance happens by feel; the gate is informal and nothing is auditable.Editorial reading · 2026-07 | The section clients and auditors read first becomes guesswork under pressure.Editorial reading · 2026-07 |
The template
ai-coding-policy.mdtext/markdown
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. For the approval clause, that mechanism is the gate a green run still cannot walk through.
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
- A named owner and a review cadence per section
It does not give you
- A universal or one-size policy - it is a starting template you adapt, not a standard you can claim to meet
- 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
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
GovernanceAI Coding GovernanceThe controls, workflows, approvals, and evidence a team needs to adopt AI coding tools without losing engineering accountability - and where each building block has limits.GovernanceNo Auto-CommitInstructions are probabilistic, permissions are deterministic - the 2025 Replit incident proved the difference. The agent permission ladder, where auto-apply is fine, and how to enforce the gate.All articlesThe whole collection - 58 cited, dated guides on verifying AI-generated code.