Who Can Break Glass When the Governance Plane Is Down?

An autonomous organization can fail in a particularly awkward way: the systems that decide who may act can be the systems that have stopped working. Identity, policy evaluation, approvals, automation and operational administration are increasingly assembled into one execution path. That arrangement produces strong ordinary controls. It also creates a lockout condition in which recovery itself cannot be authorized.

The usual answer—keep an all-powerful administrator account somewhere—solves the wrong problem. It replaces a dependency failure with standing, excessive authority. The more useful model is emergency authority as a first-class runtime state: deliberately pre-provisioned, dependency-isolated, narrowly bounded, observable and short-lived. Its only purpose is to restore the normal governance plane.

A governance plane can become its own single point of failure

A normal administrative action may rely on a chain of services: an identity provider authenticates the operator; a federation or synchronization path supplies the identity; a policy engine evaluates conditions; an approval workflow authorizes elevation; an automation pipeline applies the change; monitoring records the result. Any one of these components can be unavailable. More dangerously, a faulty policy, broken automation deployment or compromised control can be the cause of the incident.

This is not an argument against a governed execution path. It is an argument for recognizing its failure domain. If the only way to change a blocking policy is through the policy system that enforces it, the organization has designed a circular recovery procedure. If the only way to repair an identity integration is to authenticate through that integration, it has made identity recovery conditional on the failed identity path.

Cloud guidance makes the operational premise clear. AWS recommends configuring emergency access before a disruption, since the required roles may be impossible to create after normal access fails, and recommends testing the arrangement periodically. Microsoft recommends two or more emergency access accounts for Entra ID, with cloud-only identities rather than identities dependent on federation or on-premises synchronization. It also recommends authentication methods different from those used by ordinary administrators. These are not decorative exceptions. They are alternate paths around known dependency classes.

Do not build a universal bypass

Emergency access is often described as “break glass,” a phrase that can encourage an undisciplined design: one credential, unlimited access, no practical expiry and an audit performed later if anyone remembers. That is not resilience. It is a dormant security incident.

A better design is an emergency authority capsule. The term is an architectural synthesis, not a vendor feature. A capsule packages the exact authority needed to recover governance, together with the conditions under which that authority may be exercised. It is a special runtime state, not an identity that remains permanently above the organization’s rules.

The distinction matters. A permanent super-administrator is defined primarily by who holds it. A capsule is defined primarily by its operational boundary: what recovery operations it can perform, what systems it can reach, how long it lasts, what evidence it creates and what must happen after it expires. The organization should be able to explain its emergency path as a controlled transition back to normal governance—not as an alternate government.

The contents of an emergency authority capsule

The capsule should be designed before the incident, when the organization can still make careful decisions. Its contents should be explicit and reviewable.

• Eligible responders. Name the people, roles or, where appropriate, independent agent identities that may activate the capsule. Do not assume emergency authority must be human-only; the decisive requirement is independence from the affected execution chain. Google Cloud Privileged Access Manager documents support for agent identities.
• Independent authentication dependencies. The activation path should not share every identity provider, federation dependency, synchronization service, policy engine or approval chain with ordinary administration. Microsoft’s cloud-only emergency accounts and different authentication methods illustrate this principle.
• Narrow recovery operations. Define the operations required to restore the governance plane: for example, repairing an identity path, changing a blocking control, or restoring a failed foundation pipeline. Scope permissions to those operations and resources wherever the platform permits. Emergency access is not synonymous with unrestricted root authority.
• An incident reference and activation conditions. Activation should be associated with a declared incident and a concrete condition, such as a failed identity dependency or unavailable governance automation. This ties exceptional authority to an operational event rather than personal convenience.
• A fixed expiry. The authority must end automatically after a defined duration. Restoration can require multiple steps, but an emergency state should not silently become the new steady state.
• Immediate out-of-band alerts. Notify designated responders when activation occurs, including when an attempt fails. AWS recommends logging successful and failed emergency-access attempts and alerting on unexpected use.
• A reconciliation obligation. When normal operations resume, review actions taken, remove emergency access, rotate credentials where applicable, reconcile changes with standard policy and return to the ordinary operating model.

Independence is a dependency property, not a ceremonial label

An account called “emergency” is not an emergency path if it depends on the same unavailable machinery as all other accounts. Microsoft specifically advises excluding emergency accounts from blocking Conditional Access policies because those controls can render the accounts unusable during the very failure they are meant to address. The implication is architectural: enumerate the dependencies that stand between a responder and the recovery operation, then ensure the emergency route does not inherit the relevant failed dependency.

Independence does not mean eliminating all controls. It means choosing controls that can still operate in the assumed failure. A capsule can have restricted scope, strong preconfigured authentication, named eligible responders, fixed duration, alerting and comprehensive audit. What it must not require is a live approval or policy decision from the system whose outage or malfunction prompted the recovery.

This also clarifies the place of agents. An agent might participate in emergency recovery if its identity, authentication route and decision inputs are independent of the affected chain, and if its permitted operations are bounded. But an agent cannot be treated as an independent responder merely because it has a separate name. Shared model-serving, orchestration, policy or credential dependencies can collapse the apparent separation. Independence must be demonstrated as a system property.

Temporary elevation is useful, but it is not the same problem

Modern privileged-access systems show that elevated authority can be represented as a temporary grant with resource scope, duration, justification, optional approval and audit events. Google Cloud’s Privileged Access Manager is one example, including documented support for agent identities. This is a valuable pattern for ordinary high-risk work.

But ordinary just-in-time elevation commonly assumes that the governance system can receive a request, evaluate a policy and possibly collect approval. An emergency capsule begins from the opposite assumption: that this path may be unavailable or implicated in the incident. It therefore cannot be merely a high-priority request in the same queue. The capsule is the recovery mechanism for the queue, the policy evaluator or the identity route when one of them has failed.

Exercise the return path, not just the credential

A sealed credential or configured account is not evidence of recoverability. AWS recommends regular testing through incident-response and disaster-recovery exercises. Microsoft likewise recommends regular validation. Testing should establish more than whether someone can sign in. It should verify that a responder can activate the capsule under a realistic dependency failure, execute only the intended recovery operations, generate the expected alerts and records, restore normal governance, remove the emergency path from active use and reconcile the resulting changes.

Those exercises reveal the most important design defects: an emergency account still blocked by a conditional policy; an authentication factor that depends on an unavailable service; a recovery role that lacks one indispensable permission; a role broad enough to alter unrelated systems; alerts routed through the failed platform; or a team unable to determine who may activate the path. Each defect is easier to repair before the outage than inside it.

Recovery authority must lead back to governance

For autonomous organizations, this design changes the question from “Who has the master key?” to “What bounded authority can restore the conditions in which ordinary authority works again?” That framing preserves the purpose of governance under stress. It accepts that a control plane can fail without accepting that all controls must disappear.

The durable emergency design is not a secret administrator account. It is a predeclared recovery state with isolated dependencies, limited actions, an incident link, a short clock, immediate observation and mandatory reconciliation. Break glass should open a route back into the governed system. It should never become the system’s normal way of governing itself.