What Is a Break the Glass Patient
To understand what is a break the glass patient, look at protected health records. A break the glass patient has locked charts that need an emergency override to read. Hospitals lock the records of famous people, staff members, and victims of crime. Care teams cannot open these charts during normal daily work. If a real crisis happens, a doctor can override the lock to save a life. The system logs this event right away and alerts the security team. Software teams use this exact same pattern for
Break-Glass Access Procedures: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To understand what is a break the glass patient, look at protected health records. A break the glass patient has locked charts that need an emergency override to read.
Hospitals lock the records of famous people, staff members, and victims of crime. Care teams cannot open these charts during normal daily work. If a real crisis happens, a doctor can override the lock to save a life. The system logs this event right away and alerts the security team. Software teams use this exact same pattern for production databases and cloud servers.
How what is a break the glass patient applies to software teams
In health apps, a flag marks a specific user row as restricted. When a nurse tries to read that chart, the app blocks the screen. It asks the nurse to type a clear reason for opening the file. Once the nurse submits the reason, the app opens the chart and sends an alert.
Platform engineers face the same problem when an app breaks at night. Normal database roles block engineers from reading live user tables during daily work. When a severe outage hits, the on-call engineer must bypass normal role limits. They trigger an emergency workflow to get higher permissions for a short window.
Today, AI agents and automated scripts also run checks on production systems. An AI triage bot might query a database to find the root cause of an error. If the bot hits a restricted table, it faces the same lock as a human. Teams must decide if bots can trigger overrides or if humans must step in.
Security tradeoffs of static roles and emergency overrides
Many teams build emergency workflows around shared admin accounts or broad cloud roles. An engineer claims an admin role when a server goes down. This setup gets the engineer into the database fast, but it creates big blind spots.
Static roles work at the database level, not the query level. Once an engineer logs in with an admin key, they hold full power. They can read every row, change tables, or drop data by mistake. The database log might show that the admin account logged in at midnight. Yet it often fails to record every single query and result set.
Break-Glass Access Procedures: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Shared passwords make audits even harder for the security team after an incident. If three engineers share one emergency key, you cannot tie a query to one person. Also, long-lived admin keys often stay active long after the crisis ends. An engineer might forget to log out, leaving the production system wide open.
Why row and field controls matter during an outage
When an engineer fixes a broken health app, they rarely need raw personal data. They need to see error codes, timestamps, and foreign keys in the database. Giving full table permissions exposes sensitive fields for no good reason.
Without field controls, a simple select query returns real emails and phone numbers. It can also return card numbers and national IDs in plain text. If an AI agent runs that query, those sensitive fields enter the model prompt. Data masking fixes this by rewriting matched fields in the query results right away. The engineer fixes the bug while private user details stay hidden.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why do hospitals mark someone as a break the glass patient?
Hospitals use this flag to stop curious staff from snooping on private charts. It protects VIPs, hospital workers, and patients with sensitive medical histories from unauthorized views.
How do software teams audit emergency database sessions?
Teams log who requested the override, the ticket number, and every command they ran. Security reviewers check these logs the next day to confirm the actions matched the outage.
Can AI agents use emergency override roles safely?
Giving an AI agent full admin permissions carries high risk during an incident. Teams should require a human to approve any risky command the agent wants to run.