Brave makes Leo AI chat end-to-end encrypted with GLM 5.3 Flash in NEAR AI enclaves

What Brave shipped on 15 October

Brave published a long engineering post on end-to-end encrypted Brave AI on 15 October 2026, signed by privacy researcher Ali Shahin Shamsabadi, founder and CEO Brendan Eich, and engineers Darnell Andries and Jackson Egan. The headline claim is narrow and concrete: chats with the open-weight GLM 5.3 Flash model in Leo, the assistant built into the Brave browser, are now protected by end-to-end encryption and hardware-backed confidential computing.

In Brave's description, the browser encrypts each prompt on the device so that only an attested trusted execution environment, or TEE, can decrypt it. The TEE is operated by NEAR AI and runs on Intel TDX processors with Nvidia confidential-computing GPUs. Brave says the feature is available today in its Release, Beta and Nightly channels, and that users turn it on by selecting GLM 5.3 Flash in Leo.

NEAR AI published its own announcement of the Leo integration the same day. It says Brave began deploying NEAR AI enclaves in November 2025 with DeepSeek V3.1 in Brave Nightly, and that this release moves private inference from the testing channel to the production browser, so every Leo user who picks GLM 5.3 Flash gets it. Brave calls its November 2025 version a first step whose protections still rested on Brave's policies rather than cryptography.

Step one: the enclave has to prove itself first

The order of operations is the important design choice. Brave says the browser cannot encrypt anything until it has the enclave's public key, and that key is only handed out after the enclave proves what it is. A Brave verification oracle audits every NEAR AI deployment before Brave approves it.

According to the post, the oracle checks Intel's signature on the enclave's TDX quote to confirm genuine Intel TDX hardware, and checks the GPUs through Nvidia's Remote Attestation Service. It rebuilds NEAR AI's own software from public source and compares it with what is running. The third-party model runtime is not rebuilt; Brave says it is pinned instead by a hardware-attested deployment log that shows which model image is serving, which is how the system confirms the attested model is the one the user requested.

Signing keys are recorded only if they are bound into a verified hardware attestation, and every check must pass before the oracle records its approval. The open-source Brave AI Gateway then fetches the live attestation for the chosen model, checks it against those approvals, and requires the enclave's encryption key to carry a valid signature from an approved signing key. Brave says the gateway re-checks before relaying each message, using a verification no more than an hour old, and refuses to hand out the key or relay the message if verification fails.

Step two: sealing each prompt with Oblivious HTTP

With a verified key, the browser seals the request using Oblivious HTTP, an IETF standard, through Chromium's built-in support. Brave spells out the cryptography: for each request the browser generates a fresh one-time X25519 key pair, runs an elliptic-curve Diffie-Hellman exchange with the enclave's public key, derives a symmetric key with HKDF-SHA256, and encrypts the whole chat request with AES-128-GCM, which also detects tampering. That stack is Hybrid Public Key Encryption as defined in RFC 9180.

Replies come back sealed under a key derived from the same exchange and are streamed piece by piece so only the browser can read them. Each new turn is a new request: the browser generates another one-time key and re-encrypts the entire conversation history. Brave says the same protection covers any page a user shares with Leo, which matters because the assistant is often asked about whatever is open in the tab.

Who sees your IP address and who sees your words

Encryption hides what is said, not where it came from. Oblivious HTTP handles that by splitting the job between a relay and a gateway. Brave notes the naming is confusing: the Brave AI Gateway plays the relay role, while the protocol gateway that decrypts the message sits inside NEAR AI's enclave.

Brave's table makes the split explicit. Its relay knows the user's IP address but cannot read the message. It drops the IP and forwards the ciphertext under Brave's own account, so to NEAR AI every request looks like it comes from Brave. NEAR AI's gateway enclave and its inference enclave can read the prompt, but only inside the protected hardware, and never learn the IP address.

Brave says this sits on top of Leo's existing protections: no account or login required, no IP logging, and Premium subscriptions validated with unlinkable tokens so payment details cannot be tied to conversations. On storage, it says neither Brave nor NEAR AI keeps the conversation and that chat history stays on the user's device.

Private web search from inside the enclave

A private assistant is less useful if it cannot look things up, and a naive search tool would leak the conversation. Brave's answer is to let GLM 5.3 Flash call a search tool directly from inside the enclave. Those calls go to the Brave Search API's LLM Context endpoint, which returns ranked, query-relevant passages rather than a list of links.

Because the model decides what to search from inside the enclave, Brave says the conversation is never decrypted outside it for search. The generated query leaves from the enclave rather than the browser, so it is not tied to the user's IP address, and Brave says those queries fall under the Search API's zero data retention option on its own independent index.

Why an open-weight model matters here

Brave argues that encryption alone is not enough if users cannot tell which model is answering. It says GLM 5.3 Flash was released by Z.ai with open weights under the MIT license in August 2026. Because the weights are public, an independent operator can host the model entirely inside attested hardware, the model's maker never sees the conversations, and the model the enclave attests to is one anyone can download, inspect and benchmark.

The post is also candid about the limits of open weights. Brave notes that research has shown backdoors can be planted in model weights in ways that are in some cases provably infeasible to detect, and says openness eventually has to extend to training. It points to Nvidia releasing Nemotron training data and recipes, Gensyn's reproducible open-1b and Brave Research's Confidential-DPproof as directions, without claiming GLM 5.3 Flash meets that bar today.

The same thread runs through other recent launches we have covered. Google described an on-device approach in Android's AISeal enclave, and Perplexity open-sourced the isolation layer behind its agent in its SPACE Firecracker sandbox. Brave's version is aimed at the plainest consumer case: an ordinary chat in a browser sidebar.

What NEAR AI brings and who else runs on it

NEAR AI says Brave serves more than 128 million monthly active users and that Leo ships inside the browser they already use. Its description of the setup matches Brave's: prompts are encrypted with Oblivious HTTP to a key that exists only inside the enclave, memory stays encrypted during execution, and the host operating system, the GPU operator and NEAR AI itself are locked out at the hardware level.

NEAR AI adds that every response is signed inside the enclave, and that NEAR AI Cloud returns an Intel-signed token from Intel Trust Authority alongside the raw attestation evidence. It stresses that verification does not rest on NEAR alone, because Brave's verifier checks the hardware and rebuilds NEAR's code before the browser gets a key. It lists Venice AI, Abound and the Government of Bermuda as other production customers.

Both founders are quoted. Eich ties the release to his 2014 'Trust but Verify' paper and says the code that proves privacy is open for anyone to check. NEAR co-founder Illia Polosukhin says browsers handle all of our personal information, so it is critical that AI is introduced in a user-owned way.

What still rests on trust, and what comes next

Brave is explicit that today's version still relies on Brave for one step: the browser trusts the Brave AI Gateway to perform the attestation check. Next, Brave says, the browser will check keys against a signed list of the oracle's approvals itself, and after that it will verify the hardware attestation directly. It also plans a public log of enclave keys so anyone can confirm every user gets the same one.

The post lists the parties the chain ultimately trusts: Intel and Nvidia for hardware and attestation, dstack for the enclave operating system, Sigstore for build records, GitHub for source code, Hugging Face for model weights, and public DNS for certificate checks. Brave also says GLM 5.3 Flash support is in beta and that other Leo features and models will move into the verifiable mode over time, so the protection does not yet cover every Leo model.

Brave frames the launch against risks it cites from others' reporting, including court-ordered retention of chatbot logs, exposed databases and indexed share links, and it says OpenAI announced a Private Intelligence plan last month with private inference still to come. Those comparisons are Brave's. What is checkable now is the published code for the browser client, the gateway, the near-verifier oracle and NEAR AI's enclave services, which Brave links from the post.