AI Agent Governance Needs Five Kinds of Context. Two Make It Defensible.

Derive the problem from scratch and two of the five carry the weight: the kinds of context a regulated business is audited on, and the hardest to get right.

The previous pieces argued that an agent needs trustworthy context and enforced control to act safely, and named the properties that follow. A careful reader will push back on any such list, and fairly so: who says these are the right properties, and why five kinds of context rather than some other set? The honest answer is to derive them from the ground up instead of asserting them, for the architect or CTO weighing whether the framing is sound, beyond whether it reads well. Most AI agent governance starts from a control catalogue someone inherited, or a vendor's diagram, and works backwards. That is how you end up governing the things that are easy to govern rather than the things that matter. So let us build it from nothing and see what the problem forces on us.

Start with the only question that counts. For an agent to take a correct, safe, and accountable action in a regulated enterprise, what must be true at the moment it reasons or acts? Everything a context layer does exists to make the answer provable, per request, at scale. The question doubles as a filter: if a component does not help make an action correct, permitted, grounded, or accountable, it is decoration, and you can cut it.

What the question forces

Push on it and a handful of requirements fall out by necessity. The agent's action has to be semantically correct and procedurally correct - it means what you mean, and it follows the approved method. It has to be authorised for this principal, purpose, and channel, and no wider. It has to be grounded in real, current evidence with known lineage. The rules have to be enforced at runtime, where the agent acts, rather than only represented in a policy store. The whole thing has to be reconstructable afterwards, with a named human or role accountable where it matters. And the context itself has to be resilient - degrading safely when it is stale, missing, or disputed, rather than answering with confidence it has not earned.

Those are the acceptance tests for any design that claims to solve this. The more useful output of the derivation, though, is the other one: the kinds of context an agent actually consumes. There are five.

Meaning is entities, definitions, metrics, relationships: the ontology of how the enterprise talks to itself. Know-how is the playbooks and task sequences that capture how regulated work is really done. Norms are the policies, permissions, and approval paths that define acceptable action. Evidence is provenance, lineage, freshness, and confidence for every piece of context. And Authority and Accountability is the binding of the principal's identity (a person, or a governed non-human identity with a named owner) and purpose to what is permitted, plus the named human or role answerable for the outcome.

The three that come easily, and the two that decide it

Here is the part worth slowing down on, because it is where most AI agent governance quietly goes wrong. Three of the five come easily: meaning, know-how, norms. They are what a good analytics assistant already needs, and any serious context effort reaches for them first. The trouble is that three is enough for a system that answers and not enough for one that acts on what it finds.

Evidence and Authority are the other two, and a regulated enterprise cannot treat them as afterthoughts. An answer without evidence is worthless the moment a regulator asks how you know. An action without bound authority is dangerous the moment it touches a customer. They belong alongside the first three, because they are the two that turn 'helpful' into 'defensible', and the two a regulated business is audited on.

A model that is helpful will impress your team. A model that is defensible will survive your auditor. Those are not the same bar.

Representing a rule is not enforcing it

There is a second, sharper distinction hiding inside Norms, and getting it wrong is how well-meaning programmes end up governing nothing.

Most tools represent a norm. They store the policy as content: this role cannot see that field, this action needs sign-off. Storing it is necessary, and it is not the same as applying it. Enforcing a norm means binding identity, purpose, and entitlement in line, per request, before the agent reasons, so the rule shapes what the agent can physically see and do. Representation is a stored rule. Enforcement is a decision made in the request path, every single time.

That one separation is the line between a context foundation and a context-and-control plane. It is also, not by accident, where a horizontal product built for every industry tends to stop, because enforcement is specific, unglamorous, and hard to demonstrate. For a bank or an insurer, it is the whole job.

What first-principles AI agent governance catches that a checklist misses

Consider a composite from claims handling at a mid-sized insurer. The team adopts a well-regarded governance framework for its new claims-triage agent: model registry, bias testing, an approval workflow, a policy library. It passes internal review. Then a claims handler asks the agent to compare a claimant's current submission against their history, and the agent cheerfully pulls records from a related party's policy - same household, different entitlement. Every control on the checklist was green. None of them governed the thing that went wrong, because the framework represented norms and never enforced authority at the moment of retrieval, and the evidence trail could not show, afterwards, which records had been assembled or why.

Derive from the five dimensions and that failure is visible before it happens: the design had Norms and Know-how, and almost nothing on Evidence and Authority. A checklist inherited from elsewhere would never have surfaced it. That is the practical payoff of first principles over borrowed frameworks: it tells you what your governance is missing, rather than only whether you completed it.

The cost of missing those two dimensions is rarely a dramatic breach. It is a quiet, expensive drift. In the insurer's case the near-miss surfaced weeks later, when a data-subject access request asked what personal data had informed a particular decision, and nobody could answer with confidence, because the trail of what the agent had assembled was never captured. The team spent a fortnight reconstructing by hand what a run ledger would have produced in a second. That is the signature of weak Evidence and Authority: their absence does not announce itself in testing, where the happy path works and the demo shines. It shows up much later, in an audit, a complaint, or a regulator's question, and by then the cost is measured in weeks of forensic work and a dent in the second line's confidence. First principles is cheaper because it moves that discovery to the whiteboard, where the fix costs an afternoon.

The objection: isn't first-principles just over-engineering?

The fair counter is that most teams do not need a derivation; they need to ship, and the platform defaults plus a sensible policy library will cover the common cases. There is truth in it for low-stakes, internal, read-only agents - if the worst outcome is a wrong answer a human reviews, the full apparatus is overkill, and I would not impose it.

But the moment an agent acts on a customer's account, or reads regulated personal data, or takes a step that is expensive to reverse, the common cases are not the ones that matter. The ones that matter are the edge cases where authority and evidence are ambiguous, and those are exactly the cases platform defaults were not built to catch. First principles is not ceremony here; it is the cheapest way to know, in advance, which of the five dimensions your design is weak on. You can choose not to build all five. You should not do it by accident.

What to do differently on Monday

Take any agent heading for a regulated workflow and score it against the five dimensions out loud, with the people who own each. Does it compute meaning from a governed source, or guess? Does it follow an approved playbook, or improvise? Are norms enforced where the agent acts, or only represented in a catalogue? Does every output carry its evidence? And is authority bound to a specific principal, purpose, and channel, with a named human or role accountable? Wherever the honest answer is thin, you have found your real gap - usually Evidence and Authority, no matter what your governance framework claimed to cover.

Then apply the one test that cuts through any vendor conversation: for each of the five, ask whether the tool represents it or enforces it. Most will answer honestly only when you make the distinction explicit. That single question will tell you more about whether an agent can go live than any capability matrix.

Where this leaves us

The rule is rarely the gap; the gap is whether anything in the agent's path enforces it. That distinction, plus five kinds of context, two of which decide whether an agent is defensible, is the substance of good AI agent governance. Derive it this way and you can look at anything (a platform, a framework, a vendor's demo) and say precisely what it governs and what it only documents.

All of this falls out of the problem itself, before any product enters the room. What the market has actually built is a separate question, and a noisier one.

Next: one idea under a dozen names, who is actually building it, and the one part almost none of them have solved.