Implement emergency authority override

Break-glass permission should be narrow, time-limited, independently auditable and separately initiated.

01 / The operating case

What changes in a real workflow?

A network outage triggers a request to disable a production firewall policy.

Trace the authority boundary
  1. 01Authority origin
  2. 02Task and grant
  3. 03Current decision
  4. 04Observed outcome

02 / Decision contract

What the executor must check

Require an accountable operator or precisely defined safety trigger, exact resource, short expiry, dual control where possible, independent logging and post-use review.

InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

An agent self-declares emergency mode and retains broad privileges after recovery.

Evidence to retain

Keep trigger, initiator, override grant, every action, expiry and review outcome.

04 / Canonical scope

Why this reference stands alone

Fail-closed behavior governs ordinary unavailable authority; this page owns explicit exceptional authority.

Illustrative implementation artifact

Override lifecycle

REQUESTED -> OPERATOR_VERIFIED -> ACTIVE
ACTIVE: exact resource + action + short expiry
ACTIVE -> EXPIRED or REVOKED
all uses -> INDEPENDENT_AUDIT -> POST_USE_REVIEW

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation