Break-Glass Procedure

The procedure is tied to a specific, highly privileged emergency identity or role, not a standard user account. This identity is dormant during normal operations and is only activated by the break-glass process. Its use is tightly controlled and often requires physical access or a hardware token.

• Just-in-Time Activation: The identity is provisioned with permissions only at the moment of the emergency.
• Non-Repudiation: All actions taken by this identity are cryptographically signed and logged to a tamper-proof audit trail, ensuring the operator cannot deny their actions.

To prevent a single rogue operator from abusing the procedure, a break-glass protocol typically requires concurrent authorization from multiple designated individuals. This is a technical enforcement of the 'two-person rule'.

• Quorum-Based Approval: A system-enforced requirement that a minimum number of authorized responders (e.g., 2 of 3) approve the activation before access is granted.
• Geographic Separation: In high-security environments, the approving parties may be required to be in different physical locations to mitigate coercion risks.

Every step of the break-glass procedure, from initial activation to the final resolution, generates a cryptographically verifiable, append-only log entry. This audit trail is stored in a separate, highly secure system that even the emergency operator cannot modify.

• Full Session Recording: All commands executed, tools called, and data accessed during the emergency session are captured.
• Real-Time Alerting: The activation of the procedure triggers immediate, high-priority alerts to a security operations center (SOC) and executive leadership, ensuring full organizational visibility.

The elevated privileges granted by a break-glass procedure are never permanent. They are strictly time-bound and scoped to the minimum necessary actions to resolve the specific incident.

• Automatic Expiration: The emergency session has a hard time limit (e.g., 15 minutes), after which all granted privileges are automatically and irrevocably revoked.
• Action Allowlisting: The emergency identity is not granted blanket 'root' access. It is restricted to a pre-defined Tool Access Control List that only permits specific termination, suspension, or rollback commands.

The core function is a guaranteed, non-overridable command to kill the agent process or suspend its decision-making loop. This command must bypass any agent-level safety checks or self-preservation logic.

• Kernel-Level Enforcement: The termination signal is sent at the operating system or hypervisor level (e.g., via a Seccomp Profile or MicroVM control plane), not through the agent's own API, which may be compromised.
• State Rollback: The procedure is often paired with an automated mechanism to revert the system to a last-known-good state, undoing any malicious or erroneous actions the agent performed before termination.

A break-glass procedure that exists only on paper is a liability. It must be treated like a fire drill and tested in a production-like environment on a regular schedule to ensure it works flawlessly under pressure.

• Chaos Engineering: Intentionally triggering the procedure in a controlled test to validate the entire kill chain, from authorization to agent termination and state recovery.
• Post-Mortem Analysis: After every test or real activation, a blameless post-mortem is conducted to identify friction points and improve the procedure's speed and reliability.

A fail-safe mechanism that automatically triggers a predefined safety action—such as agent termination or state rollback—if a continuous heartbeat signal from a human operator or monitoring system is lost. Unlike a break-glass procedure, which requires active human intervention, a dead man's switch is passive and automatic. In agentic systems, this is implemented via a periodic signed attestation from a supervisor process; if the attestation interval is missed, the sandbox is forcibly destroyed. This protects against scenarios where the human operator is incapacitated or the monitoring channel is severed.

A system design pattern that requires a human operator to review and approve a high-stakes action proposed by an autonomous agent before it is executed. In the context of break-glass procedures, HITL serves as the preventative gate that ideally catches anomalies before emergency termination is needed. The break-glass procedure is the reactive counterpart—invoked when HITL gates have been bypassed, overwhelmed, or proven insufficient. Effective HITL design requires minimizing automation bias, where operators become over-reliant on agent recommendations and fail to critically evaluate proposals.

A component in a system architecture that intercepts a request from an agent and enforces an authorization decision before allowing the action to be executed against a protected resource. A break-glass procedure is, architecturally, a specialized Policy Enforcement Point that overrides all standard policy logic with a single imperative: deny all further actions and terminate. The PEP must be positioned in the critical path between the agent's decision loop and its tool execution interface, ensuring no action can bypass the termination gate once the break-glass has been pulled.

A short-lived, disposable execution context for an agent that is created from a known-good image and completely destroyed after a single task. This design pattern complements break-glass procedures by ensuring that termination is clean and complete—there is no persistent state to recover or corrupt. When a break-glass is triggered, the entire environment is torn down, including all memory pages, temporary file systems, and network connections. A new, pristine environment is instantiated for any subsequent investigation or recovery, preventing state contamination from the compromised session.

A security protocol that grants an agent ephemeral, short-lived credentials to access a specific resource only at the moment it is needed, eliminating standing privileges. Break-glass procedures are the ultimate revocation mechanism in a JIT access architecture. When activated, the procedure does not just terminate the agent—it also immediately invalidates all outstanding credentials issued to that agent, regardless of their remaining time-to-live. This prevents a compromised agent that has already obtained credentials from continuing to operate through a separate execution path.