06-SECURITY-PRIVACY-THREAT-MODEL.md

Security, privacy, and threat model

Status: pre-implementation threat model
Owner: security/privacy lead
Review cadence: before pilot, before v1, annually, after any architecture or incident change, and before any change in publication posture or repository visibility

1. Security objective

ContextSafe must not turn a safety test for trans and nonbinary people into a new source of patient exposure, credentials, or sensitive organizational findings. V1's strongest control is architectural: synthetic records, non-production execution, local processing, minimal transfer, and no hosted raw-evidence service.

“No PHI” is a product boundary and operating discipline, not a magical property of synthetic data. Misconfigured staging environments and exports can contain real patient data. Detection is layered and fallible.

The inversion

One property of this product shapes every section below, so it is stated first rather than derived later: a tool that reports where transgender and nonbinary identity data is lost is, in the same breath, reporting where it is retained. A finding that says “the value was absent at the laboratory” also says “the value was present in the EHR at version X, in this field, at this boundary.” A pack that tells an evaluator where to look is a list of where to look. That is the artifact's purpose and also its dual use, and no control removes it.

Two consequences follow. First, the controls in section 6 keep patient data out of the workspace; they say nothing about what the findings themselves disclose once they exist, so the findings need their own controls — T-16 below and the publication policy. Second, the safest form of a finding is the least specific one that is still true and actionable, which is why receipts carry hashes, statuses, and counts rather than values, and why that choice is a safety control and not only a privacy one.

2. Assets

• A-SEC-01: customer staging credentials and network details.
• A-SEC-02: customer system map, versions, and vulnerabilities/findings.
• A-SEC-03: synthetic raw evidence and normalized observations.
• A-SEC-04: pack, clinical oracle, mappings, and approval signatures.
• A-SEC-05: receipts, reviewer identities, and dispositions.
• A-SEC-06: customer and trans-community reviewer relationships.
• A-SEC-07: signing keys and release artifacts.
• A-SEC-08: trust in the product's bounded claims.
• A-SEC-09: published project material — documentation, schemas, packs, assertions, fixtures, talks, and repository history. It is an asset because the project's credibility depends on it being open, and a liability because of the inversion in section 1: some of it describes where identity data lives.
• A-SEC-10: the public association between a named contributor or reviewer and this subject matter, which publication creates and cannot later remove.

3. Trust boundaries

TB-01 incoming customer evidence; TB-02 optional staging FHIR connection; TB-03 mapping profiles; TB-04 pack update; TB-05 local workspace and OS account; TB-06 reviewer identity/signing; TB-07 receipt transfer; TB-08 dependency/build chain; TB-09 support channel; TB-10 publication.

TB-01 through TB-09 are operational: each is a place where data crosses into or out of a controlled process. TB-10 is different in kind. It is the boundary between everything this project knows and everyone, forever, and it is crossed deliberately rather than by attack. Its distinguishing property is irreversibility: a repository can be made private again, but it cannot be made unread. Everything crossing TB-10 is governed by the publication policy, which classifies material as method, locator, or instance and assigns approval accordingly.

4. Threat actors and misuse

• Accidental operator exporting a real patient.
• Malicious insider tampering with evidence or a disposition.
• External attacker stealing credentials or customer findings.
• Compromised dependency or release artifact.
• Vendor or customer using a receipt as marketing certification.
• Actor using customer/reviewer relationships to identify trans people or organizations.
• Overconfident clinician treating a synthetic oracle as patient-specific guidance.
• Founder overriding governance to close a sale.
• Reader of published project material seeking to locate trans and nonbinary people, or to pressure the organizations serving them. This actor needs no access, breaks nothing, and violates no license. They read the documentation, the pack, and the fault library the way an intended user does, and they take from it the retention map that the loss map implies. They are the only actor here whose capability grows every time the project does good work in public.
• Party using lawful process — subpoena, civil discovery, state investigative demand, or public-records request against a public-institution customer — to obtain receipts, customer identities, reviewer identities, or pack content. Not an attacker; the control is having little to produce, not resisting the request.
• Maintainer publishing under time pressure, shipping a talk, post, case study, or pack artifact without the review the material's class requires. This is the realistic form of the publication failure, and it is why section 6 of the publication policy blocks a class of material rather than trusting a habit.

5. STRIDE threats and controls

ID	Category	Threat	Prevent/detect/respond	Residual
T-01	Spoofing	Reviewer identity is forged	root-signed purpose/role trust manifest, plan-enrolled customer keys, role roster, MFA for code host, hardware-backed signing preferred, detached signatures, callback for critical approvals	compromised endpoint or trust root
T-02	Spoofing	Synthetic record collides with a real person	explicit namespace, local test flag, reserved contacts, customer suppression, dry run, cleanup	vendor behavior outside test
T-03	Tampering	Evidence or result changed after review	content hashes, append-only review events, signed deterministic receipt, verification command	signer compromise
T-04	Tampering	Mapping hides or changes unsupported value	mapping fixtures, code review, approval, ambiguity retention, mapping hash, absolute GI/RSG-to-SPCU substitution prohibition	subtle semantic error
T-05	Repudiation	Customer denies release disposition	named signed review, dual customer-clinical/ContextSafe-clinical signatures for accepted clinical residual risk, timestamps, receipt hash, customer release system remains authoritative	key custody disputes
T-06	Information disclosure	Real PHI included in export	no-PHI contract, training, field allowlist, namespace gate, free-text ban, canary scanner, pre-persistence fail, incident drill	heuristic miss
T-07	Information disclosure	Logs expose names, pronouns, tokens, paths	structured allowlisted logs, redaction tests, no raw values, local-only default	platform crash dump
T-08	Information disclosure	Customer/reviewer list exposes trans affiliation	confidential CRM, minimum access, no public attribution by default, no tracking	legal compulsion/insider
T-09	Denial of service	Malformed or huge input exhausts runner	file/count/field limits, bounded streaming parser, timeouts, no entity expansion, reject without ContextSafe copy	local resource exhaustion
T-10	Elevation	Parser or template executes content	treat input as data, no eval, sandbox recommendations, output escaping, dependency scanning	zero-day
T-11	Supply chain	Compromised package/release	lockfile, hashes, SBOM, signed releases, pinned CI, SAST/SCA, reproducible build target	upstream compromise
T-12	Integrity	Expired oracle still yields pass	validity gate, pack pin, revocation list, receipt warnings	disconnected customer misses recall
T-13	Safety misuse	Receipt marketed as certification	claims policy, contract restriction, watermark, public correction/withdrawal right	screenshot stripped of context
T-14	Network	Read-only adapter queries real patients	staging host allowlist, exact synthetic identifier query, least-scope credential, result cap, kill switch	endpoint misroutes
T-15	Privacy	Support ticket receives raw evidence	portal warning, attachment block where possible, staff script, secure exception path, deletion	user bypass
T-16	Information disclosure (TB-10)	Published material functions as a retention map: a pack, assertion predicate, mapping profile, or worked example tells a hostile reader which fields at which boundaries carry trans identity data	publication policy three-class rule; locator material not published without recorded approval; named approvers with a community co-chair veto; no receipt, customer, vendor, or version ever published; no small-population aggregates; re-review of already-public material before a governed pack lands	irreducible: the concepts are documented in public standards, so withholding buys curation friction and not secrecy. Publication cannot be undone
T-17	Privacy (TB-10)	Public participation exposes a contributor or reviewer as associated with trans-health work	attribution choice offered before first contribution, pseudonymous contribution accepted, no roster or acknowledgement without individual written consent, consent revocable going forward	authorship in a public history is permanent; revocation cannot reach forks, mirrors, or archives
T-18	Information disclosure (TB-10)	Lawful process compels production of receipts, customer or reviewer identities, or pack content	minimization by design — hashes not values, evidence stays customer-local, no hosted findings store, small confidential roster; counsel-owned response; contract terms set the customer's own posture before the first paid pilot	no technical control defeats valid legal process; the only real control is having little to produce

6. PHI boundary controls

Before engagement

• Contract states prohibited data and authorized evidence fields.
• Customer privacy owner signs the data-flow diagram.
• Technical owner demonstrates synthetic patient policy and downstream suppression.
• No BAA is assumed to solve poor scope; counsel determines status.

Before persistence

• Accept only approved file types and size limits.
• Require plan ID, case ID, synthetic identifier system, and namespace match.
• Reject unapproved identifiers and free-text-bearing resources/segments.
• Check email domain, phone range, names, MRN pattern, account numbers, dates, URLs, and known canaries.
• Reject any unexpected FHIR resource type or HL7 segment/field.
• During the complete first pass, store nothing on rejection except at most a non-sensitive error class; do not create a workspace or retain source hash/prefix, filename/path, byte count, or rejected bytes.

After acceptance

• Raw evidence stays customer-local.
• Use least-privilege filesystem permissions and full-disk encryption.
• Logs contain IDs and statuses only.
• HTML shows only claim-minimal fields.
• Cleanup command enumerates all retained artifacts.

The scanner must say “boundary check passed,” not “contains no PHI.” Human and system controls remain necessary.

Implementation note (2026-07-13): the first enabled boundary profile is a strict, code-only canonical JSON envelope. It rejects unknown/prohibited fields, non-plan case/checkpoint/namespace values, arbitrary prose, leading/trailing whitespace, Unicode control/format characters, configured canaries, and bounded patterns for email, SSN-like values, phone numbers, URLs, dates, MRN/account labels, and long numeric identifiers. These patterns can miss identifiers and can produce false positives. The result therefore says boundary-check-is-not-proof-of-no-phi; no approved operating process may treat scanner success as privacy authorization. Only after that complete first pass succeeds may the internal-test primitive write a private second-pass staging file. A concurrent source mutation fails before promotion or indexing. Staging cleanup is attempted, but filesystem denial can leave partial second-pass bytes for permitted exclusive recovery or explicit operator remediation; that residual is an incident condition, not a successful boundary result.

7. Data minimization by format

• FHIR: allowlist Patient identifiers/name/pronouns/GI/RSG/SPCU extensions as required, ServiceRequest, relevant Observation, DiagnosticReport, and Encounter references. Any narrative, contained resource, unrelated field/resource, or unapproved free text rejects the entire source before persistence. Never strip prohibited content and accept the remainder.
• HL7 v2: allowlist exact PID/GSP/OBX/OBR fields per profile. Reject NTE and other free-text fields.
• LIS: constrained columns only: synthetic case/order/accession tokens, analyte code, value, unit, range fields, flag, status, timestamps.
• UI observation: structured observer form; no screenshot by default.

An adapter performs only the bounded streaming parse needed to enforce format, namespace, and field allowlists against a caller-owned read-only source. No ContextSafe copy, temporary file, index row, or content-bearing log exists until the entire first-pass boundary check succeeds.

8. Identity, access, and secrets

V1 local operation uses the customer's OS identity and filesystem. ContextSafe does not implement user accounts.

• Staging credentials are read-only, short-lived, and kept in OS keychain or process environment.
• Never accept credentials in YAML, CLI arguments, logs, receipt, or support messages.
• Signing keys are separate from code-signing and customer credentials.
• The verifier pins the offline trust-root fingerprint and consumes its signed key/purpose/role manifest plus monotonic revocations; unknown, wrong-purpose, expired, revoked, stale-trust, or insufficient-threshold states do not verify as valid.
• Pack release requires role-distinct clinical-safety, community-co-chair, and technical-release-owner signatures created and checked through pack sign/verify; the technical signature attests build integrity and cannot replace either semantic approval. An executable plan requires customer-sponsor and ContextSafe-delivery-owner signatures through plan sign/verify. A mapping requires the plan-enrolled customer technical owner plus a distinct ContextSafe interoperability reviewer. Each review requires a signer authorized for its exact role; accepted clinical residual risk requires both the customer clinical owner and ContextSafe clinical chair, with neither substituting for the other. A pilot receipt requires a plan-enrolled customer release owner and a distinct ContextSafe clinical/service approver. Laboratory approval remains separately required for laboratory assertions.
• Key enrollment, rotation overlap, verification-time validity, untrusted claimed signing time, offline revocation freshness, root/key compromise, and verifier replacement follow the architecture trust model and exercised runbook.
• Repository administrators cannot bypass protected release or safety gates.
• Offboarding revokes code, CRM, storage, and signing access within one business day.

9. Secure development and release

• Threat model and misuse cases reviewed at design changes.
• Strict typing and parser property tests.
• 90% line and 100% safety-property branch coverage target.
• Secret, SAST, dependency, license, and SBOM gates.
• Pinned CI actions and least-privilege tokens.
• Signed tags and artifacts; public checksums.
• Every artifact crossing TB-10 is classified and approved under the publication policy before it is released, including documentation and examples shipped alongside code.
• No external pilot or release with an open critical/high vulnerability. A demonstrably unaffected report is formally reclassified with evidence and independent security-lead approval; critical/high status itself is never waived.
• Coordinated vulnerability disclosure policy before pilot.

10. Privacy impact

People affected

Trans and nonbinary people are the intended beneficiaries but are not data subjects in the synthetic pack. Reviewers, customer staff, and organizational contacts are data subjects in operations.

Risks

• Reviewer identity could reveal gender identity or advocacy involvement.
• Organization participation could reveal unremediated safety defects.
• Test scenarios could normalize excessive collection of sensitive fields.
• Published output could encourage surveillance or forced disclosure.
• Published project material could serve as a curated map of where identity data is retained (section 1, T-16), even when every individual statement in it is about synthetic data.
• Public contribution could out a contributor, permanently and outside their control (T-17).

Controls

• Reviewers choose public attribution, private attribution, or pseudonymity in external material.
• The same choice is offered to every contributor before their first contribution, and pseudonymous contribution is accepted.
• Publication follows the publication policy: method and concept material is open, locator material needs recorded approval, and instance material about a real organization or person is never published.
• Do not collect a reviewer's gender identity unless they volunteer it for governance composition; store separately with explicit consent.
• Every case follows a necessity test: no field exists merely for completeness.
• The pack tests “declined” and “not collected” as legitimate states.
• No analytics, tracking pixels, third-party fonts, or external scripts in receipts.
• Do not publish customer scores or comparative rankings.

11. Incident response

SEV-1

Suspected PHI persisted/transferred, credential theft, signing-key compromise, malicious receipt, or synthetic record reaching real patient/billing operations.

1. Stop processing and isolate workspace/network.
2. Do not inspect more content than needed.
3. Notify customer security and clinical contacts within 1 hour.
4. Preserve minimal forensic metadata under counsel/customer direction.
5. Revoke credentials/keys and invalidate affected receipts/packs.
6. Determine notification duties with the customer and counsel.
7. Publish no details without authorization.
8. Complete blameless postmortem and reauthorize service before resuming.

SEV-2

Non-sensitive integrity failure, inaccessible receipt, serious false result, or pack defect without known patient exposure. Acknowledge within 4 business hours; issue withdrawal/correction within one business day when confirmed.

SEV-3

Minor tool, documentation, or support defect. Acknowledge within one business day.

A suspected clinical emergency is handed to the customer's clinical safety process immediately; ContextSafe is not an emergency service.

12. Verification before pilot

• Independent security design review.
• Malicious FHIR/HL7/CSV parser tests.
• PHI canary suite including direct identifiers, free text, FHIR narrative/contained/unrelated content, near-miss synthetic values, Unicode tricks, oversized input, and proof that the whole source is rejected rather than stripped.
• Receipt tamper and signature rotation tests.
• Logging and crash-dump inspection.
• Workspace permission tests on supported OSes.
• Optional adapter credential and query-scope test.
• Support-channel social-engineering tabletop.
• SEV-1 exercise with customer.

13. Known residual risks

• No detector proves data are synthetic.
• A staging system may share downstream production services.
• A hash does not prove evidence is truthful.
• A clinically approved fixture may still be wrong or become stale.
• Local endpoint security is outside ContextSafe control.
• A recipient can strip limitations from a screenshot.
• Publication is irreversible. Nothing in this model returns a published artifact to private, and the classification decision that let it out was a human judgment made once.
• Withholding locator material buys friction, not secrecy: the underlying representations are published standards, and a determined reader can reconstruct them.
• Apache-2.0 permits a fork that adopts none of these publication controls.

These risks must appear in the risk register. Those that bear on how a customer should read a result must also appear in the customer receipt; the publication residuals are project risks, carried by the register and the publication policy rather than by a receipt.