The Karui security model

Everything Karui stores is encrypted in your browser before it is sent. The server holds ciphertext it cannot read. For inference, your browser encrypts the conversation to the model's enclave at NEAR AI or the gateway enclave at Phala, so it does not exist in the clear on our infrastructure either. A few derived things do, and only if you use the feature that produces them: the query a web search sends out, the address of a page the model reads, and the calls of a connector you route through our server. Each lives in memory for one request and is written down nowhere.

When you create an account, your browser generates a random 256-bit AES data key. That key is immediately wrapped — encrypted with a second key derived from your password using PBKDF2-SHA-256 with 600,000 iterations and a 32-byte random salt. Only the wrapped blob ever reaches the server. The wrapping key, and the unwrapped data key, exist solely in your browser's memory.

Every chat message, chat title, project name, project content, memory entry and stored image is encrypted with AES-256-GCM using that same unwrapped data key before upload — no per-item salt needed, since it's one key for everything you own. The stored format is [nonce | ciphertext]. Each ciphertext is also bound to its place: the kind of field, the IDs of the rows it belongs to and, for messages, the sender's role go into the encryption as associated data. Moved to another chat, another field or another role, it no longer opens.

Your browser can also wrap the same data key a second way, with a 12-word recovery phrase. The words never leave your device; the server keeps only a hash of a separate key derived from them.

Your password does two separate jobs, and neither sends it to us. To sign in, your browser derives a separate login key from it (PBKDF2-SHA-256, 600,000 iterations) and sends only that; the server stores an Argon2id hash of the login key. The login key cannot open your data key without cracking the password itself. For your data, the password is used locally, in the browser, to unwrap the data key returned at login. The unwrapped key never leaves your device. Two-factor sign-in with an authenticator app is available in Settings.

For a model to answer you, it has to read your prompt inside a hardware enclave. Your browser decrypts the conversation context, re-encrypts it to the provider's enclave key, and sends that sealed request through our backend, which has no key for it. The reply comes back the same way and is sealed again before it is saved to history. Which enclaves can read it depends on the provider.

The model you pick decides where it runs: Light and Heavy through Phala, GLM 5.3 Flash on NEAR AI. We use each provider's own model hosts, with one exception: Light and Heavy can run in Tinfoil's enclaves behind Phala's gateway when Phala has no host of its own for them. No other third-party hosts are allowed. Your browser encrypts the message text but leaves the surrounding envelope readable: we see roles, the number of messages, the model name and token counts, though not what was said.

NEAR AI. Before sending, your browser verifies that NEAR's gateway and the model's enclave run on genuine Intel TDX hardware, using quotes that chain to Intel's root and are bound to a fresh challenge. It encrypts each message to the model's own enclave key.

Phala. Your browser encrypts to Phala's gateway enclave. Each encrypted message is also bound to its position, the model and that one request, so it cannot be moved or replayed. Before sending, your browser verifies the gateway's attestation: a TDX quote that chains to Intel's root, Phala's production operating system, and an encryption key bound to that quote and to a fresh challenge. The gateway decrypts the message and passes it to a model host whose enclave it has verified, preferring Phala's own hosts. For Light and Heavy, if none is available, it uses Tinfoil. The gateway verifies Tinfoil's router enclave, its published code and its enclave-bound TLS key; the router then verifies the model's enclave before forwarding the message. Plaintext exists inside Phala's gateway and Tinfoil's router and model enclaves. This onward step is checked by Phala's gateway, not by your browser.

Neither browser check yet pins which release of the provider's code is running. Our backend pins the allowed host sessions at Phala, so that routing restriction also depends on our server behaving honestly. If an inference request fails, Karui shows the error rather than retrying it at NEAR AI or a different host. The Tinfoil route above is selected before sending Light or Heavy, not a retry after a failed request.

Providers that offer neither of these mechanisms are not on the list. Supporting one would mean relaying your words to it in plaintext; we removed the two we had rather than keep that path open.

A single message can leave your device more than once, so here is the full list. Your chosen model can pause its answer to ask for more: a memory file, a file from your project, one of your skills, a web search, or a web page. Your browser adds what it asked for and sends the conversation back to the same model at the same provider, sealed the same way. Web search and web pages are the exception. The search query the model writes goes to Brave, an ordinary third-party API with no enclave, and it reaches us readable on the way. When the model reads a page, its address reaches us readable too: our server downloads the page and hands its text to your browser, which seals it to the model like everything else. The site sees a request from our server, not from you. We don't log or store the address or the page. Turning web search off turns both off.

Connectors are the other exception, on Pro. A connector is a service you add, and the model can call its tools. Your browser reaches it directly where the service allows that. Some services refuse browsers, and you can also route any connector through us: our server then forwards each call and its answer, and sees them in readable form together with your access token. It keeps them in memory for that one request and does not log or store them. The service itself reads whatever the model sends it.

An image you attach goes to the model sealed like the text, and only to a model that reads images; our servers never see it. Memory stays sealed too, at every step: your chosen model sees only a list of your memory files and opens the ones it needs; when it notes something worth keeping, a smaller helper model merges it into the right file or leaves it as a suggestion; and that helper also reorganises your memory from recent conversations. Summarising older turns of a long conversation works the same way. You choose which provider runs the helper in Settings, so it can be a different one from the chat model. Every one of these features is optional, none of them is persisted, and in each case the work happens inside an enclave at the provider that runs it.

The attestation reports reach your browser through our server. It can withhold them but not forge them; because no code release is pinned yet, though, a dishonest server could hand out its own key only by running its own gateway or model deployment on genuine Intel TDX hardware. Separately, we serve the JavaScript that performs your encryption, so a server shipping altered code could weaken it.

Neither is a flaw in the cryptography; both are inherent to web apps that encrypt in the browser, and both come down to trusting the code we serve. That is precisely why we intend to open-source the encryption code after beta — so it can be checked rather than believed.

Your recovery phrase opens the same data key, so you can set a new password and keep everything. Without the phrase there is no recovery path for sealed data — that is a property of the design, not an oversight. Without your password or phrase the wrapped key cannot be opened, by you or by us. Resetting your password without the phrase starts a new sealed history, and the old ciphertext is deleted, since no one could read it again.

Ciphertext, wrapped keys, and Argon2id hashes. No readable conversations, titles, projects, memories or images — regardless of who is asking or how the data leaves the server.

Karui has not yet undergone a third-party security audit, and our legal documents are drafts under review. We'd rather state that than imply otherwise — the same honesty this page applies to the inference boundary.