The trust-root question: who is allowed to be the thing you cannot question?

Agent platform field notes, one of eight. Each note is one decision a CTO or Head of AI has to make, with the evidence I used, where I landed, and what I still cannot prove.

The question

When an AI agent does something inside your organisation, which component gets to say, with authority, that it was allowed to? That component is your trust root. Everything else on the platform can be checked against it. It cannot be checked against anything.

Most teams never choose one. They inherit one. The orchestration framework becomes it, because the policy hook lives there. Or the model provider becomes it, because the function-calling API decides what counts as a tool call. Or the cloud becomes it, because identity and logs live in its IAM and its audit service. The decision is made by whichever vendor got installed first.

My short answer, after a year of designing and building a governed agent platform for Dutch local government: no runtime, model provider, cloud or hardware vendor may be the trust root. The trust root has to be a component you own, that is small enough to understand, and that every other component is forced to talk to through a published contract.

Juvenal asked who guards the guards. Two thousand years on, the answer in most AI platforms is: whichever vendor was installed first.

Why I landed there

Three findings pushed me.

The policy hook is not the policy. Every major agent framework I evaluated, more than a hundred of them by now, offers a place to attach guardrails: a callback before a tool call, a middleware on the model request, a graph node you can route through. Useful. But a hook inside the runtime is enforced by the runtime. If the runtime has a bug, a bypass path, or simply a newer version with different semantics, the policy goes with it. A rule that lives inside the thing it governs is a convention, not a control. I wrote that down as an architecture decision: rules are enforced outside the prompt and outside the runtime, by a component that does not run agent code.

Model output is a proposal, not an instruction. When a model returns a function call, the framework typically executes it. That makes the model the authority on what happens next. I inverted it: a model-produced tool call is a proposal, and a deterministic local component decides whether to authorise and execute the effect. The model cannot talk its way past a policy it never gets to evaluate. This sounds like a small change. It changes everything about where the audit trail starts.

Provider logs are not your evidence. If your record of what an agent did lives in your model provider’s dashboard, you do not have a record. You have a view into someone else’s system, under their retention policy, in their region, subject to their contract changes. For a municipality that may have to defend a decision in front of a citizen or a court, that is not acceptable. The authoritative evidence of a run has to be written by the component you own, at the moment the decision was made, and it has to be tamper-evident.

Put those together and the shape of the trust root is clear. It owns identity: human, workload, tenant, agent, tool, model and runtime. It owns delegation and policy. It owns the decision to admit a run, to approve an action, to let data leave. It owns the evidence record. It does not run agents, it does not host models, and it does not need any particular cloud.

The decision, concretely

I split the platform into an owned governance spine and everything else.

The spine is four responsibility planes: governed execution and policy; identity, delegation and registry; verification, evaluation and evidence; and sovereignty, deployment and compliance. That is the trust root. It is deliberately small.

Everything else, the agent runtimes, the models, the workflow engines, the protocol implementations, the vector stores, sits outside the spine and is governed through versioned contracts and adapters. They are sourced, not owned, on one condition: their behaviour can be constrained, observed, tested and replaced.

The test I apply to any component that wants to join the spine is the exit test. If I remove it, do I lose agent definitions, policies, evidence, audit history or run records? If yes, it was in the spine all along and must meet spine rules. If no, it is a sourced component and may be swapped.

The hardest consequence was for our own reference runtime. It is tempting to give your own runtime a private path: a signing key, a hidden evidence channel, a policy shortcut, because you trust it. I did not. The reference runtime uses exactly the same published interfaces as a third-party runtime would. No private bypass API, no privileged signing authority, no standing credential. If I cannot replace my own runtime without losing governance, I have not built a governor; I have built another framework.

Two assurance classes, kept honest

The trust-root decision has a cousin that gets ignored even more often: where does inference run, and does the answer change your claims?

I separated model assurance from deployment topology and made them two explicit classes. In the first, inference, data, keys, evidence, telemetry, identity and operations all stay inside the municipality’s control; no remote model provider is required. In the second, the governor stays local, but policy-approved, minimised data goes to one explicitly qualified remote model route, with provider, legal entity, region, retention, subprocessors and expiry all pinned.

The rule that matters: the second class never inherits or implies the first. A frontier-connected route is never presented, inferred or marketed as sovereign. Automatic failover from a sovereign route to a remote one is prohibited. If the sovereign route is unavailable, the run degrades safely, waits for a human, abstains or is denied. It does not quietly phone out.

That rule costs availability. It is the right cost. The alternative is a sovereignty claim that is true until the first outage.

What I cannot prove yet

Grading my own work the way I grade every claim on this site: this is a prototype, not a deployed system. There is no municipality running it, no measured override rate, no incident that tested the evidence chain in anger. The architecture has more than forty recorded decisions and a threat model that treats the platform’s own agents as adversaries, and I built it with a pipeline of AI coding agents that are themselves subject to the same spine. But the exit test, in particular, has been exercised in design and in demos, not in a migration under pressure.

The honest limitation of a trust root you own is also obvious: you now own it. Its security, its availability and its correctness are yours. A small spine is easier to get right than a large one, which is why I kept it small, but small is not the same as finished.

What to do with this

If you run or are about to buy an agent platform, ask one question in the next architecture review: which component is our trust root, and did we choose it?

Then apply the exit test to every component on the diagram. Anything whose removal loses policy, identity or evidence is in your spine. Count how many of those you own. If the answer is zero, you do not have an AI governance problem. You have a vendor who does, on your behalf, without your signature.

The next field note is about the two assurance classes in detail: what it takes to qualify a frontier model route so that “connected” stays an honest word.

Have you tried turning it off and on again? With a trust root you inherited rather than chose, the harder question is where the switch is.

References

The allusions and quotations in this piece, with their origin:

• Juvenal, Satires VI (c. 100 AD): “quis custodiet ipsos custodes”, who guards the guards.
• The IT Crowd (Channel 4, 2006-2013): “Have you tried turning it off and on again?”, Roy’s standard first response.