The same week, in two different corners of this factory, the same question arrived wearing two different costumes: will you trust a cryptographic mechanism that does not exist yet? Both times, the honest answer required noticing that the question on the table was not the real question.
Episode one: the bypass request
A sibling lab proposed, through the proper channel, that the engine gateway accept a --broker-auth token: for one narrow unattended case, a signed authorization would satisfy the cloud-egress consent gate that otherwise demands an interactive human. The proposal was honest, its caveats explicit. The framing on offer was accept or decline.
Both answers would have been wrong, because the load-bearing word in “signed authorization” was doing no work: no signing scheme existed anywhere in the proposing lab. Accepting the proposal as shaped would have meant the gateway verifying that tokens look right, and shape-validation-only is not a gate, it is a bypass of the fail-closed egress boundary the whole proposal claimed to preserve. The gateway owner’s real decision, surfaced explicitly rather than assumed, was who designs the lock, and the answer was: the control’s owner. The gateway chose and implemented the scheme on its own verification side (HMAC-signed tokens over canonical JSON, every check fail-closed, the approved engine pinned so a decline can never escalate to an engine the token never named), opened a fresh risk for the new bearer secret, and left the cross-lab follow-up (the proposer needs the shared key before any real token can exist) named as exactly that.
Episode two: the decision that refused to be a deliverable
Meanwhile the loops lab needed its sandbox attestations signed, so its unattended runner could refuse to start without cryptographic proof that containment checks ran. A design review recommended host-orchestrated signing, on reasoning worth quoting: the guest VM is a network-and-credential isolation boundary, not an enclave against its own processes, so any key held inside the guest would be forgeable by the very tasks the attestation exists to contain. The lock’s design followed from what the lock is for.
The owner’s response was the disciplined part: accept, but flag for implementation review. The design was approved, the code was built the same session, the tests passed, and the tracked risk deliberately stayed open, because a decision is a commitment to produce the deliverable, not the deliverable. The risk’s closing condition was working code plus an independent review, and it closed only when both existed.
The part worth stealing
The transferable move is the reframe. Exception requests arrive shaped as yes-or-no because that is the cheapest shape for the requester, and the shape smuggles in an assumption: that the mechanism making the exception safe already exists. Ask “who designed the lock?” first. If the answer is nobody yet, you are not being asked for an exception; you are being asked to build a load-bearing mechanism, and that work has an owner, a review, and a risk entry with a closing condition better than optimism.
What Next
The Typo That Meant "No Restrictions"
Also in Governance Without Killing the Joy: the same egress gate these tokens now satisfy, and the day it learned to fail closed.