published threat model · revised 2026-06-01

The threat model.Limits named in writing.

Five named adversaries. Our posture against each. What the customer verifies. Reviewed by counsel + external cryptographer.

Revision: 2026-06-01Reviewer: external cryptographer + counselcloud architecture →

honest scope

What we promise. What we will not claim.

We promise

Data-absence: nothing at rest to seize or produce.
Hardware isolation with customer-verifiable remote attestation.
Jurisdictional friction against foreign compulsion (Art. 271 SCC).
A published threat model that states exactly where the guarantees end.

We will not claim

That it’s mathematically impossible for us to comply. A state with physical hardware access is a real adversary.
Zero-knowledge proofs of frontier inference (not feasible at scale).
That Swiss domicile alone is a shield. Without data-absence, jurisdiction only slows the subpoena.

threats, enumerated

Five adversaries. One row each.

Threat. Posture. Mechanism. Verification path.

T1
US-jurisdiction subpoena targeting customer prompts.
Protected by data-absence + jurisdictional friction.
Mainstream AI provider receives a Rule 45 subpoena for chats. There is nothing on Xanadu's side that responds. Plaintext never persists. Swiss domicile makes foreign compulsion a personal crime under Article 271 SCC.
customer verifies via Reproducible enclave build hash; remote attestation signed by the GPU; quarterly audit signed by an external party.
T2
Operator (Xanadu) acting in bad faith.
Cleartext never leaves the GPU; operator cannot decrypt.
A rogue insider or compromised credential cannot exfiltrate prompts because they never had a decryption key. The enclave is the only holder, and the enclave's hardware root of trust is NVIDIA's silicon.
customer verifies via Customer measures the attestation chain on every connection. A swap to a non-enclave host or modified code is cryptographically visible.
T3
Foreign state with physical hardware access.
Not protected against. See ‘Where it stops.’
A state that can seize a GPU and run offline silicon attacks defeats any remote attestation system.
customer verifies via We publish where the hardware lives. Customers route only what their threat model accepts.
T4
Network adversary (passive or active).
Defeated by client-side encryption to the enclave key.
An attacker on the wire sees opaque bytes. So does an attacker who controls the front-door endpoint. The endpoint cannot decrypt. End-to-end channel is enclave to client.
customer verifies via Channel is bound to the attestation; a MITM swaps the attestation and the client refuses.
T5
Compromised model weights.
Mitigated by reproducible builds + customer-pinned weights.
Model weights are open and content-addressed. Customer pins a SHA the enclave loads and refuses to mismatch. Updates require a re-attested enclave with the new weights hash.
customer verifies via weights hash printed in attestation report; customer SDK refuses mismatch by default.

revision policy

The file changes before the architecture does.

Any change to the architecture lands here first, then propagates to the docs, the SDK, and the design-partner conversations. The date and reviewer signatures at the top are authoritative.