Break-Glass Emergency Access

Governance gates high impact actions behind an approval quorum. That is the right default until the quorum itself cannot be reached, for example when an approver group has fewer active members than its threshold and the request would strand forever. Break-glass is the one sanctioned way out: a time-boxed session, armed by two different principals, that lets governed actions bypass the quorum for a bounded window while every bypass is counted and audited. It is deliberately not routed through the quorum it bypasses, because its whole purpose is to work when that quorum is unreachable.

When You Need It

A governed action is normally staged as an approval request that authorized approvers attest until the clause threshold is met. Governance refuses to open a request whose clause can never reach quorum, because that request would sit pending forever. When it detects an unsatisfiable clause (the approver group has fewer active members than the clause threshold), it fails the call with break_glass_required instead of stranding the request.

Code	Status	Meaning
break_glass_required	409	A governed action needs quorum, but the configured approval clause is unsatisfiable, so the request would never resolve. An owner must arm a break-glass session to proceed.

That error is the signal to arm break-glass. It is not a retryable failure: retrying the same call returns the same error until a session is armed for the workspace. Break-glass is workspace-scoped, so arming it affects only the workspace whose quorum is stuck.

The Two-Principal Arming Ceremony

Arming a session takes two different principals, so no single person can open the valve. The owner proposes the session, and a second, named staff member confirms it. Confirmation is what arms it.

1. Propose. An owner posts a session with a reason and a co_signer_staff_id naming a different, active staff member of the tenant. The session lands in the proposed state. The proposer must hold the literal owner role; naming yourself as the co-signer is rejected.
2. Confirm. The named co-signer confirms the proposed session. Only that co-signer can confirm it. On confirmation the session becomes active and its time-box starts. The co-signer sets the window at this step by passing duration_minutes (default 60, maximum 480).

Both endpoints require the break_glass.arm permission, which is held by owner and admin roles. On top of that, propose additionally requires the caller to be a literal owner, and confirm additionally requires the caller to be the named co-signer. See Authorization and RBAC for how a request is authorized and Policies and Quorum Governance for the quorum this session bypasses.

Operation	Who	Permission	Effect
POST /v1/break-glass	Owner	break_glass.arm plus a literal owner role	Proposes a session naming a different co-signer. State becomes proposed.
POST /v1/break-glass/{id}/confirm	The named co-signer	break_glass.arm	Arms the session and starts the time-box. State becomes active.
POST /v1/break-glass/{id}/revoke	Owner, proposer, or co-signer	break_glass.arm	Ends a proposed or active session early. State becomes revoked.
GET /v1/break-glass	Any authorized reader	break_glass.read	Lists the workspace's sessions, newest first.

The propose and confirm calls accept an idempotency key, so a retried arm does not open a second session. See Idempotency.

flowchart TD
  N[Governed action strands: break_glass_required] --> A[Owner proposes a session]
  A --> P[Proposed]
  P -- named co-signer confirms with a time-box --> V[Active, armed]
  P -- owner or participant revokes --> RV[Revoked, terminal]
  V -- time-box elapses --> EX[Expired, terminal]
  V -- owner or participant revokes --> RV
  V -- governed action runs --> BY[Bypass counted and audited]
  BY --> V

Time-Boxed and Auto-Expiring

A break-glass session is an emergency, not a standing posture, so it is bounded in time and cannot stay open. The co-signer sets the window when they confirm, in minutes, with a default of 60 and a hard ceiling of 480 (eight hours). An omitted value defaults to 60; a value below 1 or above 480 is rejected with a validation error rather than clamped.

Expiry is enforced two ways, so a lagging background job never extends the window:

• Fail-safe at read time. The security path that governance consults treats an active session whose expires_at is in the past as already inactive. Once the time-box elapses, no further bypass is granted, regardless of the recorded state.
• Durable sweep. A background job periodically flips over-due active rows to expired so the recorded state and the list view stay accurate. This is bookkeeping, not the control: the read-time check has already closed the window.

What Happens While Armed

While a session is active and unexpired, a governed action for that workspace that would otherwise be held for quorum proceeds instead. Each time that happens the session records the bypass:

• Counted. The session's bypass_count increments and last_bypass_at is set, so the durable record shows exactly how many governed actions ran under the valve and when the last one did.
• Tagged and audited. Every bypass emits an audit event naming the action that skipped its quorum and the resource it targeted, alongside the arm, confirm, and revoke events for the session itself. Break-glass leaves the loudest possible trail. See the Audit Log.

Ending a Session

A session ends in one of two terminal states.

• Revoked. An owner, the proposer, or the co-signer can revoke a proposed or active session early. Revoking an active session closes the bypass window immediately rather than waiting for the time-box.
• Expired. An active session that reaches its time-box expires on its own. No call is needed.

Both states are terminal: a revoked or expired session cannot be re-armed. If emergency access is still needed, an owner proposes a fresh session.

Reading Sessions

List the workspace's sessions to see current and past emergency access, newest first. Each session carries its state, the reason given, both principals, the ceremony timestamps, and the bypass tally.

Field	Meaning
state	One of proposed, active, expired, or revoked.
reason	Why emergency access was requested, given at propose time.
proposed_by_staff_id, co_signer_staff_id	The two principals in the ceremony.
proposed_at, armed_at, expires_at, revoked_at	The lifecycle timestamps. armed_at and expires_at are set at confirm; revoked_at is set on early revoke.
bypass_count, last_bypass_at	How many governed actions ran under the session and when the last one did.

Related

• Policies and Quorum Governance: the approval quorum break-glass bypasses and where break_glass_required is raised.
• Audit Log: how the arm, confirm, revoke, and per-action bypass events are recorded.
• Treasury: the N of M signer flow that is the most common quorum-gated action.
• Security Model: the overall control posture break-glass sits inside.