Threat-Model a Connected Health Dashboard With Consent-Boundary Tests

A health connector can be “read only” and still cross the wrong boundary. The dangerous request is not necessarily an attacker’s exploit; it can be a legitimate background refresh that continues after a person believes access ended. The security invariant should therefore be stronger than “the token was valid”: every read must be authorized by current, purpose-bound consent.

OpenAI’s July 23, 2026 announcement says Health in ChatGPT is rolling out to eligible logged-in US users age 18 or older on web and iOS. It describes connections for supported medical records and Apple Health, plus a dashboard that can cover labs, medications, activity, sleep, and other health information. OpenAI also states that connected data and relevant conversations are not used to train foundation models or target ads. These are attributed product statements, not an independent security assessment; see the primary announcement.

Draw the boundary before choosing controls

Use four assets: connection credentials, imported records, derived dashboard views, and audit evidence. Keep the consent service separate from import workers and conversational retrieval. A compact data-flow model is:

Person -> Consent UI -> Consent ledger

                         | current grant

Provider -> Import worker -> Record store -> Dashboard/chat context

                |              |                    |

                +---------- audit events -----------+

Revocation -------------> deny new reads + cleanup workflow

The key design decision is that a provider token alone never proves present consent. A worker must present the grant identifier, requested purpose, data classes, and operation time. The policy decision should be recorded without copying clinical content into the security log.

Reusable threat worksheet

Do not put diagnoses, medication names, lab values, or free text in those events. Identifiers should be scoped and access-controlled; “better auditing” is not permission to create a second sensitive database.

Consent-boundary regression cases

The following is an unexecuted test specification, deliberately independent of any vendor implementation:

- name: stale job after revoke

  given: grant g7 version 3 is revoked at t20

  when: worker with g7 version 2 requests records at t21

  then: [deny_read, emit_stale_grant, persist_no_payload]



- name: purpose expansion

  given: g8 permits dashboard and data_classes=[activity]

  when: chat_context requests sleep using g8

  then: [deny_read, emit_scope_mismatch]



- name: reconnect

  given: g9 was revoked and cleanup is pending

  when: connector callback reuses g9

  then: [reject_callback, require_new_consent]

Add two positive fixtures: an in-scope dashboard refresh while a grant is current, and a fresh grant created after a completed revocation. Positive cases prevent a deny-everything policy from appearing secure while making the product unusable.

The acceptance gate

For each test, inspect three planes. The control plane must deny stale or expanded authority. The data plane must persist no newly fetched payload after denial. The evidence plane must say which rule fired without containing health content. A release fails if any plane is unobservable.

This model does not establish how ChatGPT is implemented, whether a particular connector satisfies the cases, or any regulatory status. It does not validate encryption, deletion timing, provider behavior, or identity proofing. OpenAI says the experience is designed to support—not replace—medical care and is not for diagnosis or treatment. Security tests likewise cannot establish clinical safety. They only make authorization claims falsifiable.

A useful review question is precise: after consent changes, which queued, cached, exported, and derived objects can still move, and what evidence proves each one stopped?

AI assistance disclosure: This article was drafted with AI assistance and reviewed against the cited primary source.