A workable AI usage policy for engineering covers nine things: scope, approved tools and models, data classification rules, secrets handling, review requirements for agent-written code, agent execution boundaries, spend rules, an exceptions process, and a review cadence. The template below is written for teams running coding agents rather than for a generic office. The section after it maps each clause to the setting, API, or gateway rule that makes it real, because a policy nobody can enforce mostly generates plausible deniability.
- Name specific tools and models. A policy that says "approved AI tools" with no list is unenforceable and everybody knows it.
- The data clause should be a short never list, not a taxonomy. People remember five items.
- Agent-written code gets the same review as human-written code. No special track, no exemption, no extra ceremony either.
- Every clause needs an enforcement point: a managed settings key, a seat, a gateway rule, or a named human.
- Ship the exceptions process on day one. Without one, the policy is routed around instead of amended.
What a policy can and cannot do
A policy sets the default and gives people a defensible answer when they are unsure. It does not stop anything. The stopping is done by managed settings, identity providers, gateways, and seat allocation, and the value of writing the policy first is that it tells you which of those you actually need.
The other failure mode is length. A twelve-page policy with a data classification matrix is read once, by the person who approved it. Engineers will read one page. Optimize for the version that gets read.
The nine clauses, and why each one is there
| Clause | The failure it prevents |
|---|---|
| Scope | Arguments about whether the policy covers a personal laptop |
| Approved tools and models | A team standardizing on a tool nobody vetted |
| Data rules | Customer data pasted into a consumer chat account |
| Secrets handling | A live key in a prompt, then in three vendors' logs |
| Review of agent-written code | A 2,000-line pull request nobody actually read |
| Agent execution boundaries | An agent with a production credential doing exactly what it was asked |
| Spend rules | A metered key attached to a loop |
| Exceptions | The policy being routed around rather than amended |
| Review cadence | A policy naming models that were retired a year ago |
Two of those deserve expanding, because they are the ones teams get wrong in opposite directions.
Review of agent-written code
The instinct is to require extra scrutiny for AI-generated code. That is the wrong shape. It creates a two-track review process, invites disclosure theatre, and quietly signals that normal review is not thorough. The clause that works is simpler: the author is accountable for every line they submit regardless of who or what typed it, and reviewers review the diff on its merits. The real change is upstream, in the size of the diffs an agent produces, which is a working-agreement problem rather than a policy one.
Agent execution boundaries
This is the clause with no precedent, and it is the one worth spending your specificity budget on. A coding agent that can run shell commands, with a database credential in its environment, is not a code completion tool. Name the environments an agent may touch, name the credentials it may hold, and be explicit that a permission-skipping mode is a decision with a blast radius rather than a convenience toggle.
The template
Copy it, delete what does not apply, fill in the bracketed parts, and keep it to one page. It is written for an engineering organization running coding agents, not for a whole company.
# AI usage policy: engineering
Owner: [Head of Engineering] · Last reviewed: [YYYY-MM-DD] · Next review: [+90 days]
## 1. Scope
Applies to everyone writing or reviewing code for [Company], on any device,
including contractors. Covers AI coding assistants, agents, and chat
assistants used for work. Personal use on personal accounts is out of scope
until company code or company data is involved, at which point it is in scope.
## 2. Approved tools and models
Approved for all engineering work:
- [Claude Code] on the company account
- [GitHub Copilot] on the company organization
Approved with restrictions:
- [Tool], for [purpose] only, no customer data
Not approved: anything else, including personal subscriptions used for
company work. To add a tool, use section 8.
Default model is [model]. Higher tiers are available and require no approval;
pick the cheapest model that does the job.
## 3. Data rules: what never goes in a prompt
Never, on any tool, approved or not:
1. Live credentials, API keys, tokens, private keys, or passwords
2. Customer personal data, including support tickets containing it
3. [Regulated data class, e.g. cardholder data, PHI]
4. Unreleased financial results or material non-public information
5. Third-party code or data you are contractually barred from disclosing
Everything else about our own codebase is permitted on approved tools.
If you are unsure, ask in [#eng-ai] before pasting, not after.
## 4. Secrets
Secrets are supplied to agents through [the environment manager], never
pasted into a prompt and never committed. If a secret reaches a prompt,
treat it as disclosed: rotate it immediately and tell [#security] the same
day. There is no penalty for reporting this. There is one for not reporting it.
## 5. Code written by an agent
The person who opens the pull request is accountable for every line in it.
Normal review applies: no extra approvals, no special disclosure, no
exemptions. You must be able to explain any line a reviewer asks about.
Keep agent-authored diffs small enough to review honestly.
## 6. What an agent may execute
Agents may run commands in: local checkouts, worktrees, and [CI sandbox].
Agents may never hold credentials for: production databases, production
cloud accounts, [payment provider], or customer-facing systems.
Permission-skipping modes are permitted only in an isolated sandbox with no
production credential present.
MCP servers are limited to the org-approved list. Adding one for the team
goes through section 8.
## 7. Spend
AI spend is a real budget line. Your [plan tier] is provisioned for you; ask
rather than paying personally and expensing it. Automation and CI use a
separate API key with its own budget, requested from [platform team].
If you see spend behaving strangely, say so early; nobody is in trouble for
an expensive week, and everybody is for a silent expensive month.
## 8. Exceptions
Request in [#eng-ai] with: the tool, the reason, the data it will touch, and
how long you need it. [Head of Engineering] approves, or [Security] for
anything touching section 3. Decisions and their reasoning are recorded in
[the decision log]. An approved exception is time-boxed and gets revisited
at the next review.
## 9. Review
This document is reviewed every 90 days by [owner]. Model names, tool names,
and prices go stale faster than anything else in it. A review that changes
nothing is still recorded as a review.Making each clause real
The half most templates omit. For each clause, the control that makes it true rather than aspirational.
| Clause | Enforcement point | Honest gap |
|---|---|---|
| 2. Approved tools | Device management, plus forceLoginOrgUUID to pin logins to your org | Unmanaged personal devices |
| 2. Approved models | availableModels with enforceAvailableModels: true | Anyone using their own API key |
| 3. Data rules | Provider data-retention settings; deny rules on sensitive paths | Copy and paste into a browser |
| 4. Secrets | Host keychain, per-repo scoping, Read(./.env*) in the deny list | A secret typed by hand |
| 5. Code review | Branch protection and required reviewers | None, this one genuinely works |
| 6. Execution | permissions.deny plus allowManagedPermissionRulesOnly | Sessions on unmanaged machines |
| 6. MCP servers | allowedMcpServers and allowManagedMcpServersOnly | Sideloading, unless disableSideloadFlags is set |
| 7. Spend | A hard cap requires something in the request path | BYOK cannot be capped, only observed |
Rolling it out without generating shadow AI
- Provision before you publish. The policy lands the same week people get accounts on the approved tools, not six weeks earlier.
- Publish the exceptions channel with the policy. If the first person with an edge case cannot find the process in thirty seconds, they will improvise.
- Announce the enforcement, do not surprise people with it. Say which settings are now managed and what they change. Silent enforcement reads as distrust and generates workarounds.
- Give the never-list a five-item ceiling. If you have six, the sixth is not important enough to displace the memorability of the other five.
- Review in 90 days with the model names in front of you. Half the specifics in any AI policy are stale within two quarters.
Questions people ask
What should an AI usage policy include?
Nine things: scope (who and which devices), approved tools and models by name, a short list of data that may never enter a prompt, secrets handling, review requirements for agent-written code, boundaries on what an agent may execute and which credentials it may hold, spend rules, an exceptions process, and a review cadence. Keep it to one page; a longer document is read once by the person who approved it.
Should AI-generated code get extra review?
No. Requiring a special review track for AI-generated code creates disclosure theatre and implies normal review is insufficient. The clause that works is that the person opening the pull request is accountable for every line regardless of who typed it, and that they can explain any line a reviewer asks about. The real lever is keeping agent-authored diffs small enough to review honestly.
Can we stop employees using personal AI accounts for work?
Not with a policy alone. You can pin logins to your organization on managed devices, restrict which models are selectable, and block sideloaded configuration, but none of that reaches a personal laptop with a personal subscription. The reliable control is making the sanctioned path faster to obtain than the unsanctioned one. Slow provisioning produces shadow AI more reliably than any policy prevents it.
What data should never be put into an AI prompt?
Live credentials and keys, customer personal data, whatever regulated class applies to you such as cardholder data or health information, material non-public financial information, and third-party code or data you are contractually barred from disclosing. Keep the list to about five items so people can actually remember it, and be explicit that your own source code on approved tools is fine, otherwise engineers will over-apply the rule and stop using the tool.
How often should an AI usage policy be reviewed?
Every 90 days. Model names, tool names, plan tiers and prices are the parts that go stale, and all of them change on a scale of months. Record the review even when nothing changes, because the date on the document is what tells a reader whether the model list can be trusted.
Sources
Every figure above was read from these pages on August 2026. Vendors reprice without notice; if you find a stale number, tell us.