Governance is not a velocity tax
AI coding agents multiplied your code output. They did not multiply the layer that instructs, verifies, and evidences that output — and the gap between those two curves is where ungoverned architecture accumulates. The wrong response is a new approval gate: gates tax the velocity you adopted agents for, and delivery organisations route around them.
Effective AI-code governance rides the pipes that already exist — context flows to agents over the protocol they already speak, verification runs in the CI you already have, evidence accretes as a by-product of the work. The twelve controls below are organised into four groups: what agents are told, what they produce, what you can prove, and who can see what.
Group A — Context delivery
Govern what agents are told
Most AI-code failures are context failures: the agent never saw the standard it violated. Delivery is the highest-leverage control group and the most commonly skipped.
Standards are machine-readable and versioned
Checks, specs, and architecture decision records live in git — not in a wiki addressed to humans who might visit. If an agent cannot read a standard at write time, the standard does not govern anything.
Context is delivered at write time, by protocol
Agents pull current standards over MCP at the moment they write — not from whatever a developer remembered to paste. Delivery by recall is delivery by chance.
Every agent gets the same context
One governed source for every developer, repository, and session. Per-developer rules-file forks are standards variance you have not measured yet — diff two teammates’ agent configs and see.
Group B — Verification
Govern what agents produce
Delivered context is not obeyed context. Agents follow instructions imperfectly, so output verification stays load-bearing — but it should be automated where the mistakes repeat.
Architecture checks run in CI
Standards compile into automated fitness tests that validate every pull request — human reviewers stop re-litigating the same conventions and spend attention on design.
Review depth is tiered by risk
An internal tool and a payment path do not deserve the same scrutiny. Write the tiers down; "everything gets a careful review" means nothing does. This is a process control — no tool supplies it for you.
Recurring AI mistakes become new checks
When an agent makes the same mistake twice, the fix is not a sterner prompt — it is a new check. One mistake, one check, zero recurrence: the feedback loop that compounds.
Group C — Evidence
Govern what you can prove
Due-diligence questionnaires and audits have started asking how AI-generated code is governed and traced. "We don’t know" is an answer on the record — these three controls replace it.
Decisions are recorded as a by-product
Agents record architecture decisions at the moment they make them, from inside the workflow. Records reconstructed months later under audit pressure are part memory, part fiction.
Provenance is answerable per change
For any shipped change, you can state which standards and constraints applied when it was written. This is the exact question enterprise security reviews are learning to ask.
Documentation drift is detected, not discovered
Repository scanning compares what the docs claim against what the code contains. For audit evidence, a stale claim is worse than no claim — it is a confident falsehood with a timestamp.
Group D — Access & boundaries
Govern who and what can see
Agent context is organisational knowledge flowing through new pipes. The boundaries that governed the old pipes need equivalents on the new ones.
Agent credentials are scoped
A team’s API key exposes that team’s context and nothing else. One org-wide key in every repo is a data boundary you have already given up.
Published knowledge is scanned for secrets and PII
Anything leaving the boundary — published docs, shared context — is scanned and redacted at publish time. The second audit failure mode is evidence that leaks what it should not.
Residency and retention are known answers
Where does agent-readable knowledge live, under which jurisdiction, deleted on what schedule? For regulated organisations these are questionnaire line items, not philosophy.
Score it, then start with one repository
Twelve controls, one point each. Most organisations adopting agents score under 4 — usually the review-tiering point, a partial point for CI, and little else. That is not negligence; the tooling for the other nine barely existed until recently.
SystemDox covers the infrastructure points directly: standards git-first and served over MCP (1–3), checks as CI fitness tests (4, 6), decision records and provenance from inside the agent workflow (7–8), staleness detection (9), key-scoped access (10), sanitized publishing (11), and UK data residency in AWS eu-west-2 (12). Point 5 — risk-tiered review — is policy; no tool supplies it, including ours.
For the leadership version of this argument — the ten-minute audit that shows whether anyone governs what your agents are told — read Architecture Only Exists at Write Time.