Some things should take more than one person to open.

Like the little fire-alarm box — but it takes several keys at once.

“Break-glass” is the emergency door: a way to reach sealed raw evidence when there's a real reason — an insurance claim, an incident. But unlike a fire alarm any one person can smash, this door only opens when a quorum of trustees approve it together, and breaking it is loud and logged, never quiet.

First — where do the keys even come from?

A quorum only means something if you know whose keys count. So before anything is sealed, you choose your trustees — the people or roles you'd trust with a hard call — and each one brings their own key. Nobody hands out keys from on high: there's no master key, and we're not one of the holders.

# pin the trustees' PUBLIC keys and pick the threshold (2 of 3)
break_glass policy set --threshold 2 \\
  --trustee avery:<avery-ed25519-pubkey> \\
  --trustee bailey:<bailey-ed25519-pubkey> \\
  --trustee cameron:<cameron-ed25519-pubkey>

That's the whole enrollment. Only the public keys are ever registered; every trustee keeps their own secret key. Change your mind later and the policy update is itself signed into the record.

Try it: gather the trustees, or fail to force it open.

Now put the roster to work. It takes two of your three trustees to open this vault. Each “Approve” makes a genuine Ed25519 signature — with the same key you saw enrolled above — over the exact request, and the vault counts distinct valid signatures with the same rule the kernel uses. Try forcing it open with too few — you can't.

// count DISTINCT trustee keys carrying a valid approval
function countDistinct(approvals) {
  const keys = new Set();
  for (const a of approvals)
    if (a.valid) keys.add(a.keyHex);
  return keys.size;              // granted iff >= n
}

// re-derived at the unseal gate — never trusts a recorded outcome,
// so a device-key holder can't forge Granted with too few approvals
for approval in approvals {
    if !verify_approval(&t.public_key, request_hash, &approval.signature) { continue; }
    distinct.insert(t.public_key);   // dedup on the KEY
}
distinct.len() >= policy.n            // → Granted

Same rule, both sides. Deduping on the key means one trustee can't fill two slots by approving twice, and a stolen device key can't mint a grant with zero real approvals — the kernel re-derives the quorum from the signatures every time, exactly like the demo above.

Five rules that make single-person access impossible.

The quorum is the headline, but four more rules close the loopholes an attacker (or a well-meaning insider) would reach for.

How it actually works under the hood — no hand-waving.

• The seal — each sealed object is encrypted with ChaCha20-Poly1305 using a fresh random key, which is then wrapped under the device's master key. Tampering with a single header byte breaks the seal.
• Trustees & operator — trustees hold their own Ed25519 signing keys (which never leave them); an operator runs the request → approve → authorize → unseal flow but can't approve on anyone's behalf.
• The device's own snapshots go a step further: they're sealed to an operator's public key, so the Canary is write-only — it stores only the public half and cannot decrypt what it wrote. Opening happens off-device.