Security

Every AI product says it takes security seriously. That sentence carries no information, because no product says the opposite. This page is the version with detail in it — the ciphers and parameters we use, where the boundaries actually sit, and the things we can see that we would rather be able to tell you we cannot.

If you are evaluating Secure AI for a team, this is the page to read. Privacy is the argument for the design, the policy is the legal text, and sub-processors names the companies involved.

How a request travels

A message leaves your device over TLS and reaches our own infrastructure first. It is never sent directly from your device to an AI provider — that indirection is the whole design, and it is what makes the rest of this page possible.

Our service holds the provider API keys and does the talking. Your request arrives carrying a signed authentication token; what leaves for the provider carries your question and the name of the model to answer it, and nothing that identifies you. Your account, your email, and your subscription tier are resolved on our side and stay there.

One consequence worth stating plainly: because each request reaches the provider without an account attached, there is nothing on their side to thread two of your questions together into a history.

What you type is still sent. We remove the identity attached to your account. We do not — today — remove identifying details you write into the message yourself. If you type your address or upload a document with your name on it, that reaches the provider as you wrote it. The anonymity is in the account, not in the contents.

Accounts and sign-in

Sign-in is handled by Google and Apple. We never receive, transmit, or store a password, which means there is no password database here to breach — the most common way a company of our size loses its users' credentials is simply not a shape we have.

Stored data is scoped per account at the database layer, so one signed-in account cannot read another's rows. Requests additionally carry an attestation that they came from a genuine build of our app rather than a script replaying our API.

Encryption

In transit. Everything is TLS, on every platform, with no plaintext fallback.

At rest. Conversations — chat titles and message contents — are encrypted on your device before they are stored, with AES-256-GCM: a 256-bit key, a fresh random initialization vector per record, and an authentication tag that makes tampering detectable rather than silent. The key is derived with PBKDF2-HMAC-SHA256 at 100,000 iterations.

What is not encrypted. Encryption covers conversations. Notes, reminders, projects and memories are stored unencrypted, protected by the per-account database rules described above and nothing more. We would rather write that sentence than let you assume otherwise.

On the web. A browser has no keychain and no secure enclave, so the web client stores nothing worth stealing: no history, no memories, no notes, no key. Your conversation lives in the tab and is gone when you close it. History and sync are offered on iPhone and Android, where the operating system can actually guard a key.

Photographs. An image file carries more than the image — the coordinates it was taken at, the device that took it, and the moment it happened. That block is removed on your device as the picture is attached, so it is gone before the upload starts rather than after it arrives.

What we can see

The column that matters is the middle one, and it is deliberately about capability rather than practice. What we are able to read is what could be compelled from us by a court or taken from us in a breach; a promise that we choose not to look is worth much less than a design that means we cannot.

Training

Nothing you type trains a model — not ours, and not a provider's. This is excluded by contract with each provider rather than switched off by default, which is why there is no toggle for it in Settings. A toggle would imply the other position exists.

Reporting a vulnerability

If you have found a security issue in our apps, our website, or our API, we want to hear about it before anyone else does. Email security@secureai.one with enough detail to reproduce it. The same address is published at /.well-known/security.txt.

We will acknowledge your report within 3 business days and tell you what we intend to do about it within 10. We will not pursue legal action against anyone who reports a genuine issue in good faith, who stays within their own account's data, and who gives us a reasonable chance to fix it before publishing. We do not run a paid bounty programme today; we will credit you by name if you would like that, and say so if you would not.

Please do not test in ways that degrade the service for other people — no denial of service, no automated scanning at volume, and no accessing or modifying data belonging to an account that is not yours.

What we do not have yet

Secure AI has not been through a third-party security audit or penetration test. Nothing on this page has been verified by anyone outside the company — it is an accurate description of how the system is built, written by the people who built it, and you should weigh it as exactly that. When that changes, the report will be linked here.

The redaction of identifying detail from within message contents — as opposed to from the account a message arrives on — is designed but not built. We will describe it here when it ships and not before; until then, Vision sets out the plan and the status of every part of it.

Questions about anything above? Email security@secureai.one.