Someone needs to investigate why an agent behaved incorrectly in production. They need to read the audit records, inspect the connection configuration, maybe query the data the agent touched. The convenient answer is to give the platform team standing production access.
That converts an occasional need into a permanent exposure. Standing privilege is available to an attacker who compromises any of those accounts, and it is available to an insider on any day, not just the day of an incident. It also degrades attribution: when everyone has access all the time, access itself carries no signal.
Break-glass inverts it. Nobody has standing privilege; anyone authorized can obtain it quickly, for a bounded period, with the elevation recorded.
What Makes It Work
Speed. This is the requirement that determines whether the whole scheme survives. If elevation takes twenty minutes and requires finding an approver, people will negotiate standing access instead — and they will be right to, because during an incident twenty minutes matters. Target under a minute for the common case, which usually means self-service activation with strong recording rather than pre-approval by a human.
Time bounds with automatic expiry. Access expires on its own — 30 minutes, an hour, four hours at most — and extension is a new activation. Never rely on manual revocation: people forget, and a break-glass grant that persists is standing access with extra ceremony.
Recorded justification. A reason field, free text, required. It will sometimes be terse and that is fine; its value is in the retrospective review and in the fact that writing something makes the action deliberate.
Notification, not approval, for the fast path. Activation notifies a channel where colleagues see it in real time. Peer visibility is a strong deterrent and costs no latency. Approval gates belong on the highest-privilege tiers only.
Scoped elevation. Not root. The narrowest grant that addresses the situation — read audit records, read one tenant's data, disable one connection. A break-glass path that grants everything defeats the least-privilege point.
Recorded actions during the window. Every action taken under elevated access is recorded and attributable to the person, not to a shared emergency account. Shared break-glass credentials destroy attribution and should not exist.
Tiering by Consequence
Not all elevation needs the same controls.
Read-only investigation. Reading audit records, configuration, and metrics. Self-service, immediate, notified, 1-hour expiry. This covers most real need and should have almost no friction.
Read customer data. Reading the actual content an agent processed — prompts, retrieved documents, tool arguments. Self-service with mandatory justification, immediate, notified, 30-minute expiry, and the access itself audited as a privacy-relevant event. Some regulatory contexts require notifying the affected customer, which should be automatic rather than remembered.
Configuration change. Modifying connections, scopes, or guardrails. Here the direction matters more than the tier: tightening should be immediate and ungated, loosening should require a second person. See below.
Destructive or financial. Deleting records, adjusting balances, releasing escrow. Two approvers, no self-approval, full recording. These should be rare enough that friction is acceptable.
Emergency Tightening Must Never Be Gated
This is the asymmetry that matters most and it is easy to get backwards.
During an incident, the containment action is a tightening: kill the agent, revoke the credential, disable the connection, drop the ceiling to zero. That action must be available immediately to anyone on call, with no approval, because the exposure is ongoing while you wait. A system that requires two approvers to stop a runaway agent has an availability problem in its security controls.
Emergency loosening is the opposite: it increases what agents can do, so it needs recording and review even under pressure. Where a blocked legitimate workflow must be unblocked immediately, allow it as a time-limited grant with automatic reversion and mandatory retrospective review — not as a permanent configuration change made at 2am and forgotten.
The practical shape: a kill switch and scope-reduction controls available to on-call without approval, and a separate, recorded, auto-expiring path for temporary loosening. See rogue AI agents and kill switches and policy as code and guardrail versioning.
Agents and Break-Glass
Two distinct questions arise once agents are in the picture.
Should an agent be able to use a break-glass path? Generally no. Break-glass depends on human judgment about whether the situation warrants elevation, and that judgment is exactly what an agent cannot be trusted to make under adversarial input — an injected instruction that triggers elevation is a privilege escalation. Where an agent genuinely needs occasional elevated access, the human who directs it should elevate, and the agent should act under that human's temporarily-broadened principal with dual attribution recorded.
Should agents be part of the incident response? Increasingly yes, for investigation — an agent that reads audit records and summarizes a timeline is useful and low-risk if read-only. Give it a narrow read-only connection to the audit store rather than break-glass privilege, so its access is standing but harmless rather than occasional but broad.
Retrospective Review
The activation record is only valuable if someone reads it.
Review every activation. Weekly is usually enough. Was it justified? Was the scope appropriate? Did the actions taken match the stated reason? This takes minutes and it is what keeps the justification field honest.
Watch the rate. A rising break-glass rate is a signal that the normal path is inadequate — people are elevating routinely because ordinary access does not cover a legitimate need. The fix is to widen the normal path for that specific need, not to make break-glass easier. Break-glass activated daily by the same person for the same reason is a permission gap, not an emergency.
Watch for pattern anomalies. Activation outside working hours by someone who never does, unusually long sessions, actions unrelated to the stated reason, or elevation immediately followed by data access at volume.
Feed findings back. Each review should either confirm the process works or produce a change — a wider standing grant, a narrower break-glass tier, a new self-service capability. A review that never changes anything stops being done.
See insider threat in the age of AI agents for the broader monitoring context.
Common questions
Does break-glass slow down incident response?
Done right it adds seconds, which is not material next to the time spent understanding the problem. Done wrong — approval chains, manual ticket creation, credential handoffs — it adds minutes to tens of minutes and people route around it. The design target is that break-glass is faster than looking up which colleague has standing access, which is not a high bar.
How is this different from just-in-time access?
Largely the same idea with different emphasis. Just-in-time access typically covers routine work that happens to need elevated permissions, with approval workflows tuned for predictable requests. Break-glass covers unpredictable urgent situations and prioritizes speed over pre-approval. Most organizations need both: JIT for scheduled maintenance and routine investigation, break-glass for incidents.
What if the break-glass system itself is down?
You need an out-of-band path, and it needs to be tested. A sealed credential in a physical safe, or a cloud-provider root path with hardware MFA held by two people. It should be genuinely hard to use, so it is not used casually, and it should be exercised once or twice a year — an untested emergency path is not an emergency path. Its use should trigger an immediate review regardless of outcome.
Should customers be notified when we access their data?
Depends on jurisdiction, contract, and what you access. Many enterprise agreements require notification or a documented process for customer-data access, and some regulatory regimes require it outright. Even where not required, an access log the customer can see is a strong trust signal and increasingly a procurement question. Build the notification hook into the elevation path so it happens automatically rather than depending on someone remembering.
How Praesidia approaches elevation
Praesidia separates the permissions to build agents, grant their authority, and configure guardrails and audit settings, so standing access can be narrow while investigation and containment remain available. Containment actions — killing an agent, revoking credentials, disabling a connection, dropping a ceiling — are available without an approval gate and take effect on in-flight work, because a tightening should never wait for a reviewer.
Sensitive changes in the loosening direction can require a second approver, changes are versioned with single-step rollback, and every action including audit-record access is written to the tamper-evident trail with the acting person, the justification, and the affected scope — which is what makes retrospective review possible. See security policies for passwords, sessions, and IP and the Praesidia documentation.