Does browser-encrypted research stay private when you use AI?

Follow one piece of data

Imagine a hypothetical private note about an invented company. It may exist as readable text in an unlocked browser, as ciphertext in synchronized storage, and as selected text in an AI request. These are different states with different access boundaries. Calling the whole system encrypted does not explain all three.

In the current beta, the browser encrypts saved research before cloud persistence. The included AI path necessarily processes the selected request as plaintext through the application server and OpenAI. The application is designed not to persist prompt and response bodies. That is a narrower statement than saying no operator could ever access an in-flight request or that a provider retains no data.

Separate sign-in from decryption

Google or email sign-in identifies an account. It does not recreate the secret needed to open its encrypted research. Thesis Lab uses a compatible passkey’s PRF capability for its default local vault setup, with an optional recovery-key method. Browser and credential-provider support must actually work; an ordinary successful sign-in is not an encryption test.

Before relying on a new method, verify that it unlocks the existing vault. Preserve a working method until that succeeds. Losing all decryption methods can make the saved research unrecoverable; support cannot recreate the vault key. Treat this as a usability and availability issue as well as a confidentiality issue.

Understand the device and script boundary

An unlocked application must display plaintext to its user. A compromised device, malicious browser extension, or maliciously replaced application code can undermine that boundary. OWASP’s HTML5 guidance warns that browser storage accessible to JavaScript can be exposed by script compromise. The practical lesson is to inspect where secrets and plaintext are handled, not merely whether storage has an encryption label.

Encryption also does not hide every operational fact. Authentication identifiers, connection metadata, ciphertext sizes, timing, and synchronization revisions can exist outside the encrypted research body. Account compromise can affect availability even when the attacker cannot decrypt earlier research.

Share deliberately

For a first workflow test, use an invented research note rather than copying a private portfolio, recovery key, or API credential into a prompt. Inspect the selected context before sending it. Review support feedback as a separate disclosure: text deliberately shared with the team has a different purpose from privately saved research.

Thesis Lab’s public content hub and its existing beta login host are separate surfaces. Do not assume a passkey registered for the beta hostname will unlock a different hostname. A future authentication-host transition needs an explicit recovery and credential design.

Method, sources, and limits

This guide traces a hypothetical note through the boundaries documented in the current release. Product privacy documentation and OWASP guidance were checked on 26 October 2026. It is not an independent penetration test, a guarantee against malicious code, or a claim that authentication and encryption eliminate every privacy or availability risk.