The field has moved past "just prompt it better." The emerging consensus for agents in regulated work is sound: the model's output is probabilistic and will stay that way, so put something deterministic between the model and the consequence. A gate. Before each step, ask the gate; the gate answers ALLOW or DENY, with no model inside it, the same answer every time for the same state, and a signed record of the decision. Fail closed on anything ambiguous. Record the decision before the action runs.
All of that is correct, and it is a real improvement over an agent that narrates its own compliance. Nothing below argues against gates.
But "we gate every step" is becoming what "we sign every action" became: one phrase asked to carry several guarantees. Pressed by an auditor, it splits into three questions. Each has a cheap answer and an expensive one, and the headline does not always say which one you are buying.
Question one: what happens if nobody asks the gate?
A gate can be consultative or structural.
A consultative gate is a service your application calls before acting. The gate decides; your code honors the decision. If the answer is DENY, your code raises. If your code never calls (a new path someone added, a retry loop that skips the check, a tool the agent reaches directly), the action runs anyway, and the gate has no record that it was bypassed, because from its point of view nothing happened.
That is enforcement by integration discipline. Integration discipline is real and often good enough. But it lives in the application layer, so the guarantee is exactly as strong as the weakest code path that can reach the side effect.
A structural gate sits where the side effect is. The agent does not hold the credentials to act; it can only submit a proposal to the thing that does. The gate is the only thing able to press the button, so the agent has no path around it, and a skipped call has no effect.
The test: if I deleted the call to the gate, would the action still happen? If yes, you have a consultative gate. Say so, and put your effort into proving that every path calls it.
Question two: does the receipt prove a permission or an execution?
A gate that records its decision before the action is doing something valuable: it creates evidence that the step was authorized at that moment, under that state, and that the authorization cannot be quietly rewritten later.
But read the receipt closely. It says ALLOW, step 4, sequence 812, at 14:02:11. It says nothing about whether the step ran, what it did, whether it succeeded, or whether the thing that ran was the thing that was authorized. A permission and an execution are two different events, and the signature covers the first.
This is a different claim from the three a signed receipt makes. Integrity can be perfect (the record intact) and so can trustlessness (you hold the key yourself); the receipt is still a true statement about a permission, and the veracity of the action stays open. An auditor reconstructing an incident needs both halves: was it allowed, and what actually happened, linked so neither can drift from the other.
Linking is necessary and not sufficient. A result record can sit in the same chain as the permission and still be something the caller reported. The test: for a given ALLOW, can you show me the execution record it produced, and who wrote that record: the system that carried out the step, or the application telling the gate that it did?
Question three: did the gate check the state, or a report of the state?
Every gate evaluates some precondition. "Identity verification must complete before credit scoring." The question is what the gate looks at to decide that identity verification completed.
If the gate tracks sequence (which steps have been reported done, in which order), then it knows that someone reported the verification step. It does not know that verification passed. The failure the gate was brought in to prevent, a model inferring that a check happened without running it, moves up one layer: now the application reports the check happened, and the gate signs a perfectly ordered sequence of claims.
If the gate evaluates the precondition against the system's own state (the verification record the system itself committed), then "verification complete" is a fact the gate reads from the system's own records. That is only possible if the gate has access to the state, which usually means the gate and the state live in the same place.
The test: if the application reports a step as complete when it wasn't, does the gate notice? If the honest answer is no, the gate enforces order, not truth.
The honest limits
Each expensive answer has a real cost, and the cheap answers have real virtues.
Structural costs portability. A consultative gate works with any framework and any agent; you add a call and you're done. A structural gate requires that actions flow through the thing that holds authority: a runtime. That is a heavier commitment, and for low-consequence steps it may not be worth it.
Structural binds the agent, and two paths stay outside it. Whoever holds the database credentials can still write around the runtime, and any outbound tool the agent is allowed to call is only as gated as that tool's own check. Name both.
Linking permission to execution requires owning execution. You can only bind an authorization to the event it produced if the same system commits both. A gate that sits beside the system can record permissions exquisitely and still never see what happened next.
Checking real state requires having real state. And even then, the gate can only check what the system knows. A precondition that depends on an external system still depends on that system's report. Deriving from state narrows the gap, and at every external boundary some of it remains. Say where the boundaries are.
A structural gate enforces what was declared. If the policy is wrong, the gate enforces the wrong policy, deterministically and with a signed record. The error is then visible and attributable, which is useful, and the policy still has to be right.
The stakes
A consultative, sequence-tracking gate with pre-action receipts is far better than an agent writing its own log, and for many workloads it is enough.
The problem arises only when the three are spoken as one. "Deterministic, gated, cryptographically receipted" sounds like a single guarantee. An auditor hears three claims and asks about each: could it have been skipped, did it actually happen, and was the precondition really true? A gate that answers all three with "it's gated" loses the room on the first follow-up. A gate that answers each separately (consultative, so here is how we prove every path calls it; the receipt covers the authorization, and here is who records the execution; order is enforced, and here is which preconditions are read from state) sounds more modest for one sentence and has an answer for every follow-up.
This sharpens the enforcement layer of a broader line: communication and proposal may be probabilistic, but authority, consequence, and the record of both must be deterministic, declared, and verifiable. The proof-layer version of this argument is in A signed receipt is three claims, not one; the enforcement case is in The agent proposes; the runtime presses the button.
Nicolás Moreno builds Zarel: governed AI operations, where the AI proposes and the contract decides.