The AI coding policy template

What the playbook covers

From “are we compliant?” to an answer the pipeline prints. Acme Inc is a made up company. Its checkout squad lets agents open pull requests, and the CTO cannot say whether that is within policy. Seven steps take the save-cards pull request from unknown to checked.

Why a ban or a document does not answer the question. The two obvious answers fail in opposite directions. A ban leaves agent use on personal accounts nobody sees, and a document governs only the people who already follow it. The save-cards pull request would pass both. This chapter shows where each answer breaks for the checkout squad, and why Acme writes its policy as files in the repository that the pipeline checks on every change.

List what agents touch today, before you write a rule. Step 1 on the map. Nobody knows which account opened the save-cards pull request, on which plan, or what it read. The baseline answers that first.

Tier the repos and data by what an agent may do with them. Step 2 on the map. The save-cards agent can read customer exports as easily as payment code. Tiers say what it may read, send out or never touch. Each path in acme-checkout gets one tier in AI-POLICY.md, and the next step turns those tiers into settings.

Put the tiers in settings the tools enforce. Step 3 on the map. The tier table says agents never read .env, but the save-cards agent still can. Settings turn each tier into rules, a sandbox and a network allowlist that no engineer can switch off.

Name who signs off an agent-authored change. Step 4 on the map. The save-cards pull request has an agent author and an approval, but no one who certifies it. Sign-off names its human owner, the disclosure and who approves sensitive paths.

Check compliance in the pipeline instead of assuming it. Step 5 on the map. The save-cards pull request is governed on paper. The pipeline checks settings, secrets, owners and agent counts on every change.

Write the path for exceptions and incidents. Step 6 on the map. The save-cards migration needs the agent to see what customer records look like, and the same week a test key is pushed. Exceptions and incidents get a written path, so nobody improvises one.

Name the owner and the review cadence. Step 7 on the map. The files work only while someone keeps them current. One named owner per file, an hour each quarter, the baseline rerun to show what changed since the save-cards pull request, and the whole policy to fill in.

The page to keep. Every file and setting the policy leaves in acme-checkout, what each holds and who keeps it. Bring it to the quarterly hour, walk the rows with each owner, and mark anything that changed since the last rerun. CODEOWNERS makes each owner approve every change to their file.

Find out where your team is today. The save-cards pull request merged with an owner, a disclosure and a passing policy job, and the quarterly hour keeps the files current. The policy is the boundary layer of an AI-ready team. The assessment scores the rest, from delivery to how the team works with agents, and shows what to fix next. Most teams that finish a policy find the next gap somewhere else, in how work is planned, reviewed and measured. The assessment takes two minutes and asks how your team ships today, so the answer starts from your own pipeline. Bring the result to your next planning meeting with the policy beside it, and pick one layer to improve this quarter.