Brave Leo Adds End-to-End Encrypted AI Chats With GLM 5.3 Flash and OHTTP

Brave Software is attempting to replace those policy promises with cryptographic enforcement. Following an initial confidential-computing experiment launched in November 2025, the browser maker has rolled out end-to-end encrypted (E2EE) conversations for its built-in Leo AI assistant across its Release, Beta, and Nightly browser channels. By pairing client-side Oblivious HTTP (OHTTP) encryption with hardware-enforced Trusted Execution Environments (TEEs) operated by NEAR AI, Brave has built a pipeline designed so that when users select the GLM 5.3 Flash model, neither Brave nor the underlying AI infrastructure provider can link who is asking a question to what is being asked.

For Windows power users, enterprise IT administrators, and privacy-conscious developers evaluating browser AI integrations, Brave's architecture offers a fascinating look at how confidential computing is moving from datacenter whitepapers into everyday desktop software—along with a few crucial architectural caveats that aren't quite finished yet.

From "Trust Me Bro" to Cryptographic Verification​

To understand why this update matters, it helps to look at how browser AI usually works—and how Brave's own system worked until this week.

In November 2025, Brave introduced its first iteration of verifiable privacy in Leo by running DeepSeek V3.1 inside NEAR AI's Nvidia-backed TEEs in Brave Nightly. While that earlier setup isolated the language model inside secure hardware, user requests still passed through Brave's servers under traditional policy protections: encrypted in transit, not logged, and discarded after generating a response, with Brave's servers checking the hardware attestation and displaying a green status label. In other words, you didn't have to trust the GPU host, but you still had to trust Brave not to inspect your traffic as it passed through the company's infrastructure.

In a statement reported by The Register, Brave co-founder and CEO Brendan Eich pointed back to his 2014 "Trust but Verify" principle, arguing that users should not have to place blind trust in the software they rely on and noting that too much of modern AI still runs on "trust me bro" promises at the user's expense.

Brave's October 2026 release changes the architecture by making hardware attestation a prerequisite for client-side encryption. Rather than terminating your prompt's encryption at Brave's servers, the Brave browser encrypts the prompt—and any webpage context you share with Leo—directly on your local machine before it ever hits the network.

Summary of What Changed​

• Live Across All Channels: The end-to-end encrypted chat mode is active now in Brave Release, Beta, and Nightly.
• Model-Specific Protection: The E2EE pipeline specifically applies when users select GLM 5.3 Flash ( currently labeled as beta within Leo), an open-weight model released by Z.ai under the MIT license in August 2026. Other models hosted in Leo do not automatically share this exact pipeline.
• No Account Required: Consistent with Leo's existing design, using the assistant requires no user login, and paid Leo Premium subscriptions validate via unlinkable tokens rather than tying payment identities to chat streams.

Under the Hood: How OHTTP and Hardware Enclaves Split Trust​

If you encrypt a payload on a Windows PC and send it directly to an AI server, the server might only decrypt it inside a secure enclave, but the network interface outside that enclave still sees your IP address. Conversely, if you bounce your query through a standard proxy, the proxy provider often sees both your IP and your payload.

Brave solves this metadata problem by implementing Oblivious HTTP (OHTTP), an Internet Engineering Task Force (IETF) standard defined in RFC 9458, using Chromium's built-in OHTTP support. As specified in RFC 9458, OHTTP separates a network transaction into two distinct roles—an Oblivious Relay Resource and an Oblivious Gateway Resource—so that no single intermediary holds both the client's network identity and the decrypted message content.

Here is how Brave and NEAR AI divide those roles across a four-step pipeline:

1. Pre-Flight Hardware Attestation​

Before your browser will encrypt a single character, it needs cryptographic proof that the remote enclave is genuine. Brave operates an open-source verification oracle that audits NEAR AI's TEE deployments. This system checks Intel's signature on the CPU enclave's Trust Domain Extensions (TDX) quote and verifies the GPU attestation via Nvidia's Remote Attestation Service.

To guard against supply-chain tampering—the classic problem described in Ken Thompson's 1983 lecture Reflections on Trusting Trust, where a compromised compiler injects a backdoor invisible in public source code—Brave's verification oracle uses reproducible builds. It takes NEAR AI's publicly audited source commits, rebuilds the software images from scratch, and verifies that the resulting binaries match the signed build provenance running inside the enclave.

Before relaying a message, the Brave AI Gateway checks the TEE's live attestation against those approved records using a verification no more than an hour old. If the enclave fails verification, Brave refuses to supply the encryption key to your browser.

2. Client-Side Sealing via HPKE​

Once the Brave AI Gateway supplies a verified TEE public key, the browser uses Hybrid Public Key Encryption (HPKE, standardized in RFC 9180) to lock down the request:

1. For each individual turn in a conversation, the browser generates a fresh, ephemeral X25519 keypair.
2. It performs an elliptic-curve Diffie-Hellman (ECDH) key exchange between that one-time key and the TEE's public key to establish a shared secret.
3. Using HKDF-SHA256, it derives a symmetric key and encrypts the entire chat request—including conversation history and shared page context—using AES-128-GCM, an authenticated cipher that prevents undetected tampering.
4. When the model responds, the TEE streams its reply back encrypted under keys derived from that same exchange. Because Leo does not store your conversation state on the server, every follow-up question in a chat generates a brand-new ephemeral key and re-encrypts the conversation history from your device.

3. Confidential Inference and Grounded Web Search​

Inside NEAR AI's enclave, the ciphertext is decrypted exclusively within hardware-protected memory: encrypted RAM on Intel TDX CPUs and firewalled memory on Nvidia Confidential Computing GPUs, with encrypted bus transfers between the CPU and GPU. Neither the cloud host, NEAR AI engineers, nor the host operating system can inspect memory while GLM 5.3 Flash processes the tokens.

What happens if you ask Leo a question about current events that requires searching the web? Usually, letting an AI assistant browse the web punches a hole straight through privacy guarantees. In Brave's implementation, GLM 5.3 Flash decides what to search from inside the TEE and calls the Brave Search API's LLM Context endpoint.

Because the search request originates from the TEE rather than your desktop browser, your IP address is never exposed to the search engine. Furthermore, the raw conversation stays inside the enclave; only the model-generated search query is sent to the Brave Search API, which returns ranked web passages under Brave's zero-data-retention policy.

Why GLM 5.3 Flash and Open Weights Matter​

It is not a coincidence that Brave launched this E2EE pipeline with Z.ai's GLM 5.3 Flash rather than a proprietary frontier model from OpenAI, Anthropic, or Google.

While proprietary models can technically run inside hardware enclaves, they must remain under the operational control of their creators, and their internal weights cannot be independently inspected. Because GLM 5.3 Flash was released with open weights under the permissive MIT license in August 2026, an independent infrastructure operator—NEAR AI—can host the model entirely inside attested hardware without Z.ai ever touching the inference pipeline or seeing user traffic.

Moreover, hardware attestation combined with open weights addresses a growing annoyance in the AI industry: silent model substitution. When cloud AI providers face heavy compute load or want to trim GPU bills, they have an incentive to quietly route user queries to smaller, cheaper, or more heavily quantized models behind the scenes. By pinning the model image in a hardware-attested deployment log and signing responses inside the TEE, Brave's architecture is designed to guarantee that the model answering your prompt is actually the model you selected.

The Catch: What Brave Hasn't Finished Yet​

As impressive as the cryptographic plumbing is, veteran systems administrators know that every chain of trust has weak links and transitional compromises. To Brave's credit, both its engineering blog and The Register's reporting explicitly highlight the pieces of this architecture that are still under construction:

• Browser-Side Verification is Still Pending: Right now, your Brave browser relies on the Brave AI Gateway to check the TEE's attestation and hand over the approved encryption key. While Brave cannot read your encrypted prompt, a theoretical compromise of the gateway could still misdirect key delivery before a check occurs. Brave's roadmap includes moving attestation verification directly into the client browser and publishing a public transparency log of TEE keys so users' machines can independently verify that everyone is receiving the exact same enclave keys.
• Exact In-Memory Weight Attestation: Currently, the third-party model runtime isn't rebuilt from source (it is pinned via a hardware-attested deployment log), and the enclave does not yet cryptographically attest to the exact model weights loaded into GPU memory or prove that quantized variants were faithfully derived from the original release. Brave lists exact in-memory weight attestation as upcoming work.
• The Ultimate Root of Trust: Even when verification moves entirely into the browser, confidential computing is not magic. As Brave's engineering team notes, the verification chain ultimately rests on trusting Intel and Nvidia (for CPU/GPU enclave hardware and remote attestation services), dstack (the enclave operating system), Sigstore, GitHub, Hugging Face, and public DNS.
• Traffic Analysis Limits: As documented in RFC 9458, while OHTTP prevents a relay or gateway from linking an IP address to plaintext content, it does not magically eliminate all network metadata, message size observation, or timing correlation by an adversary monitoring network hops.

How It Compares to Other Private AI Approaches​

Brave isn't the only company trying to solve the AI data-exposure dilemma. As The Register notes, major cloud and OS vendors—including Microsoft, Apple, Google, AWS, and Nvidia—have all rolled out variations of confidential cloud compute or private cloud enclaves, while smaller players like Prem AI focus on encrypted inference.

For Windows users and enterprise admins, the practical spectrum of AI privacy currently breaks down into three tiers:

1. Policy-Based Cloud AI: Services advertising "Zero Data Retention" (ZDR) or enterprise agreements promising not to train on your prompts. Useful for compliance, but backed by legal contracts rather than cryptography.
2. Confidential Cloud Compute (TEEs + OHTTP): Architectures like Brave Leo's GLM 5.3 Flash mode, where client-side encryption and hardware enclaves isolate data in transit and in use from both the relay and the server operator.
3. Local On-Device Inference: Running open-weight models locally on your own Windows workstation via tools like Ollama, LM Studio, or Windows ML on NPU/GPU hardware. If the prompt never leaves your local PCIe bus, no cloud subpoena, open database bug, or relay compromise can touch it—assuming, of course, your local Windows machine hasn't been compromised by malware.

How to Test End-to-End Encrypted Chat in Brave Leo​

If you run Brave on Windows, macOS, or Linux and want to test the encrypted pipeline yourself, you don't need to dig into brave://flags or configure custom proxies. However, you must select the right model, as Leo does not apply this pipeline across every assistant option by default.

1. Update Brave: Ensure you are running the latest version of Brave (Release, Beta, or Nightly channel).
2. Open Leo: Click the Leo AI icon in the browser sidebar or address bar, or open a conversation panel beside your active tab.
3. Switch the Model: Open the model selector menu inside Leo and explicitly choose GLM 5.3 Flash.
4. Verify Context Sharing: Whether you type a standalone prompt or allow Leo to read the active webpage tab beside it, the browser will automatically encapsulate the payload via OHTTP before transmitting it through the Brave AI Gateway to NEAR AI's TEE.

By combining RFC 9458 Oblivious HTTP with Intel TDX and Nvidia Confidential Computing, Brave has raised the bar for what consumer and prosumer browsers should deliver when integrating cloud AI. Until client-side attestation verification lands directly in the browser, it isn't a completely trustless system—but in an era where millions of users casually paste medical records, legal disputes, and proprietary source code into cloud chatbots, replacing "trust us" with open-source, hardware-attested encryption is a massive leap in the right direction.