How Arkalife protects your records
Uploading a family's medical history to a website is a large thing to ask. This page describes what the system actually does, in enough detail to be checked, and states plainly what it has not done.
Signing in
Sign-in is Google only. There is no password field anywhere in the product, so Arkalife never receives, stores or transmits a password — there is nothing to leak in a breach and nothing to reuse from one. Google verifies your email address before Arkalife ever sees it.
Apple sign-in appears in the code as a disabled option and is not offered. Magic links and email-and-password sign-in do not exist.
One account cannot read another's records
Every table holding records has row-level security enabled in the database itself, so isolation is enforced by Postgres rather than by application code remembering to filter. A query that forgets a condition returns nothing, instead of returning somebody else's rows.
This is verified rather than assumed: applying the policies runs a check across every table in the schema and fails if any one of them has row-level security switched off. A table added without a policy does not quietly ship.
What happens to an uploaded report
When you upload a report, it is stored and sent to Anthropic's API to read the values off it. Anthropic does not use data submitted through its API to train models. Arkalife does not train any model of its own on your records, and does not sell, rent or share them.
The extracted values are a draft until you confirm them. Nothing reaches your record from an upload without you reviewing it first, and what the laboratory printed is kept alongside the normalised value — Arkalife never overwrites the original.
Analytics carry no clinical content
Product analytics are optional, asked for at signup, and recorded per account. When enabled they carry counts, durations and fixed categories — never a marker name, a value, a reference range, a file, or the contents of a report.
That boundary is enforced mechanically, not by convention. Only one directory in the codebase is permitted to import the analytics library; a lint rule rejects the import anywhere else, so no code path can send an event that bypasses the checks. A test fails the build if a clinical field name appears in the event catalogue.
Session recording is masked with no way to unmask it
Where session replay is enabled, every input and every piece of text on the screen is masked before the recording leaves your browser. There is no selector, class or exception that can unmask any part of it — the capability is absent from the configuration rather than switched off, so it cannot be re-enabled by a settings change.
Where records are stored
Records are held in a managed Postgres database and object store hosted in the Asia Pacific (Mumbai) region, encrypted at rest by the platform, and reached over TLS. The application runs on Cloudflare Workers.
Deleting your account deletes your records. Analytics events tied to the account are removed within 30 days — see the privacy policy for what those events contain.
What Arkalife has not done
Arkalife holds no third-party security certification and has not been externally assessed. No independent review of this system has taken place. It is a small product, built and operated by one person, and saying otherwise would be the least trustworthy thing on this page.
Everything above describes controls that exist in the code and can be checked by reading it. None of it is a substitute for the external assurance a larger product would carry, and you should weigh it that way.
Reporting a problem
If you find a security problem, please write to security@arkalife.ai. Please include enough detail to reproduce it. There is no bounty programme; there is a person who will read it and fix it.