How Compute encrypts your data
Where your Compute data is encrypted, who can read it while a Mac works on it, and what encryption does not protect.
When you prepare supported Compute work with the Kit, it encrypts permitted input before it leaves your environment. Control and relay services carry ciphertext and approved metadata. An admitted Mac decrypts only its assigned piece in execution memory, then encrypts the result for its authorized recipient.
Your environment
↓ encrypted input
Assigned Mac reads its piece
↓ encrypted result
Approved destinationThis protects content while it travels and while it is stored. The Mac must read the data it processes, so encryption does not make ordinary host memory confidential from every sufficiently privileged or compromised host operator. Encryption is not confidential execution. Check the processing path and destination before you approve a task, and use Choose a Compute data profile to decide whether the input is suitable for shared execution.
The paper describes this flow in Prepare and protect your input and its cryptographic detail in Encryption and key access.
When a workflow combines pieces, your environment performs the final join by default. A network reducer, when the plan uses one, receives only its declared scoped inputs; those reads count toward the reducer owner's cumulative exposure.
For example, a document task split into encrypted blocks can pass through a relay without exposing its plaintext. The assigned Mac receives a key only after the current assignment and access checks pass, reads its block, and returns an encrypted result.
See where each protection applies
| Part of the job | Readable data and protection |
|---|---|
| Customer-local preparation | Authorized local Lithi code may inspect and prepare your input. Other tools you authorize have their own processing terms. |
| Transfer | Content travels as ciphertext on the approved path. Ciphertext means encrypted bytes; the intended recipient and transfer permission remain separate checks. |
| Ordinary control and relay services | These services handle approved metadata and ciphertext, not customer plaintext. Content-aware transformation is not an ordinary relay function. |
| Admitted execution | A specifically authorized executor reads the input inside its bounded memory or workspace to perform the task. |
| Result storage | The executor encrypts the result for its authorized recipient before it leaves. The selected storage profile determines where the encrypted artifact is held. |
| Destination | Delivery needs permission for the exact destination and recipient. Decryption and any later copies are subject to that destination's access and retention rules. |
Account information, billing records, and safe diagnostic metadata are not the encrypted task itself. Do not place private content in filenames, error text, or support messages and assume task encryption protects those fields.
When you seal input locally, keep preparation material, key custody, and destination credentials in the environment authorized to use them. The Compute Kit reference describes the supported local helpers and their custody boundaries; follow its published contracts for the selected integration.
Understand the executing Mac
A participating provider Mac is not a confidential-computing enclave. While a Mac works on its piece, that piece is readable in the Mac's memory, where someone with physical or root-level access to that Mac could read it. An XPC helper can put execution in a separate process with its own sandbox and code-signing rules, which narrows that process's authority. It does not make ordinary Swift or MLX plaintext cryptographically inaccessible to a sufficiently privileged or compromised host operator. A DMG, release signature, hardened runtime, or XPC boundary does not change that host-memory limit.
Memory locking and buffer clearing are best-effort hygiene. mlock may be denied, and clearing one buffer cannot prove that every allocator, GPU, swap, crash, or backup copy has been removed. A sufficiently privileged or compromised host operator may still be able to inspect ordinary unified memory during execution. Encryption in transit or at rest does not hide data that is actively being processed from every such host operator.
Match your input's sensitivity to that limitation before approval. A valid signature, device identity, or successful scan does not remove it. A signature protects the integrity and identity covered by its verification rules; it does not prove the result is correct.
Who can release a key for a shared job
Each encrypted block has its own key. Lithi releases the keys for an assigned piece only after the current assignment, lease, fence, purpose, and owner-exposure checks pass. A lease limits the authorization in time; the fence identifies the current attempt. Every release is recorded.
By default, a release authority holds a key for the run that can technically unwrap block keys. It uses that ability to release keys to the assigned Mac, rather than to read your content. This means the default construction does not support a claim that Lithi is unable to decrypt your input.
Managed custody is the default. A supported customer-held profile can keep key release on your machine instead, with the kit online while the run is active. Key custody is separate from the data profile's content decision: the two custody modes expose keys to different authorities. Both modes release keys automatically under the approved job or automation policy; no human approves each grant, retry, redrive, or repair. Read how your job is split across Macs for the limits that apply to each release, and Choose who holds the keys for the custody distinction.
Keep keys and access scoped
A work credential, a transfer permission, and a recipient key serve different purposes. One does not replace the others. Keep secrets and signed download or upload links out of prompts, logs, receipts, and support requests.
A recipient change or a new destination requires the appropriate authorization. Do not redirect a result, weaken encryption, or add a plaintext relay to recover a failed transfer. Recover delivery of the existing accepted result rather than starting inference again.
Access follows the object, not the request. A recipient who can fetch and decrypt a whole object has access to all of it; asking for only part of it does not reduce that. Access is issued against independently protected bounded objects or chunks, each bound to an exact recipient, generation, and purpose. Review which bytes a released key can actually decrypt, including neighboring chunks, manifests, intermediate artifacts, and retry copies.
Associated data binds context; it does not remove access. A shared key still confers everything it can decrypt, regardless of the context tag attached to it.
A stable shard identity does not mean stable ciphertext. The same logical piece of work can be re-encrypted with fresh key and nonce material on a retry. Identical ciphertext is not expected, and Lithi does not require it.
Separate access expiry from cleanup
An expired link stops that access path. It does not establish that the stored object, a backup, a temporary buffer, or a destination copy was erased. Revocation cannot recall plaintext already disclosed to a recipient or hostile host.
Use the applicable retention terms for each data category. A cleanup claim needs evidence for the objects and locations it actually covers, not a promise about every allocator, GPU, swap, crash, or backup copy.
Read and verify Compute result files to check a delivered artifact before relying on it. Review result retention and deletion before deciding where to keep a result or how to confirm its removal.