Policy engineers will actually follow

In one minute AI-written code does not need a new rulebook. It needs the change-management questions you already answer for auditors, answered with evidence on every change. Only 48% of developers say they always check AI-written code before they commit it,¹ so the check has to live in the pipeline, where it runs whether anyone remembers or not.

The questions have not changed

Every change-management process asks the same five things: who or what made this change, who reviewed it, what it touched, which tests ran, and whether it touched anything sensitive.

Those questions are older than coding agents, and the frameworks your auditors use already ask them. None of SOC 2, ISO/IEC 27001, SOX or PCI DSS has a special section for code an agent wrote, and you do not need to write one. What has moved is volume and authorship. Your team ships more changes than it did, and a tool typed part of many of them. An agent can author a change. It cannot approve one.

So keep the questions you already have, and make sure each one has an answer you can show for every change, without asking the person who merged it.

How the controls map

The table maps the change-management controls regulated teams meet most often. Read each row as a question an auditor will ask about a sample of your changes.

A Change Record answers who and what, and it carries an approval wherever your git history holds one. Your code host's review records and your CI logs supply the rest. Together they cover the evidence column for every row. If your product could fall under rules aimed at AI systems, check with your counsel what applies to you.

Two engineering frameworks sit beside these controls. NIST's Secure Software Development Framework (SSDF) sets out a core set of secure development practices that US federal software suppliers attest to.⁶ SLSA covers build provenance, meaning tamper-resistant evidence of how a piece of software was built, and in-toto, a graduated Cloud Native Computing Foundation project, gives a common format for statements about each step.⁷ A Change Record exported as an in-toto statement sits next to that build evidence.

Rules that hold up

Most companies already have a secure development policy. It lives in a wiki, someone signed it off two years ago, and few people on the team could quote a line from it. A reviewer who has never opened it cannot apply it to a 600-line agent pull request at 5pm.

Rules that hold up have four things in common:

1. They are written as code, in the repository, next to what they govern. A change to a rule gets reviewed like any other change.
2. They run on every change, in CI or as a pre-commit hook, with no one needing to remember.
3. They explain themselves in the pull request. A failing check names the rule, the file that tripped it and what to do next.
4. They treat missing evidence as unknown. A change with no record of who wrote it is "unknown", never "human".

The fourth point carries the most weight for AI-written code. As chapter 3 showed, commit trailers often leave agents out, so a rule that reads silence as "human" waves through exactly the changes you wanted to see.

Five policies a team can adopt

Start small. Each policy below answers one of the five questions, and each runs on tools most teams already have.

The 200-line bar and the 90-day window are examples. Pick numbers from your own pull request sizes and fix history, then adjust them after a month.

Roll each rule out as a warning first. Let it run for two weeks, read what it flagged, and fix the rule before it blocks anyone. Promote it to a hard failure once the engineers it affects agree the alarms are real. A rule that cries wolf gets bypassed, and the bypass becomes your real policy.

Keep an exception log. When someone overrides a rule, record who, when and why. That log is evidence too, and it tells you which rules need rewriting.

Prepare one answer before anyone asks for it: which changes did an agent write last quarter? Give the changes you know an agent wrote, and the label coverage for the quarter, in the form chapter 3 describes.

What your CISO will ask

• What leaves the network? Repowise runs locally and the core is open source, so you can read what it does. Source code is parsed in memory and never stored; the index lives in a .repowise/ folder in the repository. Health, change risk, attribution and Change Records need no model at all. A model key is optional, used only for generated documentation, chat, decision extraction and opt-in refactoring code, and those calls go straight from your machine to the provider you choose. The hosted option indexes code on Repowise's infrastructure instead, for teams that prefer it.
• What does edit capture store? The opt-in hooks record line hashes, the file path, an opaque session id, the tool and the model in .repowise/attribution/ on the developer's machine, a folder git ignores. They never store prompts or code, and nothing leaves the machine unless you push the optional git notes yourself.
• How long is it kept? Local data stays until you delete it, and repowise attribution purge removes the attribution data in one step. The CLI's anonymous usage telemetry holds no code, paths or repository names, keeps events for 90 days, and turns off with one command.

Do this on Monday

1. Write down your five riskiest directories, such as payments, auth or data deletion, and name one owner for each.
2. Turn one review rule you already follow into a CI check in warning mode, and read what it flags after two weeks.
3. Take the control table above to your compliance lead and mark which evidence cells you can already fill for last quarter.

How Repowise does this Repowise reads a change policy from .repowise/policies.yaml, and repowise check tests each change against it. Rules select components by name, tag or criticality, test evidence such as agent authorship, reaching tests and decisions crossed, then warn, ask for an owner review or tests, or fail the build. Results go to CI as SARIF or JUnit, and each merged change exports as an in-toto statement. Missing evidence reports as "not evaluated", never as a pass.

Sources