GOVERNANCE · FREE TEMPLATE · 2026

Vibe coding policy template: the one page your org actually needs

Your developers are already using AI coding assistants — the only question is whether the rules live in a document or in folklore. This template covers the eight sections that matter: sanctioned tools, data rules by classification, task rules for agent runs, verification duties, access tiers instead of a ban, the app register, and exceptions. Every rule carries its enforcement mechanism, because a rule that depends on memory becomes optional under deadline pressure. Free .docx, no email gate.

Download .docx for Word Copy-paste version FAQ

Why a policy now — and why a ban is the wrong policy

The adoption numbers already made the decision for you. By early 2026, 87% of Fortune 500 companies had adopted at least one vibe-coding tool (Dataiku), 92% of U.S. developers use AI coding tools daily, and a June 2026 scan found 380,000 vibe-coded apps exposing corporate data — including 2,000+ corporate apps sitting on the public internet with no authentication. The Cloud Security Alliance's June 2026 finding is blunter: none of the major AI security frameworks (NIST AI RMF, OWASP LLM Top 10, CSA MAESTRO) provide dedicated guidance for citizen developers, so the rules have to come from inside the org.

Meanwhile the open-source world already wrote its policies. LLVM requires a human in the loop with Assisted-by: labeling and bans unsupervised agents outright. Python's pip and requests policies make the human submitter the sole copyright owner of every line — "an LLM wrote it" is not an acceptable answer to review questions. Rust's RFC 3950 prohibits submitting AI-generated work you weren't in the loop on, didn't check with care, or can't explain to a reviewer. These are the same five ideas, and they all fit on one page.

What not to do: a flat ban. Superblocks' 2026 shadow-AI analysis and every rollout guide that followed reach the same conclusion — banning tools pushes usage onto personal devices, where none of your controls exist. The AQ team's staged-rollout plan puts it cleanly: write a one-page policy before the first seat, answer three questions plainly (where agents run, what credentials they hold, who reviews the work), and tier access instead of gatekeeping all of it. That is the structure below.

The eight sections, with the enforcement mechanism for each

Section	The rule	How it's enforced
1. Header & ownership	Named owner, version, review cadence	Calendar entry — an unowned policy is folklore
2. Sanctioned tools	Approved tools on company accounts only; consumer tiers prohibited for work	SSO / account tier at login, not goodwill
3. Data rules	Data reaches tools by classification; confidential code and PII stay local-only	The data class decides, not the developer under deadline
4. Task rules	Every agent run has a written task and boundary; least-privilege credentials	Scoped accounts, enumerated secrets, no production grants
5. Verification duties	You own every line that merges; another human reviews before merge	Branch protection + required reviewers on sensitive paths
6. Access tiers	Sandbox / internal / production tiers instead of one heavy gate	Training grants Tier 1; register + review grant Tiers 2-3
7. The register	Every AI-built app registered at creation: name, builder, data, owner, trail	Quarterly register review; unregistered app = incident
8. Exceptions	Written, expiring exceptions — never indefinite	Owner sign-off with an expiry date on file

The design principle behind the eight sections: every rule carries its enforcement mechanism — the pattern the best public templates share (realitygraph's ai-coding-policy, the LobsterOne governance standard, Copper Sun's review-gate policy).

The evidence behind each rule

Verification duties. CodeRabbit's 470-PR study found AI co-authored pull requests carry 1.7x more major issues and 2.74x more security vulnerabilities; Veracode's controlled testing found 45% of AI-generated code samples introduce a known OWASP Top 10 flaw. Review is not optional overhead — it is the control that makes the speed safe, and it belongs on every AI-assisted change, by a human who is not the author.

Data rules. OWASP ranks Sensitive Information Disclosure (LLM02) among the top risks for AI applications. Assume prompts leave your network unless you have configured a private endpoint, and let the data classification decide what may enter one — confidential code and personal data stay local-only (on-device models, air-gapped processing) or never enter a prompt at all.

Task rules. The ACM Technology Policy Council's April 2026 TechBrief on vibe coding flags agentic tools that "can execute code across systems" as a distinct risk class — unintended actions like exposing sensitive data, deleting critical files, or executing injected instructions. The mitigation is written boundaries: what the agent may change, which paths it may not touch, least-privilege credentials, and no production grants without an explicit written exception.

Ownership and labeling. Gartner forecasts prompt-to-app citizen development increasing software defects by 2,500% by 2028 without a governance layer. The LLVM/pip/requests/Rust policies converge on the fix: the human submitter is the author, fully accountable, and able to explain the work — with substantial tool-generated content labeled (Assisted-by:) so reviewers calibrate scrutiny.

The register. Gartner projects 40% of new enterprise production software will be built with vibe coding by 2028. At that share, "what AI-built apps do we have?" is a question you cannot answer from memory — the register (name, builder, data touched, owner, audit trail) is what turns an incident from archaeology into a five-minute lookup. Decisions, Island, and Fabrix all shipped governed vibe-coding products in one quarter (Jul-Sep 2026) and all three implement exactly this pattern.

Copy-paste policy text

The whole template in plain text — paste into your handbook, replace every [bracket], delete what does not apply:

# AI Coding Policy · [ORGANIZATION] · v1.0 · owner: [NAME] · review: quarterly

## 1. Tools & accounts
Sanctioned: [Claude Code, Cursor, Copilot, Codex CLI, VibeFuse] on company accounts only.
Consumer/free tiers are prohibited for work on company code. New tools: ask [OWNER].

## 2. Data rules
Public/internal code may reach sanctioned cloud tools. Confidential code, PII,
credentials, and regulated data stay local-only or never enter a prompt.
The data class decides — not the developer under deadline.

## 3. Task rules for agent runs
Every agent run has a written task: what it may change, which paths it may not
touch, and what done means. Least-privilege credentials only. No production
infrastructure or data without an explicit written grant. Killing a drifting
run is always allowed.

## 4. Verification duties
You own every line that merges. You must be able to explain the change to a
reviewer without re-prompting. Every AI-assisted change is reviewed by a human
who is not the author. High blast-radius paths require two reviewers.
Label substantial AI-generated content (commit trailer: Assisted-by: tool).

## 5. Access tiers
Tier 1 Sandbox: all staff after training — prototypes on sample data.
Tier 2 Internal: approved builders — staging-data tools, named owner, register entry.
Tier 3 Production: full review + security sign-off + register entry + audit trail.
(A flat ban pushes usage onto uncontrolled personal devices. Tier instead.)

## 6. The register
Every AI-built app that leaves a laptop is registered at creation: name,
builder, data touched, deployment target, named owner, review status, audit trail.
Unregistered app found in production = policy incident.

## 7. Exceptions
Written, expiring, owner-signed. Never indefinite. Disabling CI enforcement
checks is itself a violation.

## 8. Review cadence
This policy is reviewed quarterly (next: [DATE]) and after any incident.

Rolling it out in four phases

The AQ team's August 2026 staged-rollout guide is the best field-tested sequence, and it fits any org:

Phase 0 — guardrails before the first seat

One or two weeks of work, all of it cheaper before agents arrive: branch protection on main, required CI checks that cannot be skipped, secret scanning as a blocking check, code owners on sensitive paths — and the one-page policy from this template.

Phase 1 — pilot with volunteers

Two to six weeks with volunteers on real backlog work. Volunteers forgive friction; the pilot surfaces the norms you'll need to write down before expansion.

Phase 2 — expand with champions and norms

Expansion is where most rollouts quietly die: the people joining are not volunteers. Name a champion per team, run office hours, train on real workflows — scoping a ticket for an agent, isolated branches for parallel sessions, killing a run that goes sideways.

Phase 3 — default, measured on quality

Make agents the default and measure quality rather than volume — review throughput, incident rate, register completeness. The policy review cadence (quarterly) catches drift.

Keep reading

This template is the operational companion to the vibe coding governance guide (the five controls and the 2026 evidence) and the vibe coding security guide (the code-level half — run the 15-point checklist on anything headed to production). For the discipline layer around agents, see harness engineering; AGENTS.md template puts the per-repo rules where agents read them. Builders who extend the harness can publish governance widgets to the open marketplace.

Download the .docx Get the free harness

✓ Free forever VF- license
✓ Multi-agent canvas
✓ Local/offline processing
✓ Named reviewable sessions
✓ 80% creator payouts

Put the policy where the agents run Vibe coding guide

Explore VibeFuse & harness guides

Vibe coding policy template FAQ

What should a vibe coding policy cover?

Eight sections: sanctioned tools (company accounts only, consumer tiers prohibited for work), data rules by classification (confidential code and PII stay local-only or never enter a prompt), task rules for agent runs (written task, boundaries, least-privilege credentials), verification duties (you own every line that merges, and another human reviews before merge), access tiers instead of a ban, the app register (name, builder, data touched, owner, audit trail), written expiring exceptions, and a named owner with a quarterly review cadence. Every rule should carry its enforcement mechanism - a rule that depends on memory becomes optional under deadline pressure.

Should we ban AI coding assistants at work?

No - a flat ban pushes usage onto personal devices, where none of your controls exist. The 2026 shadow-AI analyses and staged-rollout guides converge on tiering instead: a sandbox tier for everyone after training (prototypes on sample data), an internal tier for approved builders (staging data, named owner, register entry), and a production tier with full review, security sign-off, and an audit trail. 87% of Fortune 500 companies had adopted at least one vibe-coding tool by early 2026 - the usage is already happening, so the question is whether it happens inside or outside your controls.

Is there a free AI coding policy template?

Yes - the .docx on this page is free with no email gate. It contains the full one-page policy (header and ownership table, sanctioned tools, the data-classification table, agent task rules, verification checklist, the three access tiers, the register fields, and exceptions), opens in Word 2016+, Word on the web, and Google Docs, and the page also provides a copy-paste plain-text version. The structure mirrors the public policies already tested in the open: LLVM's human-in-the-loop rules, pip and requests' ownership requirements, and Rust RFC 3950's five prohibitions.

What is the human-in-the-loop rule for AI-generated code?

The human who runs the agent is the author and owns every line that merges. LLVM's policy requires contributors to read and review all LLM-generated code before requesting maintainer review, to answer questions about it, and to label substantial tool-generated content (an Assisted-by: commit trailer). pip and requests go further: the submitter unequivocally owns the copyright - an LLM product cannot be a co-author, and "an LLM wrote it" is not an acceptable answer to review questions. Rust RFC 3950 prohibits submitting AI-generated work you were not in the loop on, did not check with care, or cannot explain to a reviewer. In practice: you must be able to explain the change without re-prompting.

How do we handle data security in AI coding prompts?

Assume prompts leave your network unless you have configured a private endpoint. Classify data and let the class decide, not the developer under deadline: public and internal code may reach sanctioned enterprise accounts (with prompt/suggestion retention disabled and public-code filters enabled), while confidential code, PII, credentials, and regulated data stay local-only or never enter a prompt. OWASP ranks Sensitive Information Disclosure (LLM02) among the top risks for AI applications, and 380,000 vibe-coded apps were found exposing corporate data in a June 2026 scan - the data rule is the control that prevents your app from joining that count.

What are AI coding access tiers?

Three tiers replace one heavy gate everyone routes around: Tier 1 Sandbox - all staff after a training module, prototypes and demos on sample/staging data, auto-approved, nothing deploys; Tier 2 Internal - approved builders, internal tools on staging data, register entry plus peer review before sharing beyond the team; Tier 3 Production - full review, security sign-off, register entry, and an audit trail. Gates scale with blast radius, which is also the pattern the three governed vibe-coding products shipped in a single quarter (Decisions, Island, Fabrix) all implement.

What is an AI app register?

A register records every AI-built app that leaves someone's laptop: name, builder, date registered, data touched (by classification), deployment target, named owner, review status, and an audit-trail pointer. It is reviewed quarterly, and an unregistered app discovered in production is a policy incident regardless of code quality. The reason it cannot be optional: Gartner projects 40% of new enterprise production software will be built with vibe coding by 2028 - at that share, the question "what AI-built apps do we have?" is unanswerable from memory, and generated-in-a-session lineage is exactly what vibe coding destroys.

How do we roll out an AI coding policy?

Four phases, per the field-tested staged-rollout sequence: Phase 0 - guardrails before the first seat (branch protection on main, required CI checks that cannot be skipped, secret scanning as a blocking check, code owners on sensitive paths, and the one-page policy); Phase 1 - a two-to-six-week pilot with volunteers on real backlog work; Phase 2 - expansion with named champions per team, office hours, and written norms, because the people joining are not volunteers; Phase 3 - make agents the default and measure quality rather than volume. Review the policy quarterly and after any incident.