Security posture

This page is for a security reviewer at a hospital. It states what is in place today, and what is scheduled next.

Where Tavrik sits

Tavrik runs inside your network. Your traffic is never routed through a service Tavrik operates, and there is no inbound path from the internet. The gateway makes outbound connections to the model providers you allow and to your own audit systems, and nothing initiates a connection inward.

On the on-premises shape, the only externally reachable ports are 443 and 80 at the TLS edge, plus SSH for administration. Every application component binds to loopback and is reachable only through that edge or from the host itself. That covers the gateway, the admin API, the console and the database.

Credentials

Three credential tiers, deliberately separated:

• Tenant API keys authenticate applications to the gateway. Argon2id-hashed; the secret is shown once at creation and never again.
• Operator keys authenticate people and service accounts to the admin API. Same hashing discipline, a distinct prefix so a leaked credential is immediately classifiable, and role-checked on every request.
• Browser-extension credentials are short-lived and per-device, issued by an operator and revocable from the console.

Operators may also sign in through your own identity provider over OIDC or SAML. The root role cannot be reached that way: it is reserved for break-glass use with an API key, so that taking over your identity provider does not by itself produce a Tavrik administrator.

Keys

Provider API keys you upload are stored only as ciphertext, wrapped under a key-encryption key and decrypted in memory at the moment of a call. The console never shows a key again after upload, only its prefix and status.

The key that wraps provider secrets and the key that signs browser credentials are separate, and the gateway refuses to start if they are configured to the same value.

The audit chain

Every request, policy decision, redaction and administrative action is written to an append-only log. Each entry carries the hash of the one before it, so altering or removing an entry breaks every link after it. Verification is available on demand: over a single event, over a range you supply, or over the whole chain end to end.

What verification proves, and from when. From the point a deployment moves its audit chain into the database, the log is a single ordered history and verifies as one chain from its first event to its most recent. Before that point, on a deployment that ran the gateway and the admin API against one audit file, the log is verifiable per event and per branch – every entry against its own hash, every entry against its parent – but not as one ordered history. We say so plainly because the distinction matters to an auditor and we found it in our own demo deployment rather than in a customer’s. The earlier record is retained and its state is recorded, immutably, in the first event of the chain that replaced it.

Audit records are categorical by contract: they record that a request happened, which kinds of patient detail were found and how many, and what was decided. They do not contain prompts, responses, or the matched values themselves.

Backup and recovery

The database, which holds the audit chain, is backed up nightly. We measured recovery on our own demo deployment when we moved it to a new host on 25 September 2026, and ran the move as a restore drill:

• Recovery time: 2 minutes 32 seconds. From stopping the old host to the first healthy request answered by the new one. That covers the final backup, the restore, and bringing the services up on a host that was already built.
• Recovery point: no events lost. The restored database held all 113,536 audit events, with the same final hash as the source and identical row counts in every table.
• The chain was verified before anything could write to it. The whole audit chain was checked end to end after the restore and before any service started.
• A failed upgrade is undone. Our demo deployment updates itself from each release, and each update must pass a health check. When it does not, the previous version is restored automatically: in our test the service was healthy again 12.7 seconds after the failure was detected. An upgrade from a release bundle, the way a hospital upgrades, also checks health, and keeps the previous version beside the new one so it can be restored by hand.

These figures come from a planned move, in which the old host was still available for a final backup. After an unplanned loss of a host, the recovery point is the most recent nightly backup, and those backups are currently kept on the same host. Three recovery tests have not been run: a restore from an off-host backup copy, a timed rebuild of a host from nothing, and a restore at a hospital’s data volume.

Assurance roadmap

Three assurance items are scheduled rather than complete. Each is dated.

Independent penetration test. Scheduled ahead of the first pilot go-live, against the deployed configuration a hospital would run. An annual third-party test is the standing commitment after that.

SOC 2 Type I. Control mappings are maintained for SOC 2, ISO 27001, HIPAA, the Australian Privacy Act and the EU AI Act. A mapping is how a certification is reached, not a substitute for one. The auditor is engaged and the observation period begins after the first pilot.

Customer-held keys on-premises. Available today on the dedicated cloud shape, where the key-encryption key lives in your own key-management service. On-premises support is next: today a hospital running the on-premises VM has that key managed by Tavrik.

Reporting a vulnerability

Write to security@tavrik.ai. Reports are acknowledged within one business day.