Break-Glass Containment Governance provides a structured mechanism for AI agents (or human operators acting through agents) to exceed normal access boundaries during genuine emergencies — while preserving traceability, enforcing containment limits, and mandating fast revocation. The principle is that emergency access is not unrestricted access: even during a crisis, there are boundaries, there is recording, and there is a defined path back to normal operations. Break-glass access is the controlled exception to least-privilege governance. Without it, organisations face a dangerous choice: either maintain strict access controls and risk being unable to respond to emergencies, or pre-provision broad access "just in case" and permanently weaken their security posture. AG-306 eliminates this choice by providing emergency access that is structurally bounded, fully recorded, and automatically revoked.
Scenario A — Emergency Access Without Containment Causes Collateral Damage: A production database hosting 2.3 million customer records becomes corrupted during a failed migration. The incident response team needs an AI agent to perform emergency data recovery. The team grants the agent full administrative access to the production database cluster — all databases, all tables, all operations. The agent successfully recovers the corrupted database but, during its recovery operations, inadvertently modifies configuration settings on an adjacent database that supports the payment processing system. The payment system goes offline for 6 hours during peak trading. The collateral damage exceeds the original incident.
What went wrong: Emergency access was granted without containment boundaries. The agent received full administrative access to the entire database cluster when it needed access only to the corrupted database. No scope limitation restricted the agent's emergency access to the specific resources needed for the emergency. Consequence: 6-hour payment system outage, £2.1 million in failed transactions, regulatory notification for service disruption, additional incident response for the collateral damage.
Scenario B — Break-Glass Access Without Revocation Creates Persistent Backdoor: During a security incident, an AI agent is granted break-glass access to production firewall configurations to implement emergency blocking rules. The agent successfully mitigates the threat. The incident is resolved, but the break-glass access is never revoked — the revocation step is a manual process that depends on the incident commander remembering to execute it. Six weeks later, the agent's container is compromised through an unrelated vulnerability. The attacker discovers the still-active break-glass credentials and uses them to modify production firewall rules, opening a persistent backdoor. The breach persists for 4 months.
What went wrong: Break-glass access was not automatically revoked on incident resolution. The revocation depended on a manual human action that was forgotten in the post-incident fatigue. The persistent break-glass credential became a backdoor when the agent was later compromised. Consequence: 4-month persistent network compromise, data exfiltration through the backdoor, mandatory breach notification, estimated remediation cost £3.4 million.
Scenario C — Properly Contained Break-Glass Access Resolves Incident Without Collateral Impact: A critical API gateway serving 8 million daily requests fails. The incident response process grants an AI agent break-glass access to the API gateway configuration — scoped to only the gateway's configuration endpoints, with a 60-minute TTL, full session recording, and automatic revocation on task completion. The agent diagnoses and resolves the issue in 22 minutes. The break-glass credential is revoked 38 minutes before TTL expiry. The session recording captures every configuration change for post-incident review. No collateral systems are affected because the agent's access was scoped to only the gateway configuration.
What went right: Break-glass access was scoped to the specific resource needed, time-bounded, fully recorded, and automatically revoked. The agent could resolve the emergency without accessing any system beyond the scope of the incident.
Scope: This dimension applies to any AI agent deployment where the possibility exists that normal access controls may be insufficient to respond to a genuine emergency — a production outage, a security incident, a safety event, or any situation where rapid response requires access beyond the agent's routine permissions. The dimension applies to both agent-initiated break-glass requests (where the agent determines that emergency access is needed) and human-initiated break-glass grants (where a human operator grants emergency access to an agent). It applies regardless of the type of emergency access: database administration, network configuration, infrastructure control, cross-workspace access, or any other elevated privilege. Organisations with no production AI agents or no emergency response requirements for AI agents are excluded.
4.1. A conforming system MUST implement a break-glass mechanism that grants emergency access through a defined, auditable process — not through pre-provisioned standing privileges.
4.2. A conforming system MUST scope break-glass access to the minimum resources needed for the specific emergency, not grant unrestricted administrative access.
4.3. A conforming system MUST enforce a maximum TTL on break-glass access, after which access is automatically revoked regardless of whether the emergency has been resolved.
4.4. A conforming system MUST automatically revoke break-glass access when the emergency task is completed, even if the TTL has not expired.
4.5. A conforming system MUST record all actions taken during break-glass sessions at the highest available fidelity, per AG-305 (Privileged Session Recording Governance).
4.6. A conforming system SHOULD require multi-party authorisation for break-glass access grants — at minimum two authorised individuals (e.g., incident commander and security officer).
4.7. A conforming system SHOULD implement break-glass access tiers with escalating scope and escalating authorisation requirements (e.g., Tier 1: single-system access with one approver; Tier 2: multi-system access with two approvers; Tier 3: administrative access with three approvers and CISO notification).
4.8. A conforming system SHOULD mandate a post-incident review of every break-glass access event, including justification assessment, scope appropriateness, actions taken, and recommendations for preventing the need for future break-glass access.
4.9. A conforming system MAY implement automated break-glass triggers for predefined emergency scenarios (e.g., automated failover access on primary system failure) with pre-approved scope and TTL.
Every well-designed least-privilege system needs a controlled escape valve. The purpose of break-glass access is to ensure that security controls — which exist to protect the organisation under normal conditions — do not prevent the organisation from responding to emergencies that threaten greater harm than the controls are designed to prevent.
The challenge is designing the escape valve so that it does not undermine the system it escapes. Unrestricted emergency access is not an escape valve; it is a permanent hole in the security perimeter. The moment an organisation pre-provisions "emergency" administrative access for its AI agents, it has permanently weakened its security posture — those credentials exist whether or not an emergency occurs, and they are exploitable at any time.
AG-306 addresses this by making break-glass access structurally bounded: scoped to specific resources, time-limited with automatic expiry, fully recorded, and requiring explicit authorisation. The break-glass mechanism is not a bypass of governance — it is governance operating in emergency mode. The controls are relaxed (broader access than routine), but they are not absent (the access is still scoped, time-limited, recorded, and revocable).
The automatic revocation requirement is particularly critical for AI agent contexts. Human administrators who receive emergency access may remember (or be reminded) to release it when the emergency is resolved. AI agents have no such memory between tasks. Without automatic revocation, break-glass credentials persist in the agent's environment indefinitely, creating the exact standing privilege that just-in-time issuance (AG-304) is designed to eliminate.
Break-glass access for AI agents requires integration with both the secrets management infrastructure (AG-304) and the session recording infrastructure (AG-305).
Recommended patterns:
Anti-patterns to avoid:
Financial Services. Break-glass access for AI trading agents must comply with FCA expectations for incident management. The FCA expects that firms can demonstrate that emergency actions were proportionate, authorised, and reversible. Break-glass session recordings for trading system access must meet MiFID II record-keeping requirements.
Healthcare. HIPAA permits break-glass access to ePHI in emergencies (45 CFR §164.510(b)(4) — disclosures for emergency circumstances). However, the access must be documented, justified, and reported. AG-306 provides the structural framework for HIPAA-compliant break-glass access.
Government and Defence. Emergency access to classified systems requires additional safeguards. Break-glass access to systems above the agent's normal clearance level should require authorisation from the system's classification authority. All break-glass actions on classified systems must be reviewed within 24 hours of the event.
Basic Implementation — A break-glass procedure exists with documented authorisation requirements. Emergency access is granted through expedited provisioning of existing access control mechanisms. Session recording is activated for break-glass sessions. Revocation is a manual step in the incident resolution checklist. Limitations: revocation depends on human action; access scope may be broader than necessary due to coarse-grained provisioning; break-glass frequency is not tracked.
Intermediate Implementation — Break-glass access is integrated with the secrets broker, using emergency access templates with pre-defined scope and TTL. Multi-party authorisation is required. Automatic revocation on TTL expiry and task completion eliminates manual revocation dependency. Tiered escalation matches authorisation requirements to access scope. Post-incident review is mandatory for every break-glass event. Break-glass frequency metrics are tracked and reviewed quarterly.
Advanced Implementation — All intermediate capabilities plus: break-glass access has been verified through independent adversarial testing including scope escalation attempts, TTL bypass attacks, and credential persistence after revocation. Dead-man's switch prevents compromised agents from holding break-glass access. Automated break-glass triggers handle predefined emergency scenarios. Real-time security operations monitoring is active during all break-glass sessions. The organisation can demonstrate that break-glass access has never exceeded the defined scope, TTL, or authorisation requirements.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Break-Glass Scope Containment
Test 8.2: Automatic TTL Revocation
Test 8.3: Task-Completion Revocation
Test 8.4: Multi-Party Authorisation Enforcement
Test 8.5: Break-Glass Session Recording Completeness
Test 8.6: Dead-Man's Switch Enforcement
Test 8.7: Break-Glass Frequency Monitoring
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 14 (Human Oversight) | Supports compliance |
| FCA SYSC | 6.1.1R (Systems and Controls) | Direct requirement |
| HIPAA | 45 CFR §164.510(b)(4) (Emergency Disclosures) | Direct requirement |
| NIST SP 800-53 | AC-2(2) (Removal of Temporary/Emergency Accounts) | Direct requirement |
| ISO 27001 | A.5.18 (Access Rights — Emergency) | Direct requirement |
| DORA | Article 11 (Response and Recovery) | Supports compliance |
| PCI DSS | Requirement 7 (Restrict Access — Need to Know) | Supports compliance |
| SOX | Section 404 (Internal Controls) | Supports compliance |
AC-2(2) specifically requires the automatic removal of temporary and emergency accounts after a defined time period. AG-306's TTL-based automatic revocation directly implements this control. The control requires that the time period be defined in advance and that removal be automatic — not dependent on human action.
HIPAA permits disclosures of PHI in emergency circumstances, but the disclosure must be necessary for the emergency and must be documented. AG-306 structures this permission for AI agents: break-glass access to ePHI is permitted during emergencies, but the access is scoped, recorded, and reviewed. The post-incident review satisfies HIPAA's documentation requirements.
A.5.18 addresses the management of access rights, including provisions for emergency access. The control requires that emergency access is subject to the same governance principles as routine access — authorisation, documentation, and review — even if the process is expedited. AG-306 provides the structural framework for ISO 27001-compliant emergency access.
Article 11 requires financial entities to establish ICT response and recovery plans. Break-glass access is a component of the response plan — it provides the mechanism for emergency actions when normal access is insufficient. AG-306 ensures that the emergency access mechanism itself is governed, preventing the response from creating additional risk.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Dual risk — either inability to respond to emergencies (if break-glass mechanism fails) or uncontrolled emergency access (if break-glass lacks containment) |
Consequence chain: Break-glass governance failure creates two opposite damage paths. Path 1 (no break-glass mechanism): the organisation cannot respond to emergencies because its access controls prevent the actions needed to resolve the incident. The original incident escalates because no one (and no agent) can take the remediation actions. Path 2 (uncontained break-glass): emergency access is granted without scope constraints, time limits, or recording. The emergency actions exceed what is needed, causing collateral damage to systems not involved in the original incident. The unrestricted access persists after the emergency, creating a permanent security vulnerability. Both paths result in operational disruption, financial loss, and regulatory consequences. For financial services, uncontrolled emergency actions on trading systems may constitute market integrity violations. For healthcare, uncontained emergency access to ePHI may trigger HIPAA breach notification for access beyond the emergency scope. The balanced approach — structured break-glass with containment — eliminates both failure paths.
Cross-references: AG-304 (Just-in-Time Secrets Issuance Governance) provides the secrets broker infrastructure that AG-306 extends with break-glass issuance mode. AG-305 (Privileged Session Recording Governance) provides the recording infrastructure for break-glass sessions. AG-302 (Production Write Isolation Governance) provides production write controls that break-glass access may temporarily relax. AG-299 (Workspace Segmentation Governance) defines workspace boundaries that break-glass access may temporarily cross. AG-162 (Least-Agency Provisioning) establishes the baseline access model from which break-glass is the controlled exception. AG-034 (Cross-Domain Boundary Enforcement) defines the domain boundaries that break-glass may need to traverse during cross-domain incidents.