AI coding assistant governance without a 40-page policy

Start by naming the actual risks

Most AI coding assistant governance documents open with principles. Skip that. Write down what you are afraid of, in specific terms, because the controls follow from the list and the principles do not.

The realistic set for an engineering org: source code leaving your boundary and being retained, a licence-incompatible chunk of code landing in a product you ship, credentials pasted into a prompt, an agent running a destructive command against something real, and volume of merged code outrunning your ability to review it. Five things. Notice that only two of them are about the model.

The four controls that matter

• Buy the tier where your code is not retained or trained on, then verify it in the admin console rather than in the sales deck. Turn off any personal-account usage on work machines, which is where most leakage happens.
• Secrets never reach the agent. Enforce this with tooling, not a rule. A pre-commit secret scanner and a .gitignore that covers .env files beats an all-hands reminder.
• Blast radius. Agents run in a sandbox or a worktree, without production credentials in the environment. Nobody should be able to point an agent at a shell that can reach your primary database.
• A human owns every merge. Whoever clicks merge is accountable for the code regardless of who or what wrote it. Say this out loud, once, and put it in the contributing guide.

What to drop

Percentage targets for AI-written code, in either direction. Mandatory disclosure labels on pull requests, which turn into a checkbox everyone ticks. Approval workflows for using an assistant on a specific ticket. A central committee reviewing tool requests.

These feel like governance and produce nothing measurable. Worse, they push people to use personal accounts to avoid the friction, which is the exact outcome the policy existed to prevent. We have watched that happen at two companies, both times within a quarter of the policy landing.

Make it visible instead of restrictive

The useful thing a policy can add is a signal you can query later. Have people put an agent trailer on commits made with substantial assistance:

Co-Authored-By: Claude <[email protected]>

Then, when an incident happens, you can ask whether assisted commits are overrepresented in the postmortems. Usually they are not, and having the data ends an argument that would otherwise run for months. If they are, you have a real finding and a place to aim training.

Honest limit: this trailer is voluntary and imperfect, so treat it as a weak signal rather than an audit trail. It is still better than the guessing you are doing now.

What to do next

Write your five risks on one page. Check the retention setting in your vendor admin console today, because that is the one people assume is handled. Put a secret scanner in pre-commit. Then write a contributing guide paragraph saying the merger owns the code. That is a morning's work and it covers more real risk than the policy document you were about to commission.

If you want help putting this into practice, talk to us.