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

Abuse case	Prevent	Detect	Recover
Refresh races with revocation	serialize on grant version	log denied stale version	invalidate job and discard result
Sleep data used for an unrelated feature	purpose allowlist	purpose/data-class mismatch event	quarantine derived output
Support tooling exposes a record	default-deny support role	access receipt with case ID	revoke session and investigate scope
Deleted connection silently reconnects	require a new grant ID	reconnect event visible to person	disable connector and notify
Export includes hidden source fields	schema allowlist	export manifest counts by class	destroy export and rotate link

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.