An engineer stared at the query, knowing the account should never be touched. Then the incident report flashed on his screen. It was time to break glass.
Break glass access procedures exist for these moments—rare, high-stakes events when someone needs direct access to sensitive data despite normal restrictions. Done right, they save the day. Done wrong, they open a security hole that can sink trust for years.
Row-level security (RLS) is where most systems fall apart under pressure. It’s easy to define policies that keep users in their lanes during normal operations. It’s much harder to design an emergency override that is both fast and safe. Break glass without discipline, and you’ve just created a superuser backdoor. Build it with care, and you can respond to crises without losing control.
Why Break Glass and Row-Level Security Must Work Together
Break glass access lets an authorized person bypass normal permissions in a controlled, auditable way. Row-level security ensures only the right rows of data are visible to a given user. Together, they form a tension: you need emergency flexibility without undermining the rules that protect data every other day of the year.
The obvious risk is overexposure. A badly implemented override often bypasses all RLS rules in bulk, granting full table reads when only a handful of rows are relevant. That’s a data leak disguised as a safety net.
The ideal design applies targeted escalation. Break glass should switch to a special mode, grant access to only the slice of data tied to the incident, and log every query. Security teams should be able to reconstruct exactly what was viewed, when, and by whom.
Designing a Secure Break Glass Procedure for RLS
- Strict Approval Flow – No single person should trigger break glass alone. A second approval or automated policy check should confirm the need.
- Scoped Permissions – Keep the RLS filter in place where possible, only expanding its reach to meet the situation.
- Immutable Audit Logs – Store break glass actions in write-once storage so records can’t be altered afterward.
- Time-Bound Sessions – Force break glass access to expire quickly, cutting the window for misuse.
- Continuous Review – Regularly test and refine the process, simulating emergencies to ensure clarity and speed.
Common Mistakes to Avoid
- Global Admin Defaults – Using a full-access account as the break glass user is the fastest way to blow past RLS safely.
- No Audit Trail – If you can’t review what was accessed, you’ve replaced intentional control with blind trust.
- Always-On Overrides – Break glass that isn’t time-bound tends to stay active far longer than intended.
Real-World Scenarios
Consider an outage tied to a single customer record. Without break glass, your engineers might spend hours chasing permissions, delaying resolution. With a well-scoped override, they can limit exposure to just that customer’s rows, investigate, resolve, and close the access in minutes.
Or imagine a legal request requiring rapid data production. Break glass combined with RLS ensures the legal team can act without leaking unrelated data to anyone else in the organization.
A secure break glass system is not about convenience—it’s about precision control under pressure. It proves that emergency access and strict data boundaries can coexist without compromise.
If you want to see break glass access procedures and row-level security working together without the usual complexity, check out hoop.dev. You can see it live in minutes, with policies, approvals, and audit logs ready to go.