Guide · 2 min read

A policy starter kit for AI coding tools

You do not need a long policy document to start governing AI coding tools. Three small, testable rules cover most first conversations with a security team. This guide describes each, gives an illustrative configuration, and suggests how to roll them out without disrupting engineers.

1. Human review on sensitive paths

Some code carries more risk than the rest: payments, authentication, cryptography, infrastructure. The first rule says that when AI assistance is recorded on a change touching those paths, a human must review it before merge.

Note the wording: recorded. The rule applies to changes where AI use is Attested or Declared. It does not guess about changes with no record, which is why the disclosure rule below matters.

2. AI disclosure label

The second rule asks for one label or trailer on every pull request that used an AI tool, and optionally a statement that none was used. It turns silence into a signal: a change with no declaration is a gap you can see.

3. Tool and model allowlist

The third rule lists the tools and models your organisation has approved. A change that reports a tool outside the list is flagged. This turns an approval decision into something you can check against real activity.

An illustrative configuration

The snippet below shows the three rules together. The format is illustrative and the interface may change. What matters is that each rule is simple enough to explain to an engineer in a sentence.

policies.yamlIllustrative — interface subject to change

# Illustrative — interface subject to change
mode: warn   # start here, move to enforce later

policies:
  - id: human-review-sensitive-paths
    when:
      ai_assisted: true          # Attested or Declared only
      paths: ["payments/**", "auth/**", "infra/**"]
    require:
      review: human

  - id: ai-disclosure-label
    when:
      any_change: true
    require:
      declaration: ["ai-assisted", "no-ai"]

  - id: tool-allowlist
    when:
      ai_assisted: true
    require:
      tools_in: ["Code assistant", "Agent runner"]

Run in warn mode first

A new rule almost always flags something you did not expect: a path pattern that is too broad, a legitimate tool nobody added to the list, a team with a different labelling habit. Enforcing on day one turns those surprises into blocked merges and lost goodwill.

Start in warn mode. Replay the rule against recent history to see what it would have flagged, adjust the patterns and the list, and only then move to enforce. Review the warnings with the teams affected, since they will know which flags are noise.

Week 1: simulate against past changes and tune paths and lists.
Weeks 2 to 3: warn mode on live changes, review the flags with the teams.
After that: enforce the rules where the flags are understood.

What these rules do not do

They do not detect AI-written code that nobody disclosed, and they do not replace a security scanner or a code review. They make your stated expectations checkable, and they leave a record of how each change was handled.