Security Built for Healthcare
Patient data is your highest responsibility. Ours is making sure it never leaves your control - even when AI is involved.
Request Security DocumentationSecurity Architecture
Six layers of protection - not as checkboxes, but as non-negotiable design requirements.
PHI Never Reaches the LLM
Before any content is sent to an AI model, Navaryn's tokenizer replaces the patient identifiers it finds - names, dates, ages, ZIPs, SSNs, MRNs, account and record numbers, phone, email, URLs and device identifiers - with opaque tokens such as [TOK_NAME_001]. A value it cannot confidently classify is tokenized anyway and the record is HELD for a human to confirm: never guessed at, never left raw. The token carries no identifying information on its own; the original stays in an encrypted vault the AI path cannot read. Every AI call in the platform goes through one gateway that sits behind the tokenizer, so there is a single place to inspect rather than a policy to trust - and the patient-matching path makes no AI-model call at all.
Encryption at Rest and in Transit
Patient identifiers are encrypted with AES-256-GCM into a vault table that has row-level security FORCED on and is readable only by the server-side service role - not by any application user, and not through the public API key. Data in transit is protected by TLS. To be exact about what we do not do: there is a single platform encryption key today, held outside the database and managed by Navaryn. Per-organization keys and a scheduled rotation are on the roadmap and are not in place. We would rather write that here than imply a control we don't run.
Tenant Isolation Enforced in the Database
Navaryn is multi-tenant: organizations share infrastructure and are separated logically, not physically. We say that plainly because the separation is worth checking rather than taking on trust. Every table in the application schema has row-level security ENABLED with organization-scoped policies - none are left open - and the tables holding identifiers additionally have RLS FORCED, so not even the table owner can bypass a policy. Isolation is provable the standard way: a member of one organization, querying as themselves, cannot read another organization's rows.
Mandatory Human Review
Every AI-generated compliance document - policies, breach notifications, risk assessments, physician queries - enters a structured approval queue and cannot be finalized without explicit human approval. This is enforced at the system level, not policy.
Immutable Audit Trails
Every agent interaction, approval action, document modification, and PHI reveal is written to an append-only audit log whose rows are hash-chained: an altered or removed row breaks the chain and is detectable rather than silent. INSERT is restricted to a dedicated database writer role, and UPDATE and DELETE are denied to every application role, administrators included. Logs export as CSV from the audit screen. We do not produce a NIST-formatted export today - if your investigators need a specific schema, tell us and we will map to it.
Access Control & Authentication
Role-based access control with least-privilege defaults - platform admin, organization admin and member - checked server-side on every privileged route and enforced again by database policy, so hiding a button is never the boundary. A caller's organization is derived from their membership on the server; a client-supplied organization id is rejected. Multi-factor authentication and SSO/SAML are NOT available yet. Both are on the roadmap ahead of the first pilot, and this page will say so when they ship, not before.
Re-Identification Control Flow
When a credentialed user legitimately needs to view original PHI, every step is controlled and recorded.
- 1
Re-identification runs through one server-side endpoint; the AI pipeline cannot reach it
- 2
The caller's session, role and organization are checked inside the database before any ciphertext is decrypted
- 3
The user's identity, the record, the route and the request IP are captured automatically - routine authorized viewing is recorded as access, not as a self-declared justification
- 4
For a formal Release of Information request, a separate approval decision is recorded before the release is finalized
- 5
The audit row is written BEFORE the value is returned - and if that write fails, the value is not returned at all
- 6
The original value is decrypted only for that request, and only for the record being viewed
Compliance Posture
HIPAA - Business Associate
Navaryn acts as a Business Associate under HIPAA and is built against the Security Rule (45 CFR Part 164). We execute a Business Associate Agreement with every customer organization before any PHI is transmitted to the platform - part of onboarding, not a plan tier. Our BAA template is in final legal review; the version you sign will be the reviewed one, and you are welcome to redline it.
SOC 2 Type II - not yet
We do not hold a SOC 2 report, and we have never told an auditor otherwise. A Type II observation window is planned once there is live pilot traffic to observe, because a Type II over an empty system proves very little. In the meantime we will complete your security questionnaire and walk your team through every control on this page, with the code and the database open.
Penetration Testing - not yet
No third-party penetration test has been performed. One is scheduled before the first production PHI is loaded, and we will name the firm and the date here once it is booked. If your procurement process requires a test report before a pilot can start, tell us early and we will sequence it that way.
Data Residency
All data is stored and processed in United States AWS regions: the application database in us-east-2, the application servers and outbound email in us-east-1. There is no non-US processing. There is no dedicated single-tenant region option today.
Questions About Our Security Posture?
We're happy to complete your security questionnaire, walk your security team through every control above, or sit down with a reviewer and open the audit log and the isolation policies live. We don't have a SOC 2 report to send you; we do have the controls, and we'll show them.
Contact Security Team