Skip to content

Governance As Code

Canon Beast edited this page Aug 24, 2026 · 2 revisions

Governance as code

A policy document has never stopped an agent. A checked gate has.




The distinction the whole page rests on

Governance without velocity is bureaucracy. Velocity without governance is a liability.


Most organisations have the first one and call it the second one's fault. The way out is not less governance. It is governance that executes rather than governance that is published.


Written governance Governance as code
Where it lives A document, a policy site, a slide The deployment pipeline, the gateway, the agent's own configuration
How it is enforced Someone remembers The thing does not run
How you audit it Ask people Read the log
What happens under deadline pressure It is waived, verbally It is waived with a name and an expiry date, or it is not waived

The last row is the one that matters. Every governance system gets overridden. A good one records who overrode it and when the override expires. A bad one has no record because there was nothing to override.



The guardrail stack: three layers, and they fail differently


Layer 1 · Policy

What the agent must never do, written as specific outcomes rather than as principles.


These are never events: not "be careful with pricing" but never promise a price that is not in the database. Not "respect professional judgement" but never override the named professional's decision.


A never event is testable. That is the entire difference between this and a policy document. If you cannot write a test that fails when the agent does it, it is a value, not a never event, and it belongs somewhere else.


Layer 2 · Technical

What the agent cannot do, because the system will not let it.


Input and output controls: sensitive-data detection before anything reaches the model, output scanning for the failure patterns you have actually seen, and injection defence anywhere an outside party can put text into the system.


Layer 2 is the only layer that works when nobody is watching. Layers 1 and 3 depend on someone reading something.


Layer 3 · Organisational

Who is accountable, and what they are accountable for.


A named owner per agent. A review that happens on a date rather than on a feeling. An escalation path that was written before the incident.


Three layers, and the common failure is having only the first. A policy layer with no technical enforcement and no named owner is a document that describes a system nobody built.



The four pillars, which is the same idea at the programme level

Pillar What it means in practice The rule that makes it real
1 · Visibility Every agent has a registered ID, a named business owner, a risk tier, and a link to its audit log No registry entry, no API key
2 · Security Sensitive-data detection on every input before the model sees it; output scanning; injection defence on anything externally facing Enforced at the gateway, not requested in a guideline
3 · Quality Every agent has a golden dataset built by a domain expert, not by the developer. The pipeline blocks a deployment when accuracy falls below the baseline The block is automatic. A quality gate a human can wave through is a quality suggestion
4 · Cost Cost per transaction reported to the sponsor on a cadence. Automatic suspension when cost or error rate breaches a threshold The threshold is set before the agent runs, not after the invoice

Pillar 4 is the one that gets added after the first surprise invoice, and it is the cheapest of the four to build up front.



Two controls people conflate


Circuit breaker Kill switch
What it does Degrades the agent automatically: back to read-only, back to draft mode, scope blocked, spend capped Stops the agent
Who triggers it A threshold. Error rate, cost spike, drift signal A person
When it fires Whenever the threshold is breached, including at 3am with nobody awake When someone decides
Why you need it Because the failure you did not anticipate will happen outside working hours Because some failures should not be degraded, they should end

A programme with only a kill switch has a control that requires a person to be paying attention, which is exactly the assumption agentic systems break. Build the circuit breaker first.


Design the kill switch to be fast, obvious and testable. A global hard stop that revokes tool permissions and halts the queue, plus softer switches for session pause and scoped blocks. Test it on a schedule. An untested kill switch is a belief about a kill switch.



The system of record

An immutable log of prompts, retrieval, reasoning and outcomes.


It is the thing that makes every other control auditable, and it is almost always the thing that was not built, because it produces no visible feature and costs storage.


The test for whether you have one: an agent did something wrong six weeks ago. Can you reconstruct what it saw, what it retrieved, what it decided and why, without asking anyone? If the answer involves a person's memory, there is no system of record.



The pre-flight gates

The repo publishes a pre-flight checklist with ten gates. Source material behind this page describes seven.


The published ten are the artifact of record and they are what this page endorses. The discrepancy is recorded here rather than reconciled silently, because a governance page that quietly changes the number of gates is demonstrating the exact failure it is warning about.


One rule about all of them: gates are checked, not claimed. A README asserting something exists is not evidence that it does.



The paved road

The alternative to enforcement is not freedom, it is a shadow estate.


The CoE provides a standard platform: infrastructure, logging, guardrails, the registry. Teams that build on it get faster approval and support. Teams that go off-road own their own risk, explicitly and in writing.


This is what makes governance survivable. A governance function that only says no gets routed around. One that offers a faster path for the compliant route gets adopted, and the exceptions become visible rather than hidden.



From the practice canon. Developed through client delivery and refined in collaboration; the frameworks stated here are the author's own.

Clone this wiki locally