Does the AI Have a Break-Glass Path to Patient Data? Reading an Old Security Question Against a New Reader

Chris Sowa · Founder, RedactSure
Published September 17, 2026 · Last updated September 26, 2026

No, and the absence is the design. Break-glass access is healthcare security’s established mechanism for emergency human access to records: a clinician in an emergency can break the glass, reach the chart, and account for it afterward. An AI model working under render-layer tokenization has no equivalent. There is no emergency mode, no override and no escalation in which the model receives real patient values, because real values resolve only at approved destinations at the moment of action, never to the model. A hospital CISO evaluating AI architectures can put the question directly to any vendor: under what circumstances does the model receive the real record? The strongest available answer is none. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

Break-glass procedures exist because the HIPAA Security Rule requires emergency access procedures at 45 CFR 164.312(a)(2)(ii): authorized people must be able to reach ePHI in an emergency, with the access logged and reviewed.
The mechanism was designed for human judgment under time pressure. Extending any version of it to an AI model inverts its logic: the model has no emergency, no judgment and no afterward in which to account for itself.
Most AI architectures have the inverse property by accident: the model receives real data in the normal path, so the question of an emergency path never arises. The meaningful comparison is which architectures can answer none to the question above.
Healthcare’s breach economics make the question material: $7.42 million average breach cost in IBM’s 2025 research, the highest of any industry for fourteen consecutive years.
The no-break-glass property is what makes the security argument arithmetic rather than behavioral: the model cannot leak, be tricked out of, or be compelled to produce what it never held.

What does break-glass mean, and why does healthcare have it?

The Security Rule’s technical safeguards include, at 45 CFR 164.312(a)(2)(ii), an addressable requirement titled emergency access procedure: establish procedures for obtaining necessary ePHI during an emergency. The industry’s implementation is the break-glass account: a tightly logged mechanism by which a clinician who lacks ordinary access to a record can reach it when a patient’s care demands it, with the event reviewed afterward.

The design encodes three assumptions worth making explicit. The accessor is a person, exercising professional judgment. The emergency is clinical, and minutes matter. And accountability is retrospective: break the glass first, explain to the review committee after. All three assumptions are reasonable for clinicians, which is why the mechanism has survived decades of audits.

None of the three holds for an AI model. A model has no judgment to exercise and no license to lose. A revenue-cycle or administrative agent has no clinical emergency; a denial appeal is never a code blue. And retrospective accountability is meaningless for a reader that can be manipulated by content it reads, the risk OWASP ranks first for LLM applications, because the explanation after the fact would be an explanation of the attacker’s instruction, not of a professional’s judgment.

Why does the question expose so much about AI architectures?

Ask a simple question of any AI system that touches patient records: under what circumstances does the model receive the real values?

For most architectures the honest answer is: in the normal path. A copilot reading the chart receives the chart. A computer-use agent receives the screen; Microsoft’s own documentation describes the model observing screenshots to decide its next action. A pipeline with a prompt filter receives the record and then inspects the output. In these designs there is no break-glass question because there is no glass. The model’s ordinary condition is the condition break-glass procedures were built to make exceptional, rare and reviewed.

The question worth asking is the inverse one, and it has a precise form: is there any mode, error state, escalation, debugging path or emergency in which the model receives real values? Vendors should be expected to answer it in writing. For the architecture this page describes, the answer is none. Tokenization happens at the render, before the model reads anything. Resolution happens at approved destinations, a payer portal, a payment system, at the moment a named person approves the action. The model is not in the resolution path at all. There is no glass to break on the model’s side, because there is nothing behind the glass for it.

How do the two mechanisms compare?

	Break-glass access (human, established)	Model data access under render-layer tokenization
Who reaches the data	A clinician with judgment and a license	The model never does
Normal condition	No access without role-based rights	Tokens only, every run
Emergency condition	Access granted, logged, reviewed after	Unchanged: tokens only; no emergency mode exists
Where real values appear	On the clinician’s screen, when the glass breaks	At approved destinations, on a named person’s approval; never in model context
Accountability	Retrospective review of the human’s decision	Prospective: the approval gate sits before the action, every time
Failure mode	Misused access, caught in review	An attack yields tokens; there is nothing to misuse

The table’s last row is the practical payoff. Break-glass procedures manage a risk by making it visible. The no-break-glass property removes the risk from the model’s side entirely: a prompt injection that fully succeeds, against a model with no path to real values, exfiltrates PATIENT_001 and MEMBER_001.

Human break-glass, meanwhile, continues to work exactly as it does today. Clinicians reach records through the systems of record under the hospital’s existing emergency access procedures. Nothing about tokenizing the model’s view touches the humans’ access, in emergencies or otherwise. Permissions do not change.

Why did break-glass work for twenty years?

It is worth pausing on why break-glass succeeded, because the reasons are a design checklist, and the checklist is what the AI version has to satisfy differently.

Break-glass worked because it was rare. The mechanism carried social weight: breaking the glass was an event, logged and reviewed, and clinicians knew it. Ordinary access ran through ordinary permissions, so the exceptional path stayed exceptional, and the review committee could actually read every event because there were few.

It worked because the accessor could explain themselves. The after-the-fact review is a conversation with a professional about a judgment call, and the professional’s license, training and duty gave the review something to hold onto. Sanctions were available and understood.

And it worked because the emergency was real and legible. A patient in front of a clinician is a circumstance a reviewer can verify. The mechanism’s legitimacy rested on the emergency being the kind of thing that shows up in a chart with a timestamp.

Run an AI model down the same checklist and every line fails at once. A model’s access is not rare; reading records would be its ordinary condition. A model cannot explain itself in the sense the review requires; it can generate an explanation, which is a different thing, and under prompt injection the explanation is the attacker’s. And a model has no emergencies; a queue of denial appeals at 2 a.m. is load, not urgency. The checklist does not say models are dangerous. It says the break-glass form of accountability, exceptional access justified afterward, has no purchase on this reader. Whatever governs a model must work prospectively, before the read, which is what tokenization at the render is: the decision about what the model may see, made and enforced ahead of every run, with the approval gate in front of every action.

Does the question generalize beyond healthcare?

Healthcare built the vocabulary, and the question travels without it. Every regulated industry has records whose extraordinary access is supposed to be exceptional, and every one of them can ask the same thing of an AI architecture.

A carrier can ask it about claim files: is there any mode in which the model receives the claimant’s identity and bank details? A district can ask it about student records, where the PowerSchool breach made the cost of a new records repository concrete. A bank can ask it about account data and KYC files. In each case the industry already distinguishes ordinary authorized access from exceptional access, and in each case the strongest architectural answer is the same: the model has no path, ordinary or exceptional, and the humans’ existing access, emergency procedures included, is untouched.

The question also sorts vendor claims efficiently, which is why it belongs in evaluation templates verbatim. Claims about model safety, alignment and filtering all describe behavior, and behavior has a distribution. No path is not a behavior. It is an architecture, and architectures can be inspected.

What should a CISO do with this question?

Put it in the evaluation template, verbatim: under what circumstances does the model receive real patient values? Ask every AI vendor, including RedactSure, and require the answer in writing with the architecture diagram that supports it.

Three answers are possible. In the normal path is the honest answer for most current tools, and it means the minimum-necessary analysis must justify the full screen. Only in emergencies or specific modes should prompt a follow-up: enumerate the modes, and explain who approves entry into them and what the log shows. None is the answer this architecture gives, and it converts the security review’s hardest question into a checkable property.

The same question generalizes beyond healthcare. A carrier can ask it about claim files, a district about student records, a bank about account data. The healthcare framing is simply the sharpest, because healthcare already built a whole discipline, the break-glass review, around the principle that extraordinary access to records must be exceptional, logged and justified. An architecture in which the model’s extraordinary access cannot occur is that principle, finished.

What should the written answer contain?

Evaluation questions produce value only when the answers are pinned down, so here is what a complete written answer to the break-glass question looks like, for this architecture or any other. Security teams can use the structure as the response template they require from vendors.

A scope statement: which deployments, versions and modes the answer covers, so the answer cannot quietly exclude the support tooling or the debugging build. The PowerSchool breach entered through support tooling, and AI vendors have support tooling too.

An enumeration: every path by which data reaches model context in the covered scope, including error handling, retries, human support sessions and evaluation runs. For the architecture described here the enumeration is short: the tokenized render stream, and nothing else. Length is informative; an enumeration that takes three pages is describing three pages of attack surface.

The resolution inventory: every point where real values rejoin the work, with the approving role and the destination for each. Here, approved destinations at the moment of a named person’s approved action, with the list of destinations per workflow in the exposure policy.

The exhaust statement: what logs, backups, telemetry and vendor-side analytics contain. Tokens end to end is the answer that keeps the monitoring stack from becoming a records system.

And a change clause: how the organization will learn if any of the above changes. An architecture claim without a notification commitment decays silently at the vendor’s release cadence.

A vendor that returns this document has treated the question as an engineering matter, which is the answer within the answer. A vendor that returns reassurance has answered a different question than the one asked, and the evaluation should record that too.

The insider variant of the same question

The break-glass frame also illuminates a quieter exposure that AI deployments create and rarely discuss: the people around the AI.

Every architecture that sends real records into model context creates new human viewers of those records. The engineers debugging the pipeline see what the model saw. The vendor’s support staff reproducing an issue see it. The reviewers spot-checking outputs see it. The monitoring system’s operators see whatever the logs hold. None of these people appear in the hospital’s role-based access matrix for the medical record, and each is a small, unexamined break-glass path: extraordinary access to records, without the logging and review the clinical version gets.

The no-break-glass architecture closes the human paths with the same move that closes the model’s. The supervisor watching a run sees the tokenized stream the agent sees. The logs hold tokens, so the SIEM operators and the auditors read a complete operational record with no patient in it. The vendor stores ciphertext it cannot decrypt, so its support and engineering staff have nothing to see. Debugging happens against tokens, which is sufficient, because the failure modes being debugged, a mismatched field, a broken workflow step, a policy gap, are visible in the token stream by design.

Authorized clinical and administrative access, meanwhile, is exactly what it was: the coder, the biller and the clinician see real records in the systems of record under existing permissions, existing emergency procedures included. The architecture adds no viewer to the record’s audience. That sentence, checkable against the design, is one a privacy officer can put in front of a board, and very few AI deployments can say it.

What the record shows

The AI has no break-glass path, and the absence is the design rather than a gap in it. Healthcare’s emergency access mechanism was built for clinicians: rare access, professional judgment, retrospective review, and it earned two decades of audit acceptance on those assumptions, none of which holds for a model. The equivalent discipline for the new reader runs prospectively: tokenization at the render decides what the model may see before every run, resolution happens at approved destinations on a named person’s approval, and no mode, error state or escalation hands the model real values. Human break-glass is untouched; the model’s ordinary condition is tokens and its exceptional condition does not exist. The question this article’s title asks belongs in every evaluation template verbatim, with the answer required in writing, because it sorts architectures cleanly: behavior has a distribution, and no path is not a behavior. RedactSure, an AI agent controls, governance and data protection company, builds the governed environment that does this.

Frequently asked questions

Does removing the model’s access slow down emergency care?

No. Clinical break-glass is untouched. Clinicians reach records through the systems of record under the hospital’s existing emergency access procedures, exactly as today. The mechanism described here governs what the model reads, and only that.

What if a workflow actually needs a real value in the model’s output?

The workflow needs the value in the destination, not in the model. The appeal must land with the right payer under the right member ID; the model drafts against MEMBER_001 and the real ID resolves at the portal on the approved submission. In revenue-cycle and administrative work, no step has yet required the model itself to hold the value.

Could an administrator override the tokenization for one run?

The exposure policy is confirmed field by field by a named person before a workflow runs, and changes to it are themselves setup decisions on the record. What does not exist is a runtime override that hands the model real values mid-run.

Is the audit log a second copy of the PHI?

No, and this is a direct consequence of the same property. The log records every screen and prompt as tokens, so the SIEM ingests a complete operational record that contains no patient values.

How does this interact with the minimum necessary standard?

Directly. The minimum necessary analysis asks what the model needed to see; the architecture’s answer is tokens plus the clinical or financial facts the task required, with the list confirmed in advance. The companion article How Can Staff Use AI on Patient Records Without the Model Ever Holding PHI? works through the full analysis.

Is “the AI has no break-glass path” a marketing line or a testable claim?

Testable. It reduces to an architectural fact: the model is not in the resolution path. A security team can verify it in the design review, and should require any vendor using similar language to support it the same way.

How Can Staff Use AI on Patient Records Without the Model Ever Holding PHI? · What Is Render-Layer Tokenization? · What Is Supervised Delegation? · What Should a Security Review of an AI Agent Vendor Cover? · On the RedactSure blog: AI Could Transform Healthcare Operations. PHI Is Why It Hasn’t.

Sources

Regulation

HIPAA Security Rule, technical safeguards, 45 CFR 164.312(a)(2)(ii), emergency access procedure. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312
U.S. Department of Health and Human Services, Minimum Necessary Requirement. https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html

Research and industry data

IBM, “Cost of a data breach: The healthcare industry.” https://www.ibm.com/think/insights/cost-of-a-data-breach-healthcare-industry
IBM, Cost of a Data Breach Report 2025. https://www.ibm.com/reports/data-breach

Standards and vendor documentation

OWASP, LLM01:2025 Prompt Injection, Top 10 for LLM Applications 2025. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
Microsoft Learn, “Automate web and desktop apps with computer use,” Microsoft Copilot Studio. https://learn.microsoft.com/en-us/microsoft-copilot-studio/computer-use

RedactSure documents

RedactSure, “Secure AI for Healthcare” (2026). https://redactsure.com/blog/secure-ai-for-healthcare/
Product behavior described on this page reflects RedactSure’s current design.

Bring your hardest questions.

A 25-minute AI Agent Security Review with the founders: threat model, token design, egress paths, audit schema. Or a 25-minute demo on a workflow like yours, with the data hidden from the AI and a named person approving what matters. We come with diagrams, not a pitch deck.

Book a security review Book a demo · Something else

About the author

Chris Sowa is a founder of RedactSure and a former CEO of AI companies; he started his first years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.