Security & privacy

TurboPrivate encrypts between your client and your allocated room. This page separates that transport guarantee from host confidentiality, local tools, retained metadata and deletion.

Trust boundary

Your client creates the usable room capability; the account service receives only its hash.
The client challenges the room and binds fresh X25519 + ML-KEM-768 key exchange material to that capability and challenge.
Requests cross the public network as XChaCha20-Poly1305 ciphertext to the room.
The room decrypts the request because the model must read it, then seals and signs the response for the client.

What each component can see

component	data boundary
Account and broker service	Identity, key metadata, allocation data, availability, token counts, cost and balance. It is not a plaintext inference gateway.
Allocated room	The exact model context and answer while inference is live. The Room has no workspace, filesystem, terminal or tool executor: it runs one model over the context it was sent.
Model engine	The model input and generated output required for inference. Request-content logging is disabled in the pinned service configuration.
Your application and local tools	Whatever your code passes to them. Their filesystem and network traffic are outside the encrypted room-channel guarantee.
Model route	The Room uses an approved TurboPrivate model route and fails closed when none is available. Caller-supplied provider credentials and arbitrary endpoints are not Room allocation parameters.

Current attestation level

Current customer rooms report transit-only unless a hardware quote is actually verified. Encryption prevents the account service and passive network observers from reading room traffic; it does not prove that a host operator, debugger or forensic capture could not inspect room memory.

Software cannot substitute for a hardware root of trust. A signed build measurement can identify expected software, but host confidentiality requires genuine confidential-compute attestation anchored outside that host.

Verify the evidence

See Privacy proofs for receipt checks, exported session evidence and offline verification. That page explains what each result proves and its limits.

Room deletion

Explicitly ending a room destroys its ephemeral transport state and live keys and lets the client report whether cleanup was confirmed. Idle expiry is the fallback when a client cannot confirm the request.

Model engines may retain account-isolated prefix computation independently of a Room. Closing the Room is not a per-conversation cache purge or proof of immediate erasure of that computation. Cache reuse is partitioned by billing account; keys and Rooms within one account are not separate partitions. See Context & caching.

The product retains account, billing, usage and limited operational metadata after room cleanup. On a non-confidential host, deletion cannot rule out copies an authorized host operator or forensic system made while plaintext was live.

Local storage

The CLI stores its long-lived key in ~/.turboprivate/credentials.json with mode 0600.

Practical guidance

Revoke a lost API key in the console under API keys; revocation is immediate and ends every Room the key opened.
Do not paste secrets into diagnostics, source control or ordinary logs.
Review local tools, hooks and shell commands that read Room output as separate data exits.
End model Rooms explicitly when finished instead of relying on idle expiry.