Governing AI Coding Agents: A Baseline-First Operating Model
AI coding agents are now part of the standard toolchain. What most organizations have not built is the governance layer underneath them: who decides what the agents are told, which third-party instructions they load, what services they may reach, and how anyone verifies that a given machine matches the intended state. This paper describes an operating model we run in our own delivery practice. It borrows nothing exotic — every mechanism is one your platform team already uses for infrastructure.
The problem: configuration nobody owns
Each agent vendor ships its own configuration surface: instruction files, skill directories, server connections, permission settings. Left alone, these fill with unreviewed, unversioned state that differs on every machine. The failure modes are quiet. An agent that lost a capability does not crash; it just performs worse. A policy written in a document but never enforced in code does not object; it just stops being true. In a regulated environment, "we do not know what our agents are configured to do" is not a tooling gap — it is an audit finding waiting to be written.
The model
1. One baseline repository. Everything shared lives in a single versioned repository: operating rules, skills, agent definitions, server connection templates. A manifest declares what exists; adapters translate it into each tool's native format; an activation command applies it. Nothing shared is edited in place on a machine.
2. Rules as code, review as the gate. Changing how the agents behave means opening a pull request. The review that protects your application code now protects your agents' instructions, which — given what agents can do with a shell — deserve it at least as much.
3. Third-party content is pinned and license-gated. External skill collections join through the manifest: a declared repository, a pinned tag, a recorded license. The sync tooling refuses sources whose license is not on a permissive allowlist. The refusal is enforced in code, because a gate that exists only in documentation is not a gate.
4. Service access is declared, not accumulated. The servers an agent may reach are part of the baseline, with machine-local secrets kept out of the repository. Removing a declaration removes the access everywhere on the next activation — subtraction converges, not just addition.
5. Verification is a separate command with the power to fail. A doctor command compares live state against the declared baseline: links resolve, pins match, declared services answer. Two lessons from running it in production are worth stating plainly. A check that can never fail is decoration, so prove your checks fire in both directions. And treat a reported success that did not happen as a defect of the highest class — it is the failure that never gets fixed, because it never gets seen.
What this buys
Provenance for every instruction an agent follows. One reviewed change to upgrade every machine. Drift that surfaces in a command instead of in an incident. And an answer, on paper, to the question auditors have started asking: how do you know what your AI tools are configured to do?
Where to start
Start smaller than the model: put the instruction files you already have into one repository, add the activation script, and stop editing machines by hand. Pinning, license gates, and health checks each earn their place the first time they catch something. Ours did.