Last updated Feb 3, 2026
Not "we won't" — we literally cannot. Your messages are wrapped in two layers of encryption that only you and a sealed hardware room can unlock.
Zero-knowledge architecture · Trusted Execution Environment (TEE) · AMD SEV-SNP · Hardware attestation
How it works
First, one concept: there's a special kind of lock where anyone can lock it, but only one person can unlock it. Like a mailbox — anyone can drop a letter through the slot, but only the owner with the key can open it.
In Offload, there are two of these locks: the sealed room's lock (only they can unlock) and your lock (only you can unlock). Let's see how they work.
You write a message
You ask Offload something — maybe "What's on my calendar tomorrow?" This is your message, your actual data.
Your device locks it with the sealed room's lock
Before the message leaves your Mac, your device locks it with the sealed room's lock. Now only they can open it.
The locked message passes through Offload
You
Offload
The locked message travels through our servers. We see it — but we can't open it.
Why not? Because we don't have the key. The sealed room's private key is locked inside AMD hardware that we physically cannot access.
The sealed room unlocks it
The message arrives at the sealed room — a special computer with its private key locked inside AMD hardware.
Only this hardware has the matching key. Not us, not Azure, not anyone else. The sealed room unlocks your message and reads it.
The AI processes your request
Processing inside hardware-protected memory
Inside the sealed room, the AI reads your message and generates a response. All of this happens in memory that's encrypted by AMD hardware — nobody can peek inside, not even us.
The sealed room locks the response with YOUR lock
Now the response needs to come back to you. The sealed room locks it with your lock. Now only you can open it.
The response passes back through Offload
Sealed Room
Offload
The locked response travels back through our servers. Again, we see it but can't open it.
We don't have your private key either — it's on your Mac, protected by Touch ID and the Secure Enclave.
You unlock and read the response
The response arrives at your Mac. Your device uses its private key to unlock it, and you read the response.
That's it. Messages to the sealed room are locked with their lock. Responses to you are locked with your lock. Offload is in the middle of every message — but we can't open any of them.
The sealed room
You might be wondering: if we can't read your data, how does the AI process it?
The answer is a special kind of computer called a Confidential VM (CVM). Think of it as a sealed room with walls that nobody — not us, not the cloud provider, not hackers with physical access — can see through.
These walls aren't software. They're physical hardware, built by AMD. The chip automatically encrypts everything in the room's memory. Even if you plugged a monitor directly into the server, you'd see encrypted garbage.
Your encrypted message enters the sealed room, gets decrypted and processed by the AI, then the response is encrypted with your lock before leaving. At no point does unencrypted data exist outside this hardware-protected space.
How you can verify this
Here's the natural question: how do you know our "sealed room" is real and not just a regular computer where we can see everything?
The answer is hardware attestation — a cryptographic proof that the sealed room is genuine AMD hardware running exactly the code it claims to be running.
AMD burns a unique key into each chip at the factory
Physically etched into silicon — cannot be changed or extracted
The chip signs a certificate: "I am genuine AMD hardware"
Includes a hash of exactly what code is running
Anyone can verify this signature
Check it against AMD's public certificates — it's math, not a promise
Here's what this means for you: before your device sends any data to the sealed room, it receives a signed certificate from the AMD chip. This certificate proves two things:
- The hardware is real — The signature can only come from a genuine AMD chip. It's physically impossible to fake.
- The code is unmodified — The certificate includes a fingerprint of exactly what software is running. If we tried to sneak in code that leaks your data, the fingerprint would change and your device would refuse to connect.
This happens automatically every time you use Offload. Your device verifies the sealed room is legitimate before sending anything sensitive. Security researchers and auditors also verify this independently.
What we can and cannot see
We want to be honest about exactly what we can access. Here's the full picture:
| Data type | During sync | When stored |
|---|---|---|
| Browser tasks | Sealed room only | Encrypted to you |
| Files | Sealed room only | Encrypted to you |
| iMessage | Passes through* | Encrypted to you |
| Passes through* | Encrypted to you | |
| Gmail | Passes through* | Server-managed keys** |
| Calendar | Passes through* | Server-managed keys** |
* "Passes through" — what does this mean?
When you connect iMessage or WhatsApp, the data travels from Apple/Meta's servers. We never store it unencrypted — it's encrypted immediately upon receipt.
** Gmail and Calendar
Google sends data via webhooks that require server-side handling. This data is encrypted when stored, but with keys we manage rather than keys only you control.
The bottom line
For everything you do in Offload, your data is encrypted before it's stored. For most data types, only you hold the key. Data is never written to disk unencrypted.
Technical details
Want the full technical details? Read the complete security whitepaper.
Questions? Email security@offload.com