Your engineers are already using AI coding assistants. The only decision left is whether you have a policy, and whether that policy is one they will follow or one they will route around.
Most published AI coding policies fail for the same reason: they are written as prohibitions nobody can verify. "Do not paste proprietary code into external tools" is unenforceable on a laptop with an IDE extension. A policy that cannot be checked is not a control — it is a document you will show an auditor and quietly know is fiction.
Here is a shorter policy that holds up, built around the observation that the risk is not that AI writes bad code. It is that AI writes plausible code, quickly, in volume, and review capacity does not scale with it.
Not "AI hallucinates." The recurring, boring failure modes:
Security defaults get skipped, not broken. An assistant asked for "an API route that returns a user's orders" produces a working route. It does not produce an authorisation check, because you did not ask for one and the code works without it. Nothing is wrong in the generated code — something is absent, and absence does not look like a bug in review.
Configuration gets copied out of tutorials. Permissive CORS, a Supabase table without row-level security, NEXT_PUBLIC_ on something that should never reach a browser, a header set to a value that appears in a blog post. These come from the training distribution, where tutorial code massively outnumbers production code.
Volume outruns review. A generated 400-line diff gets the same fifteen minutes of attention a hand-written 40-line diff would. This is the real multiplier and no amount of prompt discipline fixes it.
Dependencies arrive without a decision. An assistant reaches for a package. It gets installed. Nobody evaluated it, and sometimes nobody checked it exists — a suggested-but-nonexistent package name is an opening for someone to register it.
Short enough to read, and every rule has a mechanical check behind it. That second property is what separates this from a document.
State the permission explicitly. A policy that starts by restricting tools everyone already uses gets ignored in full, including the parts that matter.
Check: branch protection requiring review. Already in place for most teams.
Assistants inline example credentials and sometimes real ones from context. This is the single highest-value rule because a secret in git history costs rotation plus history rewriting, not deletion.
Check: secret scanning that blocks the merge. Not a comment — a block. See security review in pull requests.
The most common real gap. Make it a named requirement so it survives a busy week: any PR adding an endpoint or a new query path needs someone to explicitly say "I checked the authorisation."
Check: a required checklist item or a path-based CODEOWNERS rule on your routes and data-access directories.
One sentence: why this package, and what it replaces. Not a committee — just enough friction that nobody installs something an assistant mentioned without reading its name.
Check: a lockfile diff in CI that fails when dependencies changed and the PR body has no dependency note.
The rule engineers will push back on, and the one that catches the most. A large generated diff is not reviewable at normal attention; either split it into reviewable commits or review it live with the author.
Check: a CI warning on diff size. Advisory, not blocking — this needs judgement.
Static review cannot see what only exists at runtime: the headers the server actually sends, whether that Supabase table is readable with the anon key, whether a key reached the shipped JavaScript bundle. Assistants generate configuration as readily as code, and configuration mistakes are runtime-visible only.
Check: a scheduled scan of the deployed app, with findings landing in a queue with an owner and a deadline.
Equally important, because every unenforceable rule discounts the ones next to it.
"Do not paste proprietary code into AI tools." Unenforceable with IDE extensions and unverifiable on a personal machine. If the concern is real, address it at the tool-selection layer: choose assistants with a business tier that contractually excludes training on your input, and configure them centrally. That is a procurement control, not an engineering rule.
"Disclose AI-generated code in commit messages." Nobody complies consistently, the boundary is meaningless once autocomplete is involved, and the disclosure changes nothing about how the code is reviewed. If generated code needs different review, encode that in the review rule, not in a label.
"Only use approved models." Approve the tool, not the model. Model versions change weekly and any list is stale on arrival.
"AI may not write security-relevant code." Everything touching a request is security-relevant. This rule reads as caution and functions as a prohibition on the work, so it gets ignored, and its neighbours lose credibility with it.
Before the engineering policy, three procurement questions that actually change your exposure:
One number: new findings per merged pull request, tracked monthly.
If assistant adoption rises and this holds flat, review is keeping up. If it climbs, review capacity is the bottleneck and rules 3 and 5 need tightening. It is a leading indicator, it does not require anyone to self-report, and it survives a change of tools.
Pair it with median time to remediate, so you can see whether the queue is absorbing the new volume or just accumulating it.
Concretely, for the checks above:
Team plans are $25 per seat per month, five-seat minimum, with Jira/Linear sync and compliance reporting on Team Advanced at $50. The pricing page has the detail, and auditing Cursor and Copilot output goes deeper on the code-level checks.
No, and a ban is the least enforceable option available — engineers will use them on personal machines where you have no visibility at all. Permit them explicitly and put the controls where they are checkable: secret scanning that blocks merges, an authorisation reviewer on new routes and data access, a size limit on generated diffs, and scheduled scanning of the deployed application.
Omission rather than error. Asked for an endpoint, an assistant produces one that works, and working code does not require an authorisation check — so the check is simply absent. Absence is much harder to spot in review than a bug, because there is no wrong line to point at. Second is volume: generated diffs are larger and get the same review attention as hand-written ones.
No control in the Trust Services Criteria names AI tools. What auditors ask is whether code changes are reviewed and approved before production, which your existing change-management control already covers. A short AI policy is still worth having for enterprise security questionnaires, where the question is now common, and it is easier to answer with a one-page document than with a paragraph written under deadline.
You do not, meaningfully — not in one pass. Either split it into commits that each do one thing, or review it live with the author, who can explain the intent that the diff does not carry. A CI warning on diff size makes the choice visible before review starts. Treating a large generated diff as reviewable at normal attention is how omitted authorisation checks reach production.
The question is contractual, not technical: every major assistant offers a business or enterprise tier that excludes your input from training, and the free tiers generally do not. Get the paid tier, get the exclusion in writing, ask for the retention period and region, and add the vendor to your subprocessor list. Then enforce the configuration centrally, because per-laptop settings are not a control.
Partly. It catches injection patterns, hardcoded secrets and unsafe API usage in the code itself. It cannot see the configuration mistakes assistants produce just as readily — permissive CORS as the server actually answers, a database table readable with the public key, a secret that reached the browser bundle, a missing security header. Those are only visible against the running deployment, which is why scheduled runtime scanning belongs in the policy alongside code review.
CheckVibe scans the deployed app and the repository, comments on pull requests, and puts what it finds in a shared queue with an owner and a deadline. See what teams get, or run a free scan.
Paste your URL and get a security report in 30 seconds — 100+ automated checks with AI-ready fix prompts.
Related articles
How to put security checks inside code review without teaching your team to ignore the bot: what to block on, what to comment on, what to leave out.
The questions enterprise buyers actually send small vendors, how to answer honestly when the answer is no, and what to prepare before the first one.
How a small team turns a scanner's output into owned, deadlined work: who triages, what gets closed on sight, and the queue design that stops backlogs.