OpenAI connected ChatGPT to Epic patient records. Every control it names governs which humans see what, not what the model does.

OpenAI announced on 1 September that healthcare organisations can connect Epic environments to ChatGPT, bringing "authorized patient context from Epic into ChatGPT for Healthcare" alongside a plugin for public healthcare datasets including PubMed, DailyMed and CMS Coverage.

The announcement lists the controls that come with it: role-based access, single sign-on, audit logs, and a Business Associate Agreement supporting HIPAA-compliant workflows. Those are the right controls and they are the ones a hospital procurement function will ask about.

Every one of them governs which humans may see what. None of them governs which instructions the model will follow.

Three conditions, assembled inside the patient chart

The condition with nothing named against it

The lethal trifecta is the most useful available model for agent risk, and it is deliberately simple. An agent is dangerous when three things coincide: it can reach private data, it is exposed to content an attacker can influence, and it has a route to send something outward. Any two are ordinary. All three together is the shape behind every serious agent exfiltration to date.

This deployment assembles all three, openly and by design.

Private data is the point of the product: authorised patient context, inside the chat.

The outward route is the same plugin surface the context arrives through. The announcement notes that plugins for "Microsoft SharePoint, Google Drive, Salesforce, Slack, and other enterprise systems expand the approved business context available in ChatGPT while preserving existing permissions".

Untrusted content is the middle condition, and it is the one the announcement does not address. A clinical record contains text written by many people. A public dataset contains text written by anyone. A SharePoint site contains whatever was uploaded to it. The model reads all of it, and nothing in the announcement describes a control on what happens when some of that text is written to be read as an instruction.

That is not an accusation of negligence. OpenAI may well have mitigations it did not put in a launch post, and a launch post is not a threat model. It is an observation about what a healthcare buyer has been told: a complete answer on access control, and no answer on the failure mode that access control cannot reach.

The mechanism acquired a name the same week

On the day of that announcement, a preprint was submitted to arXiv describing exactly this class of failure in agent systems, with a vocabulary for it.

"What's in Your Agent's Context? Context Privilege Escalation Attacks against AI Agent Harness", arXiv:2609.01222, names two categories. The first is MessageRole Context Privilege Escalation, which "occurs when attacker-controlled content originating from a low-privileged context is incorporated into a higher-privileged message role". The second is Cross-Scope Context Privilege Escalation, which "occurs when attacker-controlled content persists beyond the context in which it was introduced".

The authors report assessing these against "12 real-world agent harnesses, including Claude Code and Codex", with consequences including "full agent compromise, remote code execution, denial of service, and manipulated tool or skill invocations".

Three caveats, because this is a preprint and should be handled as one. It has not been peer reviewed. No vendor response is attached and no CVE has been assigned. And nobody should write this up as "Claude Code has a remote code execution flaw", because that is not what a paper describing an architectural class of weakness across twelve harnesses is saying.

What makes it worth reading next to the healthcare announcement is the reframing. Prompt injection is usually discussed as a content problem, which invites content solutions: filters, classifiers, instructions telling the model to ignore instructions. This paper recasts it as a privilege problem in how a harness assembles context. Content from a low-trust source ends up in a high-trust position, and the trust boundary between message roles is not enforced.

If that framing holds, then a filter is the wrong shape of answer, and the right question for any agent deployment is which context sources can write into which message roles.

The 99.1% figure, and who produced it

The announcement carries an evaluation: "physicians evaluated responses across 27 clinical use cases, including pre-visit review, clinical timelines, medication review, and handoff summaries. Across 4,363 ratings, physicians rated 99.1% of responses safe across all use cases."

That is a precise-sounding number and it deserves its context, which is on the same page a few lines earlier.

What the evaluation figures are, and are not

The figure	How the announcement describes it	What it does not establish
99.1% of responses rated safe	Across 4,363 ratings by physicians, over 27 clinical use cases	Independence. The same physician network is one OpenAI “partners with… to help us define, measure, and improve health responses”
More than 93% rated “good” or better accuracy	A separate two-round evaluation across five connected data sources	A defined scale. “Good or better” is an ordinal label with no error taxonomy and no inter-rater reliability reported
More than 700,000 model responses reviewed	By hundreds of partnered physicians across 60 countries, 49 languages and 26 specialties	That the reviewing population is separate from the improving population. The announcement says the same network does both
Enterprise controls	Role-based access, single sign-on, audit logs, and a Business Associate Agreement	Any control on model behaviour. These govern human access, not model instruction-following

The circularity is the part worth naming, and it should be named fairly. OpenAI states that it partners with these physicians "to help us define, measure, and improve health responses in ChatGPT". Define, measure and improve. The same network that shapes the model's behaviour is the network that then grades it.

That is not fraud and it is not unusual. It is how most vendor evaluation works, and having any physician review at all puts OpenAI ahead of most products that reach a clinical setting. But it is the difference between a vendor's internal quality process and an independent trial, and "99.1% rated safe" reads like the second when it is the first.

What this is not

It is not a claim that the Epic integration has been attacked. Nothing has been reported and nothing is alleged here.

It is not a claim that OpenAI has no prompt-injection defences. It is a claim that the announcement describes none, which is a fact about the announcement.

And it is not an argument against putting AI near clinical records. The use cases named, pre-visit review, clinical timelines, medication review, handoff summaries, are exactly the administrative burden that makes clinicians miserable, and a tool that does them well is worth having.

The position

The security question raised by this deployment is not whether OpenAI has built it carefully. On the evidence of the announcement they have built the access-control half carefully, and the partner list suggests serious institutions have looked at it.

The question is that the industry keeps shipping the trifecta and describing the controls for two legs of it. Private data, untrusted content and an outward route, with an answer for the first and third and silence on the second, is now a recognisable pattern rather than an oversight, and it has appeared on this site three times in a fortnight in three different products.

A preprint gave the mechanism a name this week. The useful thing a buyer can do is stop asking whether a vendor has thought about prompt injection, and start asking which of their context sources can write into a privileged position.