LastVet Security Posture¶

Last 1 Enterprises LLC
Status: Canonical security reference (August 2026). Whitepaper source material.
Audience: Security engineers, compliance auditors, privacy counsel, VA infrastructure reviewers, provider diligence.

This document is the index and narrative for LastVet's security posture. Detailed controls live in linked companion documents. Where this document and a companion disagree, the companion with the more recent Status line wins until this index is updated.

How to read this document¶

Label	Meaning
Implemented today	Deployed and verifiable in staging and/or production as described
Designed, not yet built	Architecture or policy is decided; code or infra incomplete
Aspirational (Track 2+)	Directional commitment; no production dependency today
AWS legacy	Former production path; retained only as a documented rollback net

LastVet Phase 1 is mental-health care coordination in San Diego, powered by VA Lighthouse APIs (Patient Health FHIR + Veteran Service History & Eligibility) plus open-data Facilities/Forms. No real veteran PHI has been admitted to production as of this writing; environments hold synthetic sandbox data only. VA production API access (case #00015000) remains pending.

1. Introduction and scope¶

What LastVet is¶

LastVet is a veteran-owned coordination layer, not an EHR. Veterans hold a sovereign health-and-service profile; providers receive consent-gated access to veteran-directed copies and LastVet-native coordination data. Clinical systems of record (progress notes, treatment plans, billable assessments) remain in provider EHRs.

What this document covers¶

In scope	Out of scope
Platform security (R940, network, storage, crypto)	Product UX copy (see `last.vet-web` legal pages)
Application access control (RLS, consent, audit)	Meridian, Angel, Sovereign tenant security (see architecture docs)
Key custody and encryption posture	Legal advice or attestation of HIPAA compliance
Compliance mapping (how controls relate to frameworks)	Gate build specs (`gates/`) except where cited
Post-quantum posture (current + planned)	Penetration test findings detail (see API repo)

Runtime topology (summary)¶

Implemented today (August 2026): Production and staging API traffic is served from the R940 platform (lastvet-api, lastvet-db, lastvet-edge, lastvet-imaging). Public HTTPS terminates at Caddy on lastvet-edge (Let's Encrypt). DNS for api.last.vet and api-staging.last.vet is Cloudflare grey-cloud only (authoritative DNS, not proxied). No CDN or third-party TLS terminator sits in the API data path.

AWS legacy: ECS + RDS stacks in us-west-2 remain online as a time-boxed rollback net with frozen synthetic data. They take no production traffic after R940 cutover and must not receive veteran PHI (Gate 0.5 invariant).

Security-relevant documentation across Last 1 repositories and this repo:

Canonical posture (API repo)¶

Document	Summary	Primary topic
`last.vet-api/docs/security/SECURITY_POSTURE_DATABASE_ACCESS.md`	RLS on four PHI tables, `lastvet_app` role, consent-table gap	Database access control
`last.vet-api/docs/security/SECURITY_POSTURE_IMAGING_STORAGE.md`	AWS SSE-KMS imaging model, presigned multipart, audit-at-issuance	Imaging (AWS design)
`last.vet-api/docs/security/SECURITY_POSTURE_TOKEN_CUSTODY.md`	VA OAuth tokens stay on veteran device (iOS Keychain)	OAuth token custody
`last.vet-api/docs/security/SECURITY_PENTEST_STATUS.md`	External assessment status and scope	Penetration testing

RLS implementation plans (API repo)¶

Document	Summary	Primary topic
`last.vet-api/docs/api/TRACK3_PHI_RLS_PLAN.md`	PHI table RLS rollout plan	RLS program
`last.vet-api/docs/api/RLS_BATCH1_CALLSITE_AUDIT.md`	Batch 1 callsite audit	RLS batch 1
`last.vet-api/docs/api/RLS_BATCH2_PLAN.md`	Consent-table RLS (planned)	RLS batch 2

Platform and migration (this repo)¶

Document	Summary	Primary topic
`../architecture/R940_PLATFORM_ARCHITECTURE.md`	R940 tenant map, ZFS, backups, VM lifecycle	Platform architecture
`../architecture/LASTVET_MIGRATION_PLAN.md`	AWS → R940 cutover, MinIO envelope design	Migration
`../architecture/COX_STATIC_IP_INGRESS.md`	Cox static IP, Caddy edge, DNS cutover	Public ingress
`../lastvet/README-postgres-recovery.md`	Postgres TLS, pg_hba, MagicDNS connectivity	Postgres TLS
`../lastvet/README-zfs-recovery.md`	ZFS key recovery for imaging dataset	ZFS encryption
`../lastvet/BITWARDEN_ENV_AUDIT.md`	BWS secret inventory vs code	Secrets audit
`../lastvet/BITWARDEN_HYGIENE_PLAN.md`	BWS naming and migration hygiene	Secrets hygiene
`../architecture/BITWARDEN_ENV_AUDIT_FULL.md`	Cross-product BWS audit	Secrets audit
`../architecture/BITWARDEN_HYGIENE_PLAN_FULL.md`	Full BWS hygiene program	Secrets hygiene
`../architecture/BITWARDEN_NAMING_CONVENTION.md`	Secret naming rules	Secrets naming

Compliance artifacts (this repo)¶

Document	Summary	Primary topic
`../compliance/CARIN_Code_of_Conduct_2023_signed.pdf`	Signed CARIN attestation (Ryan Curry, April 2026)	CARIN
`../compliance/CARIN_Confirmation_Email_Faltz_2026-04-15.pdf`	Leavitt Partners confirmation (Jaclyn Faltz)	CARIN
`../README.md`	Cross-product doc index, CARIN authoritative sources	Documentation home

AWS legacy (reference only)¶

Document	Summary	Primary topic
`../lastvet/AWS_ENVIRONMENT.md`	ECS, RDS, compliance logging module	AWS inventory
`../lastvet/AWS_OPS_CONSOLE.md`	AWS operational runbook	AWS operations

Track 1 (forthcoming, this repo)¶

Document	Summary	Status
`IMAGING_ENVELOPE_ENCRYPTION.md`	App-layer envelope encryption for MinIO imaging	Implemented v1 (August 2026)
`PQ_TLS_POSTURE.md`	Hybrid post-quantum TLS at Caddy edge	Implemented (August 2026)

Agent invariants (this repo)¶

Document	Summary	Primary topic
`../../.cursor/rules/00-invariants.mdc`	Phase 1 scope, two-data-plane, Part 2, Railway trip-wire	Engineering invariants
`../../AGENTS.md`	Gate orientation, coordination-layer boundary	Agent orientation

3. Threat model¶

What LastVet defends against¶

Threat	Primary controls
Unauthorized access to veteran health data	Consent engine, RLS on clinical tables, JWT/session auth, provider verification
Cross-veteran data leakage (IDOR)	RLS `FORCE` policies on `documents`, `health_record_items`, `provider_notes`, `self_reported_entries`; repository request context
PHI exfiltration via storage compromise	Encryption at rest (Postgres TLS transport, ZFS on imaging disk); designed: app-layer imaging envelope (Track 1)
Network MITM on API path	TLS 1.3 at origin (Caddy + Let's Encrypt); designed: hybrid PQ key exchange (Track 1)
Network-level surveillance of east-west traffic	Tailscale mesh (WireGuard) between R940 VMs; Postgres `sslmode=require`
Insider with DB credentials but no request context	RLS returns zero rows for `lastvet_app` without `app.veteran_id` / consent context (verified empirically)
"Harvest now, decrypt later" (HNDL) against long-lived ciphertext	AES-256 symmetric keys (PQ-effective security per NIST guidance); hybrid PQ TLS planned for transit
VA OAuth token theft from LastVet servers	Tokens never sent to LastVet API (iOS Keychain custody)
Non-consented provider access	Active consent grant required; `consent_audit_log` at imaging URL issuance
Grant-free clinical sharing	`document_share` allowlist excludes imaging types

What LastVet does not defend against¶

Limitation	Notes
Compromised veteran endpoint	Malware on phone/browser can read data the veteran can read
VA / ID.me / OAuth provider compromise	LastVet trusts VA Lighthouse and Sign in with Apple only within their stated assurance
Compromised provider EHR	LastVet is not the system of record for clinical documentation
Physical theft of R940 without key material	ZFS encryption protects at-rest imaging disk; operator physical controls are organizational
Nation-state with live access to running API memory	In-memory DEKs exist during encrypt/decrypt operations (Track 1)
Social engineering of veterans or staff	Training and process; not purely technical
Availability attacks (DDoS)	Single-host R940; no multi-region HA today

4. Sovereignty architecture¶

Implemented today.

Property	Implementation
Compute ownership	Dell PowerEdge R940 on operator-controlled hardware (Proxmox KVM)
Data residency	Postgres and object storage on R940 VMs; no multi-tenant cloud database
Public ingress	Cox Business static IP → downstream NAT → Caddy on `lastvet-edge` (`192.168.1.89`)
TLS termination	At origin (Caddy). No third-party reverse proxy decrypts API traffic
DNS	Cloudflare authoritative DNS, DNS-only (`proxied=false`). Not a CDN in the PHI path
Inter-service network	Tailscale MagicDNS (`*.tailc3bbdc.ts.net`), WireGuard encrypted mesh
Secrets	Bitwarden Secrets Manager; runtime injection via `bws run` / env restore scripts
Inference	Shared GPU host (`inference-01`); no PHI persisted on inference VM by policy

Designed / legacy:

Property	Status
Zero managed-cloud runtime	Production API on R940; AWS rollback net exists but takes no traffic
VLAN segmentation	Target topology documented; flat LAN `192.168.1.0/24` during transition
Second physical site DR	Planned; single-host limitation acknowledged

Reference: ../architecture/R940_PLATFORM_ARCHITECTURE.md, ../architecture/COX_STATIC_IP_INGRESS.md.

5. Data at rest¶

PostgreSQL (`lastvet-db`)¶

Control	Status
Transport encryption	Implemented: TLS required (`ssl=on`, self-signed cert with MagicDNS SANs). See `../lastvet/README-postgres-recovery.md`
Disk encryption	ZFS on `tank-fast`; operator custody
Application role	`lastvet_app`: no superuser, `rolbypassrls=false`
RLS	Implemented on four clinical tables (see §7)

Imaging object store (`lastvet-imaging`)¶

Layer	Status
ZFS native encryption	Implemented: `tank-bulk/encrypted-lastvet-imaging`, AES-256-GCM, key in BWS (`LASTVET_R940_ZFS_IMAGING_KEY`). See `../lastvet/README-zfs-recovery.md`
MinIO	Implemented (S3-compatible API on R940)
Application envelope encryption	Implemented v1 (August 2026). Per-object DEK, KEK in BWS, wrapped DEK in `imaging_envelope`. See `IMAGING_ENVELOPE_ENCRYPTION.md`

AWS legacy imaging model: SSE-KMS only, no app-layer ciphertext (SECURITY_POSTURE_IMAGING_STORAGE.md). R940 envelope encryption adds KMS-equivalent key separation on sovereign hardware.

Legacy local uploads (`/data/lastvet-uploads`)¶

DD-214 and vault document types use app-layer AES-256-GCM with a server-held key (LAST1_TOKEN_ENCRYPTION_KEY pattern). Distinct from imaging envelope (single key vs per-object DEK). See SECURITY_POSTURE_TOKEN_CUSTODY.md companion crypto module.

Symmetric primitive¶

AES-256-GCM for application and ZFS encryption layers. FIPS 197 (AES); GCM mode per NIST SP 800-38D.

Platform log aggregation (R940)¶

Control	Status
Central log store	Implemented (August 2026): Loki 3.3.2 on observability VM; Promtail on 11 VMs
Tiered retention	Implemented: `retention_tier=system` (90d), `retention_tier=audit` (6yr) via Loki `retention_stream`
Audit-tier sources	LastVet API, Postgres, Caddy journal units (Bucket A); MinIO deferred
Offsite / immutable archive	Gap: Loki on single VM; B2 offsite for audit tier still required (gap register #6, #10)

See ../observability/OBSERVABILITY_STACK.md Phase 3.

6. Data in transit¶

Veteran and provider → API (public Internet)¶

Control	Status
TLS version	Implemented: TLS 1.3 via Caddy + Let's Encrypt
Certificate authority	Let's Encrypt (domain-validated)
CDN / edge proxy	None on API hostnames (Cloudflare DNS only)
Hybrid PQ key exchange	Implemented: X25519 + ML-KEM-768 (`X25519MLKEM768`) on Caddy 2.11 / Go 1.26. Classical X25519 fallback for older clients. See `PQ_TLS_POSTURE.md`

API → Postgres, API → MinIO, inter-VM¶

Path	Status
Postgres	Implemented: `sslmode=require`, TLS to `lastvet-db.tailc3bbdc.ts.net`
East-west	Implemented: Tailscale WireGuard mesh; MagicDNS for stable hostnames
MinIO	TLS posture follows MinIO deployment config on `lastvet-imaging` (verify in ops runbook)

Reference: ../architecture/R940_PLATFORM_ARCHITECTURE.md (Inter-service naming).

7. Access control¶

Row-level security (PostgreSQL)¶

Implemented today on four clinical-content tables with FORCE ROW LEVEL SECURITY:

Table	Policy
`documents`	`documents_request_context`
`health_record_items`	`health_record_items_request_context`
`provider_notes`	`provider_notes_request_context`
`self_reported_entries`	`self_reported_entries_request_context`

Verified behavior: lastvet_app without request context sees zero rows on these tables. Provider reads set consent context before query (2026-07-21 fix).

Gap (documented, remediation planned): Thirteen veteran-scoped tables including consent_grants and part2_consents rely on application logic only. RLS batch 2 is required before real veteran admission. See SECURITY_POSTURE_DATABASE_ACCESS.md §3 and RLS_BATCH2_PLAN.md.

Control	Status
Consent engine	Implemented: active grant required for provider access
`consent_audit_log`	Implemented: append-only audit including `imaging_download_url_issued`
42 CFR Part 2	Implemented: `part2_consents` for SUD-sensitive flows; Phase 1 wedge is mental health
Request context	Implemented: `applyRequestDbContext` / `withRequestDbContext` per request
Principle of least privilege	IAM (AWS legacy), `lastvet_app` DB role, BWS project scoping

Two-data-plane discipline¶

VA-sourced data is consented and transient at the API boundary; only veteran-directed copies and LastVet-native data persist. See ../../AGENTS.md and ../../.cursor/rules/00-invariants.mdc.

8. Key custody¶

Key material	Location	Lifetime	Status
VA OAuth tokens	Veteran device (iOS Keychain)	Session / refresh per VA	Implemented
Server JWT / session secrets	BWS → API env	Rotated per env policy	Implemented
DD-214 / vault encryption key	BWS (`LAST1_TOKEN_ENCRYPTION_KEY`)	Server boot load	Implemented
ZFS imaging dataset key	BWS (`LASTVET_R940_ZFS_IMAGING_KEY`)	On-disk key file loaded at boot	Implemented
Imaging master KEK	BWS (`LASTVET_R940_{STAGING,PROD}_IMAGING_MASTER_KEK`)	API memory at startup	Designed (Track 1)
Per-image DEK	Ephemeral API memory during crypto ops	Per request	Designed (Track 1)
Wrapped DEK	Postgres (`imaging_envelope` table, planned)	Persistent with object	Designed (Track 1)

Rotation posture: kek_version field planned for imaging envelope. KEK rotation = re-wrap DEKs, not bulk re-encryption of objects. Rotation automation is not implemented day one (TODO comments at loader and repository boundaries in Track 1 implementation).

Never: log DEK/KEK values; write DEK/KEK to disk outside BWS; hardcode keys in source.

Reference: ../architecture/LASTVET_MIGRATION_PLAN.md (Imaging storage / envelope section).

9. Audit and verifiability¶

Implemented today¶

Surface	Mechanism
Veteran-facing access history	`consent_audit_log` (provider access, imaging URL issuance, consent events)
Secure link access	`secure_link_access_events`
Provider auth	`provider_auth_audit_events`
Imaging download	Audit at URL issuance, not only at S3/MinIO byte delivery
Application logging	Structured logs; no PHI in logs by policy
Infrastructure	`journalctl` on VMs; Proxmox host access SSH key-only
Centralized log aggregation	Implemented (August 2026): Promtail → Loki on observability VM; tiered retention (system 90d, audit 6yr). See `../observability/OBSERVABILITY_STACK.md`
Infrastructure alerting	Implemented (August 2026): Prometheus + Loki ruler → Alertmanager (email + Slack `#alerts-lastvet`); critical/warning runbooks in repo. VM-stopped and cert-expiry alerts deferred. See OBSERVABILITY_STACK Phase 4
External synthetic uptime	Implemented (August 2026): UptimeRobot Pro on `api.last.vet/health` (1 min) and `api-staging.last.vet/health` (5 min); email + Slack outside R940. Defense in depth with internal alerting. See OBSERVABILITY_STACK Phase 5
Public availability transparency	Implemented (August 2026): UptimeRobot public status page at `https://status.last.vet` (CNAME to `stats.uptimerobot.com`; standard URL `https://stats.uptimerobot.com/jKTZt8e5at` until DNS). Shows live uptime, response times, and incident history for all public LastVet endpoints. Intentionally public: we monitor and we report. Aligns with the sovereignty posture (veterans and partners can verify platform health without trusting a private dashboard). See OBSERVABILITY_STACK § Public status page

Designed / gap¶

Surface	Status
6+ year audit retention	Partially implemented: Loki `retention_tier=audit` holds 6 years on observability VM. Offsite immutable archive (B2) still required for site-disaster protection
Infrastructure log parity with AWS CloudTrail	Gap-with-mitigation on R940 (see migration plan parity table)
Population-level outcome verification (ZKP-ready)	Aspirational (Track 2). Design commitments in `../../LOOP_LEDGER_AND_PROOF_MACHINE_SPEC.md`; not implemented in production

10. Post-quantum posture¶

LastVet assumes long-lived health data may face harvest-now-decrypt-later adversaries. Symmetric and hash primitives are chosen for PQ resilience where NIST guidance applies; asymmetric migration is phased.

Symmetric encryption at rest¶

Primitive	PQ notes
AES-256-GCM	Grover's algorithm effectively halves key strength; AES-256 provides ~128-bit quantum security margin, still above NIST recommended thresholds for sensitive data. NIST IR 8105 (2016), FIPS 197

Implemented: AES-256-GCM for ZFS, vault documents, planned imaging envelope.

Key exchange in transit¶

Primitive	Status
X25519 (classical ECDH)	Implemented today (TLS 1.3 default)
ML-KEM (Kyber) hybrid	Implemented — FIPS 203. See `PQ_TLS_POSTURE.md`

Digital signatures¶

Primitive	Status
RSA / ECDSA (TLS certs, JWT)	Implemented today (Let's Encrypt, application JWTs)
ML-DSA (Dilithium)	Planned as Node.js / TLS ecosystem matures — FIPS 204

Hashing¶

Primitive	Status
SHA-256, SHA-3	Implemented where used (cert chains, integrity checks). PQ-safe as-is per NIST IR 8105

11. Compliance mapping¶

This section maps controls to frameworks. It is not a certification statement.

HIPAA Security Rule (45 CFR §164)¶

Safeguard category	LastVet control examples	Status
§164.308 Administrative	Risk analysis (this document + companions), workforce access via BWS, incident procedures (§12, partially documented)	Mixed
§164.310 Physical	R940 location access (organizational control; written procedure gap)	Gap before PHI
§164.312 Technical	Access control (RLS + consent), audit controls (`consent_audit_log`), integrity (GCM auth tags), transmission security (TLS)	Largely implemented; RLS batch 2 open
BAA	AWS BAA (legacy account); B2 BAA planned for offsite backup; no cloud BAA for R940 MinIO (operator-owned)	Mixed

CARIN Code of Conduct¶

Implemented: Signed attestation and Leavitt Partners confirmation on file. Public Terms §13.1 references CARIN Trust Framework principles.

Artifact	Location
Signed attestation	`../compliance/CARIN_Code_of_Conduct_2023_signed.pdf`
Faltz confirmation	`../compliance/CARIN_Confirmation_Email_Faltz_2026-04-15.pdf`

Pending: MyHealthApplication.com listing gated on live VA Lighthouse production connection.

42 CFR Part 2¶

Implemented: Part 2 consent flows for SUD-sensitive categories; mental-health wedge in Phase 1. Consent records in part2_consents. Hogan Lovells copy lock tracked in Gate 0.5.

VA Lighthouse API terms¶

Implemented: Sandbox approved; production access pending (#00015000). OAuth scopes limited to approved APIs. Token custody posture documented for VA review.

12. Incident response¶

Honest status: LastVet does not yet publish a standalone incident-response runbook in this repository. The following reflects policy intent and partial implementation. Counsel-reviewed breach notification procedures are tracked in Gate 0.5 and the LastVet Bible; they are not duplicated here as operational law.

Key rotation triggers (planned policy)¶

Event	Intended response
Suspected KEK compromise	Rotate imaging master KEK in BWS; re-wrap DEKs (Track 1); invalidate old `kek_version`
Suspected JWT/session secret leak	Rotate env secrets via BWS; force session invalidation
Suspected DB credential leak	Rotate `lastvet_app` password; review audit logs
ZFS imaging key compromise	Replace key file from BWS; re-key dataset (destructive; DR scenario)

Breach notification workflow¶

Step	Status
Detection and containment	Operator-driven; no automated SOAR
Assessment (PHI involved?)	Requires counsel; two-data-plane limits VA transient exposure
Notification (veterans, HHS, VA)	Policy in privacy/Terms; operational runbook gap
Post-incident review	Ad hoc

Reference: ../lastvet/LASTVET_BIBLE.md (breach notification procedures mentioned); gates/GATE_0.5_hardening_and_proof.md.

Audit log preservation¶

Requirement	Status
`consent_audit_log` integrity	Postgres durability on R940; no WORM/immutable store yet
Long retention (6+ years)	Partially implemented: Loki audit-tier retention (6yr) on observability VM. Offsite B2 immutable bucket still required for disaster recovery
Forensic export	SQL export capability; legal hold process not documented

13. Gaps register (security posture without dedicated doc)¶

Gap	Severity	Notes
Incident response runbook	High before PHI	No standalone IR playbook in git
Breach notification operational workflow	High before PHI	Referenced in Bible; not runbook-ready
RLS batch 2 (consent tables)	High before PHI	`RLS_BATCH2_PLAN.md`
Imaging envelope encryption	High before imaging PHI on R940	Track 1
PQ hybrid TLS	Medium (HNDL mitigation)	Track 1
6-year audit log archive	Medium	Loki 6yr audit tier implemented on observability VM; offsite B2 archive still open (site-disaster gap)
Physical security documentation	Medium	R940 platform notes §164.310 gap
B2 offsite encrypted backup	Medium	Planned in platform architecture
Formal pentest report in gates repo	Low	Lives in API repo only
VA production access	Blocking for real PHI	Case #00015000 pending
Web client OAuth custody delta	Future	`SECURITY_POSTURE_TOKEN_CUSTODY.md`

14. Document maintenance¶

Trigger	Action
Track 1 ships (`IMAGING_ENVELOPE_ENCRYPTION.md`, `PQ_TLS_POSTURE.md`)	Replace TODO links; update §5, §6, §8 status tables — PQ TLS done; imaging envelope in progress
RLS batch 2 completes	Update §7 gap
Real veteran PHI admitted	Re-review entire doc; close gaps register items marked "before PHI"
KEK rotation ships	Update §8 rotation posture from "designed" to "implemented"
AWS rollback net torn down	Remove AWS legacy rows; confirm Gate 0.5 trip-wire satisfied

Owner: Ryan Curry (Privacy Officer). Review cadence: before VA production access approval and after any material architecture change.

End of canonical posture index.