Epic Break the Glass Feature
The epic break the glass feature lets staff open restricted records during an emergency. You enable it by assigning emergency role rules and reason prompts to user profiles. Healthcare and support teams use this workflow to block casual browsing of sensitive charts. Still, broad role permissions often give users full read and write power after entry. Once a user clears the prompt, the system trusts every action in that session. This creates risk when staff or engineers run tools against backend
Break-Glass Access Procedures + Feature Flags Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
The epic break the glass feature lets staff open restricted records during an emergency. You enable it by assigning emergency role rules and reason prompts to user profiles. Healthcare and support teams use this workflow to block casual browsing of sensitive charts. Still, broad role permissions often give users full read and write power after entry. Once a user clears the prompt, the system trusts every action in that session. This creates risk when staff or engineers run tools against backend databases.
How the epic break the glass feature works
In normal daily work, role rules limit which records a user can open. Staff only see charts for patients in their own care unit or work queue. When a sensitive chart appears, the app shows a warning screen to the user. This screen asks the user to type a clear reason and confirm their identity. The system saves this reason, the user name, and the time in a log. After the user submits the form, the app opens the restricted record right away. Compliance teams read these logs later to check if the emergency was real. They match each entry against work schedules and patient care notes from that day. If a user opens a chart without a valid task, the security team investigates.
What the native workflow solves and where gaps remain
This native workflow stops curious staff from casually reading VIP or coworker records. It forces people to pause and think before they open a restricted file. It also gives auditors a clear list of every emergency entry event. Yet this setup only checks who opens the door at the start. It does not check what commands or queries run inside the backend session. Database admins and support engineers also need emergency entry to fix broken systems. When they log in to a database, a simple text prompt cannot limit queries. An engineer with an admin role can run broad queries or export full tables. Standard audit logs only show that an emergency login took place at a certain time. They rarely rewrite sensitive fields like emails, phone numbers, card numbers, or national IDs. Teams end up reviewing stale logs days after a bad query already ran. Without real-time controls on queries, a single emergency session can expose thousands of rows.
Why backend teams need finer controls during emergencies
Clinical apps manage front-end screens well, but data teams work in raw databases. During an outage, engineers log in to production systems to fix corrupt data fast. If they use shared admin keys, audit logs cannot tell who ran which command. A proper emergency workflow for engineers must link every single query to a human. It should also ask a peer to approve high-risk commands before they run. Data masking should rewrite matched fields in results, such as emails and phone numbers. This lets engineers fix the bug while keeping sensitive numbers and IDs hidden. Teams get fast incident fixes and clean audit trails at the exact same time.
Break-Glass Access Procedures + Feature Flags Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What triggers a break the glass prompt in clinical software?
The prompt appears when a user tries to open a restricted chart. Common triggers include VIP flags, employee records, or patients outside the user's department.
Who reviews the logs after an emergency session ends?
Privacy officers and compliance teams review the event logs on a set schedule. They check that the typed reason matches a real care task or support ticket.
How is database emergency entry different from app screen prompts?
App prompts only gate a single patient chart on a front-end screen. Database access opens raw tables, so teams must control individual queries and mask fields.