The review comment that changed this design was one sentence long, and it was correct: a trusted core that agents call advisorily is exactly as bypassable as the policy engine it was supposed to improve on. The host can ignore the verdict. It can cache it. It can fabricate it.
I had been describing the thing I was building as the layer agents cannot bypass. That description was false in most of the deployments it would actually run in, and it was false for a reason no amount of engineering on my side could fix: I do not own the kernel, and I do not own the gateway. Non-bypassability is not a property of my code. It is a property of a deployment topology belonging to somebody else.
There were two honest responses. Assert the guarantee anyway, in the confidence that almost nobody checks the difference between a control and a witness. Or state the condition, record which mode each deployment actually achieved, and build the machinery that refuses to let an artefact claim more than it earned.
This is the report on taking the second, including what it cost.
Two modes, and the vocabulary each has earned
Mediated means the decision sits in the execution path. Bypassing the control means bypassing execution itself. That is not a description of software quality; it is a description of where the software sits. Three topologies qualify. Kernel-mediated: policy compiled into kernel enforcement, so that a denied syscall or path is unreachable regardless of what the agent decides to do. Gateway-mediated: all tool and network traffic forced through a proxy that fails closed, with no route from the agent's network namespace to the target that goes around it. Broker-mediated: the capability itself — the credential, the egress socket, the tool handle — is issued per action and is unobtainable any other way.
Advisory means the host calls the control and may ignore it. The agent process retains an unmediated path to the effect. Everything the control produces is still real: the decision was made, the evidence was signed, the action is attributable to a principal and a chain. What is not true is that anything was prevented.
Advisory is a legitimate mode and I want to be emphatic about that, because the temptation when drawing this distinction is to make one side sound like a failure. Most first integrations start advisory. Signed evidence has real value with no mediation at all — it survives a dispute, it attributes an action to a principal, it makes a denial checkable by someone who was not there. A great deal of what organisations actually need from this layer is available in advisory mode.
It is simply not containment, and it must never be sold as such.
The rules that make the distinction bite
A definition that lives in a document is the thing this practice keeps finding to be worthless. So the distinction is carried in the artefact and enforced by the verifier.
- Every receipt must carry its enforcement mode. Without it, an advisory deployment's receipt is indistinguishable from a mediated one, and the non-bypassability claim becomes unfalsifiable — which is the technical term for marketing.
- A verifier must reject any non-bypassability or containment claim asserted by, or on behalf of, a receipt whose mode is advisory. Not warn. Reject.
- Conformance reports must state the mode of every run. Passing in advisory must never be reported, summarised or marketed as passing in mediated.
- Mode must be determined by attested deployment facts — the compiled policy digest, the gateway's enforcement attestation, the broker's issuance record — and must not be a configuration flag the operator simply sets.
- A deployment that cannot substantiate a mediation path must default to advisory. Fail-closed applies to claims as well as to actions.
- Mode may vary per operation class. A deployment that is kernel-mediated for network egress and advisory for file writes must report two modes, not one average.
The fourth rule is the one that does the work, and it is worth pausing on because it is the rule every product in this category violates.
Mode is established by attempting to bypass
A deployment claiming mediated has to produce four things, and the third is the one that cannot be faked cheaply.
The mediation digest identifies the compiled kernel policy, gateway configuration or broker ruleset actually in force — content-addressed, so that the claim is about a specific ruleset rather than about a ruleset's name. The attestation is a signed statement from the enforcement point that this ruleset is loaded, which closes the gap between a ruleset existing and a ruleset being active. Then the escape suite.
The suite runs an agent explicitly instructed and equipped to reach the effect without going through the control. Not a test that the control denies things — the control denying things is trivially demonstrable and proves nothing about bypass. A test in which something actively tries to get around it, on the same topology, with the same configuration, and every attempt is required to fail. Mode is verified by attempting to bypass rather than by reading a configuration file, because reading a configuration file tells you what somebody wrote down.
The fourth artefact is the coverage list, and it is deliberately adversarial: it must enumerate which operation classes are mediated and, explicitly, which are not. A mediation claim that lists only what it covers is not auditable, because the reader cannot distinguish between an operation class that is mediated and one that nobody thought about.
This is where the per-class rule earns its place. Real deployments are mixed. Kernel-mediated for network egress and advisory for file writes is an honest and common answer, and a system that forced a single global mode would push every such deployment toward the more flattering of the two.
What this contract costs
A design decision reported without its cost is a decision being sold. Three costs, and the first is commercial.
The honest answer for most first integrations is the word advisory. That is a worse position than every competing product occupies, because the competing products do not make the distinction and are therefore free to use containment vocabulary from the first call. I have built a machine that says a weaker thing about my own system than my competitors say about theirs, and the weaker thing is the true one. I do not have a way to make that commercially comfortable, and I have stopped trying.
It converts a one-time claim into a per-deployment property. A claim asserted in documentation is asserted once. A claim substantiated by an attested ruleset and a passing escape suite has to be re-established when the topology changes, which is continuously. That is real operational load and it falls on the deploying organisation rather than on me, which makes it a cost I am imposing on someone else — worth naming plainly rather than describing as rigour.
It makes some questions unanswerable that customers would like answered. "Is your product secure?" has no answer under this contract. The answerable questions are narrower: which operation classes are mediated in this deployment, what the escape suite found, what the coverage list leaves out. Those are better questions. They are also harder to ask, and a buyer who wants a yes will experience the contract as evasion.
Why this matters more in the current regulatory posture, not less
There is a reading of the present moment in which none of this is urgent. The revised interagency guidance on model risk management issued on 17 April 2026 — carried by the Comptroller's office as Bulletin 2026-13 and designated SR 26-2 by the Federal Reserve, superseding the 2011 and 2021 letters — places generative and agentic AI expressly outside its scope, and states that it does not set forth enforceable standards or prescriptive requirements.
Read casually, that says nobody is going to ask. Read carefully, it says something close to the opposite.
What was withdrawn was the framework that would have specified the controls. The obligations attached to the underlying action were untouched. Safety and soundness, consumer protection, sectoral duties and third-party risk all survive, and the April text's own third-party passage is explicit that its principles remain applicable even where a vendor's code, data and methodology are proprietary. So an institution still owes the outcome, and no supervisor is currently telling it what the control looks like.
That is the exact condition under which vocabulary gets set by whoever is selling. In the absence of a supervisory definition of what an agent-governance control is, the definitions in circulation are written by vendors and shaped around what those vendors' products happen to do. An organisation that adopts a vendor's taxonomy during this interval is not merely buying a product — it is adopting a description of its own control environment, and that description is what it will be defending later, to someone who did not write it.
A board-level version of the contract in this piece is therefore short and does not require any of the mechanism. For every control your organisation describes as preventing something, ask which of two things it does: does it sit in the path, so the thing cannot happen — or does it sit beside the path, so the thing is recorded when it does? Then ask what evidence supports the answer, and whether that evidence is a configuration file or a test that tried.
Two supervisors outside the United States have independently written down a related expectation — the ability to stop one system without stopping the estate, proposed in India's draft model-risk guidance and enumerated in the Central Bank of the UAE's guidance note. Both are draft or guidance-note status and neither binds any institution discussed here; they are noted because convergence between independently drafted instruments says something about the problem, and because a stopping control is precisely the claim that advisory mode cannot support.
What I would not claim
Three limits, and the first is the one that keeps me up.
The escape suite is only as good as the attacks in it. A passing run establishes that the attempts I thought of failed. It does not establish that no attempt succeeds, and the gap between those is exactly the gap that security work lives in. A conformance artefact from this system is a floor, not a ceiling, and anyone reading a passing escape suite as proof of containment has made a stronger inference than the artefact supports.
The second: an attested ruleset can be loaded and still be wrong. Attestation establishes that a specific ruleset is in force; it says nothing about whether that ruleset expresses the policy anybody intended. A deployment can be genuinely, verifiably mediated by a policy that permits the thing you cared about. The mode contract is about the strength of the enforcement path, not about the quality of the rules travelling down it, and conflating the two would reintroduce the exact category error this whole piece exists to prevent.
The third: this contract binds artefacts, not conversations. It stops a receipt from claiming containment it did not earn, and it stops a conformance report from being summarised dishonestly. It does not stop a person on a call from saying the word containment. I have not solved that and I am not sure it is solvable by construction — the closest available thing is publishing the contract so that a customer can hold a claim against it, which is part of why this piece exists.
What would falsify the design is specific and I would want to hear it: a deployment topology that is genuinely non-bypassable and fits none of the three qualifying forms, which would mean the taxonomy is too narrow and is denying a legitimate claim. That is a better failure than the alternative, and it is the one I would rather be corrected on.