An Agent Governance Framework in Five Controls and One Register

Why do governance frameworks fail on contact with a small team?

Because most of them are taxonomies wearing the word governance. They divide the problem into domains — data, model, human oversight, monitoring — name the risks in each, and stop before the part a small team needs: the artifact that proves the control exists, and the person whose name is next to it.

A framework that requires a governance committee, a maturity model and a tooling purchase is not wrong; it is simply not runnable by a team of six with an agent in production and a customer waiting. What is runnable is five controls and one register, each with an artifact that can be shown to somebody.

A control is not a policy. It is a condition you can check, an artifact that proves it, and a named owner — the same standard a gate has to meet before an agent is allowed to write.

I have set these up on systems where the "governance function" is one person who also owns delivery, which is the normal case rather than the exception. The five below are ordered by what fails first when they are missing.

Control 1 — The register: what the agents may do

The artifact: one table, one row per action an agent can take against a system of record.

Three fields carry most of the value. Blast radius — draft, internal record, external commitment — sorts the rows into the ones that need the other four controls and the ones that need a note. Reversible separates a mistake that costs a correction from one that costs a customer. Owner is the field that is empty in every system that later has an incident nobody can explain.

The register is the single editing point for governance. Adding a tool without adding a row is the change that matters, so the review of the register is really a review of what changed.

Cadence: monthly for a system under development, quarterly once stable. Thirty minutes, and it is the same thirty minutes that keeps the file from becoming fiction.

Control 2 — Per-action authorisation

The artifact: the scopes the agent holds, printed from the identity provider, with the diff against last quarter.

Four properties: the agent's credentials are narrower than the human who approved the workflow; they are scoped per action so a tool can be revoked without rotating everything; no credential is shared between environments, tenants or agents; and the scopes are reviewed against the register each quarter, because scope creep is the normal way a governed system becomes an ungoverned one — a debugging session adds a permission, and nobody removes it.

The failure this control prevents is specific: an incident where the run record says an agent did something, and nobody can establish which credential allowed it. That question has no good answer after the fact.

Control 3 — The evidence trail

The artifact: a per-run record joining the input as received, the prompt version, the model version, the tool calls with arguments, the decision, which gate applied, and any human override to your own task identifiers.

The acceptance test for this control is a sentence: pick a run from ninety days ago and reconstruct what happened, without the vendor's console. If that takes a support ticket, the trail is not yours, and the consequences compound — an uninspectable incident gets resolved by switching the feature off.

Retention should be decided rather than inherited: long enough to cover your review cycle and any contractual or regulatory obligation, and exported in a format that survives the vendor relationship. What a run record has to contain is the design detail; here it is the third control.

Control 4 — The approval rule and its owner

The artifact: per risk class, the condition that sends a case to a human, the queue it lands in, the person accountable, and the response time they have committed to.

Two failure modes, symmetric and both expensive. A rule that routes everything to a person reinstates the labour cost the system was bought to remove; a rule that routes nothing lets confident errors reach customers. The rule has to be written with actual thresholds in it — an amount, a segment, a confidence band — because "the operator can review it if needed" is availability, not a control, and nobody is accountable for a case nobody was required to check.

The field that gets forgotten is the response time. An approval queue with no committed response window becomes an accumulation point, and the first sign of trouble is a customer wondering why nothing has moved. Where those thresholds belong is covered in the design; governance only requires that the rule, the queue and the owner exist in writing.

Control 5 — The review loop

The artifact: a dated review — ninety minutes a quarter — that re-scores the system and records four things.

The last row is the one that keeps the register honest. An uncalled tool is a liability with no benefit, and a tool whose permissions grew quietly is the most common way an agent gains authority nobody decided to grant. The quarterly review that keeps an AI system working is the fuller version of this cadence.

What does an auditor or a customer questionnaire actually ask for?

The useful discovery is that the rows are requests for artifacts, and these five controls produce them. Not legal advice, and not a certification — a mapping from the question to the file that answers it.

If the file is complete, most of these are answered by pointing rather than writing. That is the practical argument for doing this before it is asked for: a questionnaire answered from a maintained register takes an hour, and one answered from memory takes a fortnight and produces weaker claims.

Who owns what?

Governance fails quietly when ownership is collective. One row per control is enough.

Two rules keep this from becoming a matrix nobody reads: the owner of a control has to be able to produce its artifact in a day, and an absent owner means the control is unowned rather than shared.

What this framework deliberately does not do

It does not produce a maturity score. A score cannot be compared to an invoice, and it has no owner attached; a ranked process register is the useful substitute.

It does not require a tooling purchase. A spreadsheet, the identity provider you already have, your run table and a calendar entry cover all five controls. Gateways and registries are useful enforcement layers, and they are not prerequisites — the MCP boundary question explains why the registry entry is not the approval.

It does not claim to satisfy any regulation. It maps to the questions regulators and customers ask, which reduces the cost of answering them properly. Whether a given obligation is discharged is a legal question with a lawyer's name on it.

It does not scale to a hundred agents in its current form. At that size, the register needs tooling and the review loop needs automation. The five controls are the specification that tells you what to automate, which is a better order than buying a platform and working out the controls afterwards.

Start with the register

Fill in one table — action, blast radius, reversible, scope held, owner, review date — and read the Owner column. The rows with names are governed; the rows without them are where the system will surprise you, and they are the only rows worth assigning before anything else happens.

Then close the two gaps that matter most for a system that writes: the scope printout for control two, and a reconstructed run from ninety days ago for control three. Both take an afternoon, and between them they answer the two questions that arrive first in any incident or audit — what was it allowed to do, and what did it actually do? The go-live version of this same material, gate by gate with the artifact each one requires, is in the seven gates an agent clears before it writes to production.