Governance as Code: When the Rulebook Can Enforce Itself

Walk into almost any organisation and ask to see its governance. You will be handed documents — an information security policy, a data classification standard, a retention schedule, a privacy framework — usually as PDFs in a SharePoint folder, often a version or two behind reality. They are careful, well-intentioned, and almost entirely disconnected from the systems they are supposed to govern. The policy says data is classified and retained to a schedule; whether that is actually true in the database is a separate, unanswered question. The gap between what the document says and what the system does is where nearly every real governance failure lives.

I think that gap is closing, and that the organisations which close it deliberately will have a structural advantage. The shift is simple to state and hard to do: stop writing governance only as prose, and start expressing it as code — machine-readable policy that the system reads, enforces, and produces evidence against at every layer. Governance stops being a document about the system and becomes part of the system.

How I think about technology governance

Before the vision, the principles underneath it, because the vision is only as good as the discipline you bring to it. A few hold across everything I have built — a brokerage's compliance process, a government cyber uplift, an AI control plane, a data-governance program:

• -Business first, technology second. The wrong opening question is "what tools do we need?" The right one is "what does success actually look like, and what risk are we accountable for?" Controls flow from that, not from a vendor's roadmap.
• -Evidence over assertion. A control that cannot produce evidence is a belief. The work is in making the right thing the recorded thing.
• -*Anchor to a recognised standard, and the right one.* ISO 27001, the ISM and Essential Eight, the Privacy Act and APPs, NIST's AI frameworks — chosen to match the context, so the control set can be reviewed, challenged, and uplifted against a known baseline rather than argued about.
• -Independence — the second line. Governance is most credible when it constrains the builder, including when the builder is me.

The operational scaffolding around this is unglamorous and I will mention it only in passing — ITIL Foundations, the service-management vocabulary of change, problem, and configuration that keeps governance from collapsing into heroics. None of it is the point. The point is that these principles, today, are mostly enforced by people remembering to apply them. That is the part that does not scale, and the part agentic AI is about to break.

Why this is urgent now: governing agents through a context layer

Here is the forcing function. We are handing real work to AI agents — systems that read data, make decisions, and act. An agent does not read your policy PDF. It cannot be sat down and trained on tone and judgement. It will do whatever its context and its permissions allow, at machine speed, and it will be prompt-injected and will over-reach. Governance that exists only as prose is, to an agent, invisible.

So an agent needs governance it can actually consume: a context layer that tells it, in a form it can read, what this data is, how it is classified, where it may go, how long it may live, and what this particular caller is allowed to do with it — and a control plane that enforces those answers rather than trusting the agent to honour them. I have built the beginnings of this. My Agentic Development Platform treats the agent as an untrusted insider: deny-by-default guardrails, an append-only audit trail, and a context broker that hands the agent a small, governed packet of pointers instead of dumping the whole estate into a prompt. That broker is not just a cost optimisation — though bounding tokens matters — it is a governance surface. The thing that decides what context an agent sees is exactly the thing that should be enforcing classification, purpose, and access.

Codified governance is what makes that context layer possible. You cannot feed an agent a policy it can reason over, or gate its actions against a control, if the policy and the control only exist as English in a document.

What "codified" looks like, layer by layer

Concretely, the governance documents become configuration and rules that live with the system, version-controlled, and are referenced at every conceptual layer — storage, application, API, and the AI context broker. Four pieces do most of the work:

• -Classification and categorisation. Every data domain carries a machine-readable classification — PII, sensitive, financial, health, operational — and a lawful basis and residency. Not a label in a spreadsheet, but an attribute the system can read at runtime. Get this right and almost everything downstream becomes derivable rather than manual.
• -Classification rules. The logic that assigns classification — by source, field, pattern, or domain — expressed as rules rather than tribal knowledge, so a new table or a new document is classified consistently and automatically, not whenever someone gets around to it.
• -Retention and disposal. The retention schedule stops being a wall chart and becomes policy-as-config: each class mapped to a trigger, a period, and a disposal method — soft-delete, hard-delete, crypto-shred, or anonymise — enforced by a scheduled job that logs every action. I have built exactly this pattern in a production codebase: a data map, a retention schedule, a deletion policy, and an export/portability scope, all as version-controlled configuration that jobs execute and audit. The schedule and the enforcement are the same artefact, so they cannot drift apart.
• -Data lineage. Where data came from, what transformed it, and where it flows — captured as structured metadata rather than reconstructed by hand during an incident. Lineage is the connective tissue that makes the other three useful across systems.

The unifying idea: one source of governance truth, expressed as code, enforced at each layer it touches. The classification you set once is the same classification the storage layer encrypts by, the API redacts by, the retention job disposes by, and the agent's context broker filters by.

What it unlocks

This is where it stops being an architecture diagram and starts paying for itself:

• -Audit becomes a query, not a project. When classification, retention, and access are codified and every enforcement writes an immutable event, "show me that personal data is retained to schedule and access is appropriate" is answerable in minutes against the log — instead of a three-week evidence-gathering exercise that is stale the moment it finishes.
• -DLP gets something real to act on. Data-loss prevention is only as good as its understanding of what is sensitive. Codified classification gives DLP, egress controls, and the agent context layer a precise, current signal — so prevention is driven by the actual classification of the data, not a fragile guess at the gateway.
• -Financial reporting gets data quality it can trust. Numbers are only as reliable as the reference data underneath them. A governed, classified, lineage-tracked reference set means a figure in a report can be traced to its source and its definition — the difference between a control environment that can stand behind its numbers and one that hopes they are right.
• -*It makes building easier, not just safer. This is the part people miss. When data is classified, described, and lineage-tracked, a developer — or an AI agent — can find the correct, authoritative* data quickly instead of guessing between three diverging copies. Governance, done as code, becomes a productivity feature: the fastest path to the right data is also the governed one.

From RBAC to RBAC + ABAC

Codified governance also lets access control grow up. Most organisations run on role-based access control (RBAC): your role grants a fixed set of permissions. RBAC is necessary and it is not enough — it cannot express "this caller may read financial data, but only for their own region, only for a permitted purpose, and not export it offshore." Those are attributes — of the data, the user, and the context of the request.

That is attribute-based access control (ABAC), and the reason most ABAC programs stall is that they have no reliable source of attributes to evaluate. Codified classification, residency, purpose, and lineage are that source. Keep RBAC as the coarse-grained backbone — it is simple and auditable — and layer ABAC on top for the fine-grained, contextual decisions, evaluated against attributes the system already maintains because governance is code. The result is access control that can finally express what the policy always intended, and enforce it at the same layer the agent operates in.

Where this actually is

I will be honest about the maturity, because overclaiming a vision is its own governance failure. Pieces of this exist and work — the agentic control plane and context broker, the config-driven data governance in a real product, the requirements-led tooling and lineage work I am doing now in a data-governance function. The fully unified version — one codified policy fabric enforced identically across storage, application, API, and AI layers, with ABAC evaluated against it — is a direction I am building toward, not a finished platform I am claiming to have shipped. That distinction is exactly the discipline the vision demands.

But the direction is, I think, inevitable. Agentic AI removes the human who used to quietly hold governance together by remembering to apply it. What replaces that human cannot be a longer PDF. It has to be policy the system can read and enforce on its own — a rulebook that, for the first time, can enforce itself.

Written by Zachary Reeder — founder of OtterBlock, builder of the Agentic Development Platform, and a data-governance practitioner. The patterns described draw on production work across AI control tooling, a config-governed hospitality platform, government cyber uplift, and enterprise data governance.