AI Agent Governance: The Four Controls a Vendor Review Asks You to Evidence

It starts with one agent. A code assistant, or something that drafts documentation. It works, so a second one appears, then a third, each from whichever framework the team that built it preferred, each holding its own provider key. Nobody decided to run an ungoverned fleet. It assembled itself, incrementally, out of reasonable decisions.

For a company selling software to a bank, that arrangement has a deadline attached. At some point a procurement team sends over a vendor-risk questionnaire, and the questions in it are not about whether your agents work.

What the questionnaire actually asks

Almost nobody is asked "do you govern your AI?" The questions that arrive are narrower and much harder: which of your systems can take an action without a person, what bounds it, who was notified the last time a bound was reached, and can you produce that record for the period under review.

Every one of those is a question about records rather than intentions. This is the gap teams find late — they built the control, it works, and they cannot demonstrate to a third party that it fired.

A control with no record is indistinguishable from a control that was switched off in production. Both answer the first question confidently. Only one survives the second.

Control 1 — policy, and the layer it belongs to

Policy means rules that hold across agents regardless of which framework built them: which models are approved, what content handling applies, where data may go. The part that matters organisationally is that policy is layered — a platform default, an organisation position, a workspace rule, and a decision the agent's own code enforces at the point of action. Where two layers disagree, the stricter one wins.

That layering is what lets a security function set a standard once without having to litigate every workspace's configuration. It is also what a reviewer is really probing when they ask who can change a rule and whether a team can weaken one locally.

The evidence this leaves: the policy set as it stood on a given date, which layer each rule came from, and the trail of who changed what and when. A current-state export answers none of the questions a reviewer has about last quarter.

Control 2 — a halt that does not require a deploy

When something is going wrong, the useful question is not whether a stop exists but how long it takes to reach every affected system. A stop that requires finding the right configuration file and shipping a release has a propagation path measured in the thing you are trying to get ahead of.

A workable halt has scopes, so the response can be proportionate — stop everything, stop only model calls, stop the issuing of new credentials — because an all-or-nothing switch is one people hesitate to use, and hesitation is the failure mode.

The evidence this leaves: activation records with who triggered it, at what scope, when, and when it was lifted. EU AI Act Article 14 asks that a person be able to intervene and halt a high-risk system; a halt nobody has ever exercised is a claim, and the drill you ran on purpose is the proof.

Control 3 — an audit trail, and the word to be careful with

Every action, model call and cost event needs a record. The word teams reach for here is usually "immutable" or "tamper-proof", and it is worth being precise, because a reviewer who knows the difference will notice.

What is achievable is tamper-evidence: records are sealed, checkpoints carry a Merkle root over what came before, and the checkpoint is timestamped by an external authority under RFC 3161 so the time it claims is not a time you assert about yourself. That does not make records unchangeable. It makes a change detectable, and detectable by someone who does not have to trust you — which is the property an auditor actually needs.

The evidence this leaves: the record, plus a verification path a third party can run themselves. An audit trail whose integrity rests on your assurance that nobody edited the table is not doing the job it was built for.

Control 4 — approval gates on the consequential actions

Agents should work unattended on low-stakes tasks and stop before consequential ones — changes to production systems, outbound communication a counterparty will see, spend above a threshold, anything touching a named category of personal data.

The design risk is over-gating. A reviewer facing forty routine approvals an hour stops reading them, and Article 14 names that failure specifically: the human is present and their attention has been spent on noise. Auto-approve conditions are the boundary, and they are worth writing down as policy rather than leaving to habit, because a condition set in configuration can be shown to a reviewer and argued about.

The evidence this leaves: one row per decision — who, when, what was proposed, what was decided — linked to the action that actually executed afterwards. Without that link you have proof somebody clicked a button, not proof that the approved thing is what ran.

Where the governance layer sits

There is a real architectural choice here and it is worth stating rather than glossing. A governance layer can sit in the request path, seeing and gating every call, or alongside it, reading what the agents emit and evaluating it out of band.

Dobby is out of band by default. It reads run telemetry from your agents rather than proxying their traffic, which means it is not a dependency of your production path and cannot take your agents down. The cost of that choice is honest to state: a system that is not in the path cannot block a call by itself. Where you want a decision enforced in-line, the agent's own code becomes the enforcement point via a control point — the code asks for a verdict and acts on it — which is an opt-in mode, and one that does add time to the call it guards.

This is also why the four controls above are described by the record they leave rather than by what they prevent. Prevention varies with where you place the layer. The evidence obligation does not.

Where to start

Inventory first. List the agents that exist, the framework each uses, the credentials each holds and the systems each can reach. Most teams find something they had forgotten, and an inventory you cannot produce is the first thing a questionnaire exposes.

Then get telemetry landing somewhere central, so cost and behaviour are observable at all. Then write the policy set down — approved models, spend bounds, which actions need a person. None of this is a one-day exercise, and treating it as one is how teams end up with a governance layer that covers the three agents that were easy to instrument.

The organisations that do well with agents are not the ones running the most of them. They are the ones that can answer a stranger's questions about what their agents did last quarter, with records rather than assurances.