Two days ago we published an adversarial test of our own institutional mandate gate. Most of it held. One part did not, and we said so:
With the institutional mandate for the tenant fully revoked — the decision path went from allowed to blocked, reason MANDATE_REVOKED; the tool-execution path was unchanged: authorized, certificate minted, action executed — behaviour identical before and after.
It ended with a commitment: “The uncovered execution path is the next piece of work, and when it is covered this post will say so.”
This is that work. It is also an honest account of how far “we built it” is from “it is protecting you” — because those are not the same sentence, and a governance vendor that blurs them is doing the thing it sells against.
What was actually wrong
EVE has two paths that can authorise an action, and they were not equally governed.
The decision path answers “may this action happen?” and returns a signed decision record. It had been mandate-gated since the institutional mandate shipped: before any policy is evaluated, the mandate authorising that policy is resolved server-side, and if it is not current the action is refused.
The tool-execution path is what an AI agent actually goes through to call a tool. It resolves a delegation graph, checks the agent's record, and mints a single-use execution certificate bound to the exact tool, action, resource and parameters. It is a real control — it just answered a different question. It asked “does this agent have delegated authority for this action?” and never “does the institution still stand behind the machinery granting that delegation?”
The static reading was as blunt as the measurement: the word “mandate” did not appear anywhere in the agent authority evaluator, the gateway runtime, the execution certificate issuer, or the MCP enforcement module.
The fix, and where it sits
The gate now runs between the decision and the mint. That position is the whole point. Under enforcement, an invalid mandate refuses before the certificate is issued, so there is no certificate for anything downstream to verify, consume, or replay — and the connector is never called.
Three choices in it are worth stating plainly, because each one is a place where a weaker version would have been easier and would have looked identical from outside.
1. The mandate is resolved server-side, and a caller's claim is only ever an expectation
Nothing about the authority comes from the request. The gate reads the mandate from the durable governance record store and checks it against the agent-authority policy version that will actually execute — read from the evaluator module itself, not from the manifest's declared version. Using the caller's declared version would have let a caller satisfy the mandate by naming the version the mandate expects.
2. The commitment is inside the signature, not beside it
When the gate resolves a valid mandate, the resulting mandate_state_digest — a commitment to the mandate's derived governance state at that instant — is bound into the signed body of the execution certificate.
The tempting shortcut is to attach evidence alongside the certificate as an extra field. That produces something that looks the same in a screenshot and is worth nothing: an authority claim carried outside the signature can be added, altered, or quietly removed by anyone handling the certificate. Because the digest is bound, removing it changes the certificate's identity and its content hash, and verification fails two checks before anyone looks at the mandate at all.
3. A certificate that makes no claim must not be read as making a satisfied one
An ungated certificate does not carry an empty mandate field. It omits the field entirely, and the verifiers return no claim rather than a claim that passed. A relying party that requires institutional authority asks for it explicitly and is refused when it is absent.
This also keeps a promise to every existing deployment: because the field is bound only when present, a certificate minted without the gate is byte-for-byte identical to one minted before this work existed. We checked that rather than assuming it — the same certificate built against the currently deployed code and against this change produces the same bytes, the same certificate id and the same content hash.
The measurement, inverted
The original post's finding was a number: with the mandate revoked, the connector was still called once. The test that matters here is the same scenario with that number required to be zero. It runs over the real evaluator, the real signer and the real single-use consumption gate — not stubs.
| With the mandate REVOKED | Published, 13 Sep | Now |
|---|---|---|
| Decision path | blocked | blocked |
| Tool path — authorized | yes | refused |
| Tool path — certificate minted | yes | none |
| Downstream connector calls | 1 | 0 |
The test also pins something less obvious. When the mandate blocks, the underlying decision is still AUTHORIZED — the agent's delegated authority was never the problem. The refusal comes from the institution having withdrawn its authority, and the record says so. Collapsing those two into one “denied” would lose the only fact an operator actually needs to act on.
The part we are not going to dress up
Here is where a launch post would say “now protecting every agent action.” We are not going to, because it would not be true today, and the gap between shipping a control and switching it on is exactly the gap this series is about.
The tool-path mandate gate is merged and off. It has its own rollout ladder and its own enrolment list, both defaulting to off, and no tenant is enrolled in any deployment. Certificates on that path are byte-identical to what they were before. The capability exists; the path is not yet covered in practice.
There are three honest reasons it is off, and none of them is caution theatre.
The mandate it checks for does not exist yet. The gate resolves an institutional mandate for a policy set that names agent execution. That is a new scope. No organisation has issued one, because until this week there was nothing to issue it to. Arming enforcement before the mandates exist does not produce governance; it produces a uniform refusal with the reason MANDATE_NOT_FOUND, which teaches an operator nothing they did not already know.
Enrolment is deliberately not inherited. Eleven tenants are enrolled in mandate enforcement on the decision path. It would have been one line to reuse that list here, and the effect would have been to arm tool-path enforcement for eleven organisations who agreed to something else. A tenant has to be enrolled twice to be enforced twice. That is more work for us and less surprise for them, which is the correct trade in a control plane.
The gateway itself is still observing. Our agent gateway runs in shadow mode in production: it evaluates and records, and does not block. A mandate gate cannot be stricter than the path it sits in. Arming the mandate while the gateway observes would let us announce enforcement that could not refuse anything — the most flattering possible configuration, and a meaningless one.
So the accurate sentence is the narrow one: mandate validity is enforced on the CoreGuard decision path for enrolled tenants, and the agent tool-execution path now has a gate that is not yet enabled for anyone. When a tenant is enrolled and the gateway leaves shadow, we will say that, and it will be checkable rather than asserted.
What you can check without us
Both published verifiers — the Python SDK and the independent JavaScript one — now understand the conditional mandate binding, and three new frozen conformance vectors pin it across both languages: a mandate-bound certificate that must verify, one with a tampered digest that must not, and one with the digest stripped that must not. The eleven pre-existing vectors are unchanged, which is itself the evidence that ungated certificates were not disturbed.
The practical consequence: given a certificate, a published public key, and no network access, a third party can establish whether it carries an institutional-authority commitment, whether that commitment is intact, and whether it is absent. Three distinct answers, none of which requires asking us.
Why publish this one too
The first post was easy to publish in one respect: the gap was already real, and describing it cost nothing we had not already spent. This one is the harder half, because the temptation runs the other way — the work is done, the test is green, and the shortest true-sounding sentence is “the gap is closed.”
It is closed in code and open in deployment. A control you have built and a control that is protecting you are different claims, and the distance between them is measured in enrolment decisions, not commits. We would rather be the vendor that names that distance than the one whose customers discover it during diligence.