Your Data Security & Privacy

Your numbers are personal. Salaries, portfolios, trades, invoices, net worth — the things you track on CalculatorAI are some of the most sensitive data you own. This page explains, in plain language, exactly how we protect them, who can (and can't) see them, and the controls you have. Where it matters, we link to the official documentation of the infrastructure we build on so you can verify the claims yourself.

The short version: your data is encrypted, isolated to your account alone, never sold, and never used to train AI. We — the people who run CalculatorAI — do not browse through your entries, and our AI assistant only ever sees your data, only when you ask it something, and it is never trained on it.

Encryption everywhere

In transit. Every connection to CalculatorAI uses HTTPS/TLS, so the data moving between your device and our servers is encrypted and can't be read in flight.
At rest. Your data lives in a managed Supabase Postgres database (built on AWS), encrypted at rest with AES‑256. Daily backups are encrypted too.
Sensitive credentials get a second layer. When you connect a read‑only exchange or wallet, the API keys are encrypted a second time with AES‑256‑GCM before they're stored, using a key that never leaves our server environment.

References: Supabase security & compliance (SOC 2 Type II) · Vercel security, where the app itself runs.

Your data is isolated to your account

This is the most important guarantee. CalculatorAI uses Postgres Row Level Security (RLS) — database‑level rules that make it technically impossible for one account to read another account's rows. Every table that holds your content carries a policy of the form "you may only see rows where the owner is you," enforced by the database on every single query, not by app code that could be bypassed.

In practice that means: even a bug in our own frontend can't leak your trades to another user, because the database itself refuses to return rows that aren't yours.

The only way another person sees any of your rows is when you invite them: a shared space, or a colleague you give access to your Client Booking schedule. For the schedule, the colleague never reads your tables directly — our server checks their invitation on every request and hands back only what you chose (their own appointments or the whole schedule), never prices, payments, packages or your private notes about clients. Removing access takes effect on the next request.

Reference: Postgres Row Level Security, explained by Supabase.

Authentication is handled by Supabase Auth. If you sign up with a password, it is hashed (with bcrypt) before storage — we never store, see, or log your actual password.
You can add two‑factor sign‑in — an authenticator code, Face ID / fingerprint, or both — see the section below.
You can also sign in with Google, so no password ever touches us at all.
Sessions use secure, http‑only cookies.

Turn it on in Account settings → Security, and choose the second step: an authenticator app, Face ID / fingerprint, or both (at sign‑in, either one is enough).

Authenticator app. Every sign‑in asks for a six‑digit code from Google Authenticator, 1Password, Authy, Microsoft Authenticator or any other. The codes are TOTP, the open standard defined in RFC 6238: your app and our server share one secret and both derive the same number from the current 30‑second window, so nothing is transmitted that an eavesdropper could reuse. Enrolment and verification are handled by Supabase Auth MFA — we never see the secret after it is shown to you once as a QR code.
Face ID / fingerprint (also Touch ID, Android fingerprint, Windows Hello). This uses WebAuthn, the W3C standard behind passkeys and the same mechanism large services use for security keys. When you add a device, it creates a key pair and gives us only the public half; your face or fingerprint never leaves the device and never reaches us. At sign‑in the device signs a fresh one‑time challenge, and our server checks that signature against the public key before letting the session through. A device must confirm who is holding it (face, finger or device PIN), not just that someone tapped it. Each device is added separately, because the key lives on that device — add every phone and computer you sign in from, or keep the authenticator app as a backup.
A code by email, when the device can't. A face or fingerprint key lives on the device that created it, so on a new laptop or a borrowed phone it may simply not be there. The sign-in prompt then offers "Get a code by email": a six-digit code goes to your account's email address. It works for 10 minutes, allows 5 tries, only the newest code counts, and no more than 3 codes are sent in 15 minutes. The code is stored only as a one-way hash, and it replaces only the second step — the password or Google sign-in is still required first. It means your email inbox also counts as a way through the second step, so keep that inbox protected too.

Why it matters: a password can leak in someone else's breach, be guessed, or be typed into a convincing fake page. A second factor means a leaked password alone is not enough to get in. And with only the password, nobody can add their own second factor, remove yours or switch the protection off — every such change first asks for the second step you already have.

One thing worth knowing: turning two‑factor on also raises the bar on the Password Manager. See the next section.

The Password Manager is zero‑knowledge — we cannot read it, by design

Everything above describes data we protect. The Password Manager is different: it holds data we are structurally unable to read, and that is not a policy we could quietly change — it is arithmetic.

How it works, in four steps:

When you create your vault, your browser generates a random 256‑bit key — the vault key — using the Web Crypto API, the browser's own cryptography, not ours.
Your master password is stretched into a key‑encryption key with PBKDF2‑SHA256 at 600,000 iterations and a random per‑vault salt. That iteration count is the figure OWASP recommends for PBKDF2‑SHA256 — it makes guessing the password by brute force enormously expensive. This key wraps the vault key.
A recovery code — 32 characters, 128 bits of randomness, shown to you once — wraps the same vault key a second time. Either secret opens it; neither is ever sent to us.
Every saved login — title, username, password, website, notes — is encrypted with AES‑256‑GCM (NIST SP 800‑38D) in your browser, with a fresh random nonce each time, before it is saved.

What the server actually stores: opaque blobs and two wrapped copies of a key it cannot unwrap. There are no plaintext columns — not even the title or the website — which is also why the search box, the filters and the category list all run inside your browser rather than on our servers.

What that means in each bad scenario:

If this happened	What the attacker gets
Our entire database is copied, backups included	Encrypted blobs. Nothing to decrypt them with.
A CalculatorAI employee or contractor goes rogue	The same blobs. There is no admin tool, no support path, no override.
Someone takes over your email and resets your CalculatorAI password	Your account — and a vault that still asks for a master password, which the account login never sees.
Someone steals your session cookie	The same. And if two‑factor sign‑in is on, the database refuses to hand over vault rows to a session that never presented the second factor.

Unlocking with a passkey (Face ID, Touch ID, Windows Hello, a hardware key) is the one path with nothing phishable to type. It is not a shortcut around the encryption: the authenticator derives 32 bytes from a secret that never leaves the device, using WebAuthn's PRF extension, and those bytes produce the key. A forged credential produces different bytes and the cipher simply refuses — which is why there is no signature for us to check and nothing for us to get wrong.

A passkey belongs to one device, on purpose. This surprises people, so it is worth saying plainly: if you set up a passkey on your laptop and then open the vault on your phone, the phone will say it has no saved key for this site — and offer to scan a QR code or plug in a USB security key, neither of which you need. Nothing is broken. The key was never uploaded anywhere, which is the whole point: there is no copy on our servers for anyone to steal, so there is no copy to hand your phone either.

The fix takes one tap. On the new device, unlock with your master password, open Settings → Security and add a passkey there. The phone offers Face ID, the laptop offers Touch ID or Windows Hello, and from then on that device opens the vault without typing anything. Each device keeps its own key, and removing one — a lost phone — never touches the others. (Passkeys stored in iCloud Keychain are an exception: Apple syncs those between your own devices, so one may already work on the next.)

The vault also locks itself: after the idle time you choose (1 to 60 minutes), a minute after the tab goes into the background, when you leave the page, and when you sign out. A copied password is wiped from your clipboard after 30 seconds. The key itself lives only in that browser tab's memory — never in local storage, never in a cookie, never in a request.

The honest limits — what zero‑knowledge cannot do for you

We would rather say this plainly than let you find out later:

There is no password reset, and there never can be. A reset we could perform would be a vault we could read. If you lose both your master password and your recovery code, the data is gone — for you and for us. Print the recovery code.
A compromised device beats any password manager. Malware, a keylogger or a hostile browser extension on your own computer can see what you type and what is on your screen once the vault is open. No service — not ours, not 1Password's, not Bitwarden's — can prevent that. Keep your device clean and up to date.
A weak or reused master password is the weak link. 600,000 PBKDF2 iterations make guessing expensive, not impossible. Use four or more random words, used nowhere else, and turn on two‑factor sign‑in.
We can't stop you being phished into typing it. We will never ask for your master password or recovery code — not by email, not in the chat assistant, not through support. Anyone who does is not us.
Browser support has edges. Passkey unlock needs a browser and device that implement the PRF extension (Chrome/Edge 116+, Safari 18+, or a hardware key with hmac‑secret). Where it is missing we say so rather than pretend.

Legally, the limits of what we can be responsible for are set out in our Terms; practically, the list above is the honest version of it. Our commitment is narrower and firmer than a disclaimer: we will not build a way to read your vault, and if we ever could, this page would say so.

Payments never expose your card

We do not run our own payment forms and we never see or store your card number. All billing goes through Stripe, a PCI‑DSS Level 1 certified provider (the highest level) used by millions of businesses. Your card details are entered on Stripe's own secured checkout and stay with Stripe — CalculatorAI only receives a token that says "this customer is subscribed."

Reference: Stripe security & PCI compliance.

How the AI assistant handles your data

Our assistant can talk about your finances — your portfolio value, your win rate, your overdue invoices — so it's fair to ask what happens to that data. Here's the honest, complete answer:

It only sees your data, only when you ask. When you send a message, we assemble a compact snapshot of your data (protected by the same Row Level Security above) and pass it to the model to compute your answer. It is not a process that sits and watches your account.
No cross‑user access. Another person's data is never in your assistant's context, and yours is never in theirs.
It is not trained on your data. The assistant runs on Anthropic's Claude via their business API. Under Anthropic's terms, inputs and outputs sent through the API are not used to train their models. We also do not use your data to train any model of our own.
You're in control of what it knows. The assistant reads what you've saved so it can be useful; it doesn't act on your money or move funds.

References: Anthropic Privacy Center · Anthropic Privacy Policy.

Connected accounts are read‑only

If you link an exchange or a crypto wallet to the Portfolio Tracker, we ask only for read‑only access. A read‑only key can show balances — it cannot place trades, transfer, or withdraw anything. On top of that, the key is stored encrypted (see Encryption above). We never take custody of your funds and we never have the ability to move them.

What we never do

We never sell your data, and we never share it with advertisers or data brokers.
We never read through your entries for any purpose other than providing the service you asked for (and supporting you if you contact us).
We don't put personal or financial values into URLs, analytics events, or third‑party trackers.

You stay in control

Export anytime, for free. Exporting your own data (CSV) is always free, on every tier — it's your data, and it's never held hostage behind a paywall.
Delete anytime. Deleting an item removes it from view immediately; deleted content is then permanently purged on a rolling schedule. You can also delete your whole account yourself in Account Settings — on a paid plan, cancel the subscription first, so you are never billed for an account that no longer exists.
Read‑only after a trial ends. If your Pro trial lapses, your existing data stays safe and visible — expiry only limits creating new items, it never deletes what you already have.

Details of what we collect and your rights are in our Privacy Policy, Terms, and Cookie Policy.

Reporting a security issue

Security is never "finished," and we take reports seriously. If you believe you've found a vulnerability, please email us through the contact page with the details and steps to reproduce, and give us a reasonable window to fix it before disclosing publicly. We're grateful for responsible disclosure.

An honest note

No online service — ours included — can promise it is impossible to breach; anyone who claims otherwise is not being straight with you. What we can promise is that we use the same battle‑tested, independently audited infrastructure that banks‑adjacent fintechs rely on (Supabase, Stripe, Vercel, Anthropic), that your data is encrypted and isolated to you, that we never sell it or train AI on it, that the one thing we could never be trusted with — your saved passwords — is encrypted so that we cannot read it rather than merely promising not to, and that you can export or delete it whenever you want. If our practices ever change, we'll update this page and our Privacy Policy.

Questions about any of this? Reach out — a real person will answer.