We Attacked Our Own Mandate Gate: What Held, and What Did Not

A signed AI decision proves the record was not altered. It does not prove anyone still had the authority to approve the rules that decision applied. We wrote about that gap and built a mechanism for it: an institutional mandate, resolved server-side at decision time and bound into the signed record.

Writing the mechanism is the easy part. The question that matters to anyone evaluating it is narrower and less flattering:

The required answer is no. This post is the test that tried to make the answer yes, and what it found — including the part that is not covered.

The test refused to use a convenient shortcut

The mechanism had been exercised against an in-memory store. Memory keeps live Python objects; it cannot reveal what a JSON column round-trip, a VARCHAR limit, row-level security or a real concurrent writer does to a digest-bound authority record. So the run used a disposable PostgreSQL database shaped like production:

• the governance table owned by one role, the runtime connecting as a different, least-privilege role;
• that runtime role not a superuser and without BYPASSRLS, so row-level security genuinely applies to it;
• RLS enabled and forced, with the fail-closed predicate that denies a read or a write when the tenant binding is missing, empty or mismatched.

One control is worth stating because it is the difference between a real test and a theatrical one. Pointing the same store at the owner role is refused outright — the code declines to run governance persistence on a connection that could bypass RLS, and says why. A harness that quietly accepted that connection would have proved nothing.

Against that database, the existing governance record suite passed 43 of 43 with nothing skipped.

What held

The scenario is the one from the original problem: a mandate authorises a lending policy, an agent takes a compliant action, the institution then changes its objective and supersedes the mandate, and the same otherwise-compliant action is attempted again.

The baseline action was allowed, with the signed record carrying the mandate identifier, the governing generation, the authorised policy pack version, the server-derived version that actually executed, the match between them, the authority owner, a state digest committing to the mandate's derived governance state at that instant, a trust resolution hash and the decision timestamp. The certificate verified.

Then the institution changed its mind, and every one of these was attempted:

• The same action, pinned to the superseded generation. Blocked, reason MANDATE_SUPERSEDED. No state digest and no trust hash were minted for the dead generation — the block record carries the absence, not a fabricated success value.
• The same action, unpinned. The server resolved the current generation on its own and did not fall back to the stale one.
• Revocation instead of supersession. Denied at exactly the revocation instant, one second after, five minutes after, and thirty days after. Pinning the generation that was active before the revocation did not resurrect it.
• A mandate with no expiry date. The concern here is subtle: if authority never expires, does explicitly withdrawing it still work? It does. The mandate under test was created with no expiry and was still killed by supersession. Absence of an expiry confers no immortality.
• A restart. A cold process, sharing nothing in memory with the one that superseded the mandate, produced the same denials. The behaviour comes from durable state, not from something cached in a running process.

Replaying the mandate's own genuine evidence

The most interesting attempt was the one that used no forgery at all. After the mandate was superseded, the caller replayed the superseded generation's real evidence — the genuine state digest and trust resolution hash from the earlier successful decision, its real authority owner and policy pack version, with valid set to true and status ACTIVE.

The result was blocked, MANDATE_SUPERSEDED. The signed record recorded valid: false, minted no state digest, and did not echo back a single caller-supplied value. A caller-side assertion of authority is read as an expectation the server then checks, never as the authority itself — so the worst a pin can do is cause a denial that would not otherwise have happened.

History stays true, and the machinery says so

A governance control that invalidates the past when authority changes is not useful; it is a different kind of dishonesty. So the test checked both directions against a signed as-of-time state proof, offline.

The original certificate verified against a proof built for its own decision time on all sixteen checks — the proof's content hash and signature, the generation chain and its linkage, the mandate being effective, not revoked, not retired, not superseded and current on reaffirmation at that instant, and the certificate's state digest being reproducible from the proof.

The same machinery was then asked to support the claim that the superseded generation was current at the later timestamp. It refused, and named the reasons: “certificate names version 1 but version 2 governed at that timestamp” and “the certificate's mandate_state_digest is not reproducible from this proof.”

What did not hold

EVE has a second, separate path. Alongside the decision API, an agent gateway governs tool calls and mints its own single-use execution authorization certificate. It is reasonable to assume a mandate gate covers both. It does not, and the test measured that rather than taking anyone's word for it.

With the institutional mandate for the tenant fully revoked, the same tool action was run again through the gateway in enforcing mode, over the real evaluator, signer and single-use consumption gate:

• 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.

The static reading agrees with the measurement: the word “mandate” does not appear at all in the agent authority evaluator, the gateway runtime, the execution certificate issuer or the MCP enforcement module. Those paths resolve a delegation graph and an agent record. They never ask whether the institution still stands behind the policy.

Two smaller findings worth naming

Scope is not matched against the action. The gate enforces whether a mandate is current, not whether a specific action falls inside the mandate’s stated scope. A successor mandate that narrowed its stated limit did not, by itself, block an action above that limit. The policy pack governs the action’s merits; the mandate governs whether that policy still has authority. Those are two different questions and only one of them is answered here.

Supersession is derived, not stamped. The store is append-only, so a predecessor generation is never rewritten when its successor arrives. Its superseded status is derived from position in the signed chain — the successor commits to the predecessor’s content hash. An auditor reading a raw row must derive that fact rather than read it off the row, which is the honest consequence of an append-only design.

Where this stands

Checking it yourself

The verification surface ships in the public SDK and needs no network access and no secret — a decision record, a mandate state proof for the decision time and the published public key are enough:

pip install eve-coreguard

from eve_coreguard.mandate import verify_mandate_authority, mandate_claim

claim = mandate_claim(decision_record)          # None if the record makes no mandate claim
result = verify_mandate_authority(claim, proof) # every check, offline
print(result.valid, result.to_dict())

A record that carries no mandate block makes no authority claim, and mandate_claim returns nothing for it. That is deliberate: the absence of a claim should never read as a satisfied one.

Why publish the failure

We would rather a prospective customer read the boundary here than discover it in a diligence call. A governance vendor that only publishes what held is asking to be trusted on the parts it did not mention. The uncovered execution path is the next piece of work, and when it is covered this post will say so.