BetaFeatures and data are not guaranteed while we are in beta. Do not rely on it as your system of record yet. Beta terms

Trust

Security

Last updated September 24, 2026

Kairos is built for perioperative data: operating-room schedules, surgical episodes and the outcomes a value program pays on. This page says plainly how that data is protected, who else touches it, and how to reach us if you find a problem. The public demonstration holds synthetic data only.

Separate by design

  • Kairos is its own product: its own codebase, database, sign-in, encryption keys and design. It shares nothing with any other product.
  • The web application is a pure client of the Kairos API. It has no database access and holds no secrets beyond the API address.
  • Every rule — tenancy, authorization, audit, encryption, calculations, AI calls — lives in the API, so no surface can bypass it.

How data is protected

  • Encryption. TLS 1.2 or later in transit with HSTS; databases and backups encrypted at rest. Patient identifiers are stored only in a vault, encrypted field by field with AES-256-GCM under a versioned key held in a key-management service.
  • One door to identifiers. A single service can decrypt the vault, and every decrypt, view or export writes a row to a PHI access log. Operational tables carry an opaque reference token, never a name or record number.
  • Audit. Every change writes an audit row in the same transaction, chained to the previous row by hash. The database itself refuses updates and deletes on the audit, PHI-access and sign-in logs.
  • Sessions. The session token lives in an httpOnly, SameSite cookie that page scripts cannot read. Sessions are revocable on the server and end after 15 minutes without activity, with a warning a minute before. Accounts lock after five failed sign-ins; passwords are hashed with BCrypt.
  • Access control. Seven roles, facility scoping, and an explicit PHI-access grant that no role implies. Emergency (“break-glass”) access is time-boxed, requires a reason, and is reviewed after the fact.
  • AI on de-identified data. The AI layer can only receive de-identified aggregates. A guard on every outbound request blocks anything that looks like an identifier and logs the attempt. Every answer stores the tool calls that produced it.
  • No identifiers where they leak. No identifiers in URLs, and a log scrubber keeps request bodies, tokens and records out of logs.

Who else processes data

We use a small number of established infrastructure providers, each reviewed before integration and bound by a data-processing agreement — and, before any real patient data, a business associate agreement. The categories are below; a named list with each provider's certifications is available to any customer on request at the founding team.

Categories of sub-processors
CategoryPurposeWhat it holds
Cloud infrastructure providerCompute, networking, load balancing, container registry, logs and alarmsRequests in transit; application logs with bodies and identifiers scrubbed
Managed database serviceOperational records and the encrypted identifier vaultScheduling, episode and value-program records; identifiers only as ciphertext
Key management serviceEncryption keys for the identifier vaultKeys only — never the data they protect
Web hosting providerServing the web applicationRequests in transit; the web tier stores no customer data
AI model providerCopilot answers, daily briefs, recommendations and savings narrativesDe-identified aggregates only; identifiers are refused before any call leaves the platform
DNS and certificate servicesDomain names and TLS certificatesNo customer data

Independent verification

Kairos is not yet SOC 2 or HITRUST certified. It is designed and evidenced against HIPAA, HITRUST CSF, SOC 2 and ISO 27001 controls, and the product reports its own control status at runtime; see the compliance posture. An independent penetration test of the API and web application is planned before the first real patient record; results will be summarised here with the assessor named. We do not describe our security as “bank-level” or “unbreakable” — nothing is.

Report a vulnerability

Email the founding team. We acknowledge within two business days and keep you informed until it is fixed. We will not pursue researchers who act in good faith, avoid other people's data and accounts, do not degrade the service, and give us reasonable time to fix before disclosure. The demonstration contains synthetic data only; please keep it that way and never submit real patient information.