AI Coding Policy Template

AI coding policy is a governance question before it is a tooling one. Four controls decide whether security can sign off: who has access, what the policy allows, how data moves, and whether anyone is measuring adoption. The table assigns each an owner.

The owners column matters more than the controls themselves, which I realise is a slightly odd thing to say about a governance table. But a control with nobody's name against it is a control nobody checks, and it fails at exactly the moment someone has to answer for it. The usual mistake is assuming security owns all four. They don't. Identity is IT's system of record, policy is an engineering-leadership call about what the team is allowed to ship, and adoption belongs to whoever owns developer experience. Security owns the data-flow question and the audit path, and they will ask about both.

Data flow is the one that stalls approvals, so answer it before the meeting rather than during it. Write down what the tool can read, what it can change, what leaves your network and where any of it is retained. Most of that comes straight from the vendor's documentation and your own configuration. It's dull work, but it turns a vague objection into a specific one, and specific objections are the kind you can actually close.

A rollout works when it starts narrow and earns its expansion. One team, one repo and a few real tasks in week one, with policy and training in place before anyone scales it wider.

1. 1Week 1: pick one team, one repo and three realistic tasks.
2. 2Week 2: write the workflow standard from the pilot.
3. 3Week 3: train champions and add policy guardrails.
4. 4Week 4: expand only after quality, cost and review load are visible.

Four weeks is a shape, not a rule. The dates matter much less than the order, and the reason to start with a single team is that those first two weeks are mostly you finding out what your standard should even say. You can't write that from a pilot too broad to watch properly. Pick the team that will tell you when something doesn't work, rather than the team most likely to hand you a good result.

Expansion is where this usually goes wrong. Not because anyone's careless, either — the pilot went well, someone senior noticed, and now there's pressure. That's a hard thing to say no to. Before you add teams, though, check that you can answer three things with numbers instead of impressions: did review load go up or down, what does a developer actually cost per month, did quality hold. If any of those is a shrug, another fortnight of the same pilot beats a rollout you have to walk back.

Cursor ships often, so here is the current state of the surfaces this page touches. Each row links to the source where you can confirm the detail.

Ask what happens when someone ignores it. Cursor splits agent safety into deterministic security controls that block an operation whatever the model suggests, and non-deterministic steering that makes good behaviour more likely. Any clause resting on the second kind is a request, and the template should say so in the clause itself.

Being pedantic about this is not about tidiness. A clause saying secrets must be excluded via .cursorignore reads, to anyone who doesn't know the mechanism, like a guarantee that secrets cannot reach a model. It is not one. For paths that genuinely must not be read, the answers are file system permissions, encryption, or a hook that blocks the read, and probably all three on anything you would have to disclose.

Right, so mark every clause with one of those two words before you circulate the draft. Cheapest edit this document takes.

The one promising a record of what the agent did. Cursor's audit logs record security events and administrative actions, and they do not log agent responses or generated code content. A clause saying AI-assisted changes are logged and reviewable cannot be satisfied from audit logs alone.

Cursor's own recommendation for that gap is hooks. A prompts-submitted hook can log when a prompt is sent and a code-generated hook can log when code is written, posting to your compliance endpoint, and Cursor advises logging metadata rather than full prompt or code content.

My first instinct was to write the logging clause and hand it to whoever owns the SIEM. Wrong order, I think. Whoever writes the hook decides what the clause can truthfully claim, so the sentence gets drafted after the hook exists rather than before it. Otherwise the policy makes a promise the pipeline has to be bent to keep.

Audit logs are an Enterprise-plan feature, viewable in the team dashboard and streamable to a SIEM, a webhook or S3. Confirm which plan you are on before that clause is written, because without them the escalation path has to be a named person rather than a query.

Model access, and personal API keys in particular. With your own key, zero data retention is subject to your agreement with the model provider rather than Cursor's. A policy that enforces Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. org-wide and says nothing about bring-your-own-key has a hole in the middle of it.

Two lines close it. Name which models the org allows and restrict the rest; state whether personal API keys are permitted at all. Non-ZDRZero Data Retention. A contractual guarantee that the model provider won't store your code or train on it. Press Enter for the full definition. models already require admin approval, so the approval step exists either way, and the policy's job is to say who grants it and on what basis.

A repository blocklist is the matching clause from the other direction. For the repos that should not be reachable from Cursor at all.