PrymeIntelligence
Sign in Start Free
Home/Ideas/Agent governance is a bound, not a model
Ideas · Agent governance · 28 Aug 2026

Agent governance is a bound, not a model.

Every serious conversation about agent risk eventually arrives at the same place: not what the model can do, but what it is permitted to do, who decided that, and whether the decision is enforced anywhere other than a policy document.

The market has spent three years optimising the wrong half of the problem. Enormous effort has gone into making agents more capable, and almost none into making capability bounded — which is the only half that an operations director, a compliance officer or a regulator actually asks about.

Ask most teams how their agent is governed and you get one of three answers. A system prompt that asks it politely not to. A classifier that flags outputs after they are produced. Or a human in the loop, meaning a person who approves everything until the volume makes that impossible and then approves nothing.

None of these is a bound. A bound has three properties: it is stated before the action, it is read at execution time, and it can refuse. A prompt fails the third test, a classifier fails the first two, and a human queue fails all three the moment it backs up.

What governance has to answer

There are four questions, and a governance layer is worth having only if it can answer all four without a person reconstructing anything from logs.

  • What is this agent allowed to do? Not in principle — right now, per capability, as a value something reads.
  • Why is it allowed that much? Which specific bound produced the answer, given that several apply at once.
  • What did it actually do? Including the things it refused to do, which are the entries that matter most in an audit and are missing from almost every system.
  • What changes if I change something? If a certificate lapses or a source disconnects, the permitted depth has to move on its own.

A control that cannot refuse is a preference. A control that refuses but cannot say which rule refused is an outage.

The two failure modes we designed against

Five bounds, and the smallest one wins

In our model an agent’s effective authority at any instant is the minimum of five separate things: the role scope it was published under, the certificate it currently holds, the sources it can read, the ceiling its customer set, and the guardrails in force. We call it the minimum chain, and it is deliberately unexciting arithmetic.

The value of stating it as a minimum is that it makes every refusal attributable. When an agent declines, exactly one of those five was binding, and the system can name it. “Certificate below required depth” is a different conversation from “your plan does not include this”, which is different again from “the role never permits it” — and a system that returns the same flat refusal for all three has told you nothing on any of the three occasions.

The longer treatment of the chain works through what each link is for and why the arithmetic has to be a minimum rather than a policy engine.

Capability is a verb, an entity and a depth

Most permission systems model capability as an integration: the agent has Xero access, or it does not. That collapses on the third vendor, because the thing you certified was never “Xero” — it was posting a journal entry.

We define a capability as a verb against a canonical entity, at a depth. Post a journal entry, at depth 3, is one capability whether it executes on Xero, NetSuite or a bank’s own core. Adding a fourth vendor is a connector certification and changes nothing about the agent. Collapse those two and every integration becomes a retraining programme; most platforms find this out expensively.

Three states, not two

Binary permissions cannot distinguish a capability nobody has built from one that is refused on purpose. Both render as “no”, and they demand opposite responses — one is a to-do, the other is an argument you would have to win. We carry held, unheld and withheld as distinct states everywhere they surface, at real cost to the interface, because the distinction is what makes a capability table actionable rather than decorative.

What this costs

Governance done this way is slower to stand up than an agent with a permissions checkbox. Depth has to be earned against scored cases rather than set in a field, evidence expires, and the honest consequence is that a new agent starts narrow and widens over weeks.

We think that is the correct trade, and we would rather say so than pretend the trade is not there. The alternative is an agent whose authority was decided by whoever was in the room, justified by a number nobody has checked since, and reconstructible only from logs that do not record the refusals.