I am the author of venice-e2ee-proxy, using @Elkim 's venice-e2ee library.
Venice sells private inference that should be end-to-end encrypted to the gateway, or at least attested by TEE (Venice can see the prompt, but it goes to the secure enclave).
Over the past few days, I spent some time improving the verification (both in the proxy and upstream library) and I got some spare Venice credits and wanted to try the new Qwen 3.8-Max (and Claude Opus 5 later for verifying the audit results).
While the design is not bad, it does not guarantee end-to-end encryption and non-logging in its current form. Also, there can be some functional changes to make this actually usable.
From the usability front, E2EE models do not support tool calling, because the API does not allow encrypted tool call parameters. While the library does some sort of inference to extract tool calls from the response, the models are very flaky and if you just want to run opencode through it, it won't work for more than a few interactions. This is the highest leverage usability fix.
The security story is a little bit longer, you can find details in the published "audit" below. But TLDR:
The proxy encrypts prompts on your machine to a key carried in an Intel TDX attestation, so Venice's network and infrastructure never hold plaintext. Decryption happens inside a Phala network -operated enclave ("the gateway") which then forwards your plaintext to an inference router, which forwards it to a GPU node.
So: you encrypt your prompt to a specific machine, and that machine proves what it is before you send anything.
The proof is hardware-signed. The CPU signs a statement saying: this is a genuine sealed VM, here is a fingerprint of the code running inside it, and here is the public key that lives in there. You check that signature against Intel's root certificates on your own machine, then encrypt to that key. Venice, whose API you are calling, is just a pipe. They carry ciphertext.
So far that is ordinary remote attestation. The interesting part is what happens next.
The sealed machine (the gateway) does not run the model. It has to forward your prompt to a GPU box. So how do you know that machine is sealed too?
You don't check it yourself. You don't have to.
The code running in the gateway, the code whose fingerprint you already verified, contains a checker. Before forwarding anything it demands the next machine produce its own hardware-signed passport, verifies it against Intel, and binds the TLS connection to the key inside that passport, so it cannot verify one machine and then talk to a different one.
You know that check happens, because you verified the code that performs it.
Verify one machine, and it vouches for the next, and you know the vouching is real because the voucher's own code is attested.
It is also better than "trust me, I checked". The gateway signs a receipt for your request containing what it found, plus a hash of the next machine's actual passport. You can download that passport and verify it against Intel yourself. I did. It checks out, all the way down to the second hop.
What is missing to make this airtight
Two things actually matter for confidentiality:
1. Root SSH. The enclave's boot script can install an SSH key for root. Whether one was installed is an encrypted secret, and the attestation cannot tell you either way. If it was, somebody has a shell inside the "sealed" box and can read every prompt passing through it. This is a deployment choice, not a protocol limit, which is what makes it so frustrating.
2. The last hop's software is unmeasured. Your plaintext ends up on a GPU node whose serving software nobody has measured. Nothing cryptographic stops it from writing prompts to a log.
Then the ones that weaken the guarantee without breaking it:
3. The fail-closed switch is off. The gateway supports refusing to forward when the next hop fails verification. On the domain Venice's traffic actually uses, that enforcement is disabled: a failed check gets recorded in the receipt and the prompt goes anyway. The client flag that would turn it on is rejected by Venice's API with a 400.
4. Attested recipe, not attested binary. The measurement says "I compiled this exact source commit", not "I am running this exact binary". The build runs at boot against a cache that is not measured.
5. Dev OS image, with SSH and serial console enabled, and not published, so you cannot reproduce it and check what actually boots.
6. Replay. The gateway does not publish the random challenge it sent the next machine, so you cannot prove that passport is current rather than one captured earlier.
Note what is not on that list: whether the model weights are the genuine article. That is a correctness question, not a confidentiality one. A swapped model gives you worse answers, it does not leak what you typed.
Where that leaves things: Venice as a company genuinely cannot read your prompts. Phala, who operates the enclaves, could, if an SSH key was injected or if the unmeasured GPU-side software logs. Close the SSH question and flip the fail-closed switch and this goes from very good to genuinely hard to break.
Read it here:
Proxy:
@Elkim 's upstream library (that he is using for his open-source health consultant @getbased.health ): 
Note: There is also 
which has the same name, but is a different codebase and it uses older library that doesn't do proper verification yet and is much less secure.
GitHub
venice-e2ee-proxy/docs/SECURITY-AUDIT.md at main · jooray/venice-e2ee-proxy
Local proxy that transparently encrypts OpenAI-compatible Venice requests with end-to-end encryption - jooray/venice-e2ee-proxy
GitHub
GitHub - jooray/venice-e2ee-proxy: Local proxy that transparently encrypts OpenAI-compatible Venice requests with end-to-end encryption
Local proxy that transparently encrypts OpenAI-compatible Venice requests with end-to-end encryption - jooray/venice-e2ee-proxy
GitHub
GitHub - elkimek/venice-e2ee: Venice AI end-to-end encryption library — ECDH secp256k1, AES-256-GCM, TEE attestation verification
Venice AI end-to-end encryption library — ECDH secp256k1, AES-256-GCM, TEE attestation verification - elkimek/venice-e2ee
GitHub
GitHub - AxLabs/venice-e2ee-proxy: OpenAI-compatible proxy that adds end-to-end encryption to Venice.ai: talk to TEE-backed models with verified TDX + GPU attestation, no client changes.
OpenAI-compatible proxy that adds end-to-end encryption to Venice.ai: talk to TEE-backed models with verified TDX + GPU attestation, no client chan...
