Core concepts

Security model

The controls below are implemented and tested against a synthetic sandbox. They are described here because the design is the point — and because an honest account of what is still open is more useful than a clean-looking summary.

#Tenant isolation

Isolation is enforced at two independent layers. The application resolves every request within a tenant and authorized practice, and PostgreSQL carries composite tenant foreign keys on every tenant-owned edge, so an attempt to assemble an aggregate across tenants is rejected by the database itself.

Lookups that would otherwise confirm the existence of another tenant's resource return a deliberate non-disclosure response. Hostile tests cover cross-tenant reads, writes, foreign-key assembly, replay, and identifier guessing.

#The one-time review credential

The review flow is the most security-sensitive surface in the current system, because possession of the link is the only factor.

The secret never reaches the serverA 32-byte secret is delivered in the URI fragment. Fragments are not transmitted in HTTP requests, so the secret cannot appear in server logs, proxy logs, or referrer headers.
The client strips it before mountingThe browser captures and removes the fragment as its first operation, before the application renders, so it never enters browser history or any client instrumentation.
Exchange is single-useThe secret is exchanged exactly once, within five minutes, for a short-lived HttpOnly cookie. Storage is hash-only: a salted verifier, never the secret itself.
Comparison is timing-safeVerification uses constant-time comparison, and unknown grants perform equivalent dummy work so that timing cannot distinguish a real grant from a fabricated one.
Sessions are device-boundThe resulting session binds to request-derived properties and is revalidated on every read against environment, hash, device, expiry, state, and version.

Expired, unknown, already-consumed, and tampered grants all converge on one coarse 410. That uniformity is intentional: a caller cannot use response differences to enumerate valid grants.

#Evidence integrity

Audit entries form a per-tenant hash chain with a locked sequence head, so entries cannot be inserted, reordered, or removed without breaking a verifiable chain. A separate stream records security observations — invalid grant attempts are recorded by digest only, never by raw value. Verifiers re-derive both chains under repeatable-read isolation and report machine-readable failure codes.

Evidence rows are append-only at the database level. Update and delete are rejected by trigger on clinical snapshots, validation evidence, status history, grants, sessions, and outbox rows.

#Cryptography

Replay bodiesAES-256-GCM, bound by associated data covering status, headers, and version metadata

Idempotency keysBlinded via keyed hash, scoped by tenant, caller, and operation

Grant and session secretsSalted hash verifiers only; raw values never persisted or logged

Key materialEnvironment-supplied 32-byte root key; startup fails without it

#Transport and browser posture

The Nginx edge is the only published application origin and applies a restrictive content-security policy, frame denial, no-referrer, a request-body size limit, and canonical no-store JSON envelopes for its own failure responses. The backend is unreachable from the host directly. The web client carries no telemetry or analytics by design, because the review surface renders clinical content.

#Fail-closed posture

Startup refuses to boot on non-synthetic data or any environment other than the sandbox.
Blocking validation persists no partial aggregate.
Unresolved authority is denied rather than assumed.
Tampered outbox rows quarantine terminally instead of retrying.
Malformed or missing configuration prevents startup rather than degrading silently.

#What remains open

Stated plainly, because the boundary is the point

An independent adversarial audit conditionally approved this system for synthetic, loopback, no-egress use only, and identified hardening that must land before any live data or connectivity. Five engineering items remain open: database privilege separation, complete aggregate sealing, key governance and rotation, atomic authorization revocation, and a database-authoritative transition API.

They are scheduled work, not closed items, and this documentation will not describe them as closed until executable evidence exists. Detailed audit findings are held internally rather than published.

#Not present at all

Production identity is absent: there is no OIDC or OAuth provider, no multi-factor authentication, no identity proofing, and no workforce session model. Sandbox bearer authentication is disabled outside the local profile, so the current build has no usable production caller-authentication path — by design, since production access is gated regardless.

There is no PostgreSQL row-level security, no separately privileged runtime and migration roles, no external immutable audit export, no production observability pipeline, and no backup, restore, or disaster-recovery implementation. The platform makes no HIPAA, SOC 2, ONC, DEA, or prescription-network compliance claim.

#Reporting a vulnerability

Suspected security defects belong in a private disclosure process, never in a public issue and never in a report containing secrets, credentials, or patient information. Because this system holds only synthetic fixtures, no report should ever require real clinical data to demonstrate.