Governance for AI-generated code that engineers accept

Start with the one rule that holds

Governance for AI-generated code gets simpler once you accept a single principle: the person who opens the pull request owns the code, whatever produced it. No separate category, no lighter review, no excuse in the incident review that the model wrote it.

Most of the elaborate policy documents we read are attempts to avoid stating that plainly. They invent tiers, approval matrices, and disclosure taxonomies. Then an engineer ships a fix at 6pm and none of it applies. One clear line of accountability beats four pages of process.

Write down four things, not forty

• Scope. Which repositories and which data may go near a coding agent. Name them. "Use good judgement" is not a scope.
• Secrets. That credentials, customer data, and production dumps never enter a prompt, enforced by a pre-commit scanner rather than by hope.
• Licensing. Your position on generated code that closely reproduces a known open source implementation, and who to ask when someone is unsure.
• Review. That every change gets human review before merge, with no exception carved out for small or generated diffs.

Four items fit on a wiki page people actually read. We have watched a 22-page policy get approved by legal and ignored by every engineer in the building within a month.

Automate the parts humans forget

Policy that depends on memory fails. Policy compiled into the pipeline holds.

Practical controls, roughly in order of payoff: a secret scanner in pre-commit and in CI, so a leaked key is caught at the earliest point; branch protection requiring a review from someone other than the author; a dependency check that fails the build on a new package added by an agent without a human noting why; and a size threshold that flags very large diffs for extra attention rather than blocking them.

That dependency check matters more than it sounds. The most common surprise in agent-assisted work is not bad logic, it is a new transitive dependency pulled in to solve something your standard library already handles. A CI step that prints the diff of your lockfile in the pull request description costs an afternoon to build and catches this every time.

Controls that get ignored

Mandatory tagging of generated code in commit messages decays within weeks. People forget, then people stop caring, and then your data is worse than useless because it is partial. If you want the signal for a first quarter of measurement, say so and set an expiry date.

Blanket bans also fail, in a specific and expensive way. Engineers use personal accounts on personal laptops and the organisation loses all visibility. A narrow, well-explained boundary gets respected. A wide one gets evaded.

Approval boards for individual changes are the third. Nobody has the throughput, so the board rubber-stamps, and now you have latency plus false assurance.

What to do next

Write your four items on one page this week and circulate it to the engineers before legal. If any of them can describe a normal Tuesday workflow that the page forbids, the page is wrong and you have found out cheaply. Then pick one control, the secret scanner, and ship it before you write anything else.

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