Compute security
How you control what Compute runs, where your data is readable during a task, how provider Macs are isolated, and how to report a concern.
You choose the task, the input data, and who can receive the result before any Compute job runs. Encryption protects your data in transit and in storage, while permissions govern what may run. Because tasks run on participating Macs rather than hardware enclaves, encryption does not make a task confidential from the owner of the Mac processing it.
For example, a quote might cover classifying a set of approved files and sending the output to one destination. Before starting the job, Compute still checks your data profile, account access, usage limits, and output destination. If you change the purpose, input scope, or recipient, the job requires a new approval.
Review the work before it runs
Preview, quote, and approval are separate steps. A price preview estimates the job, and a signed quote locks in the proposed scope, price ceiling, and expiration time. Neither step starts paid work.
Paid work starts only after your approval. You can approve a single job or rely on an active approval policy that covers that scope. Before admitting the run, Compute checks your current permissions, supported operations, data policy, and account limits.
Retries stay inside the approved scope. Eligible retries, redrives, repairs, and result replays run automatically within your original approval. If a request drops its connection, check the existing run's status before submitting a new one, and treat any refused request as unrun work. Changing the destination, purpose, data scope, or any other material term always requires a fresh approval.
Check each permission independently
Every job passes six independent checks before it runs:
| Check | What it confirms |
|---|---|
| Data profile | The input category and stated purpose are permitted. |
| Encryption | The transfer path and stored files use the required protection. |
| Jurisdiction | The source, processing, storage, and destination regions are allowed. |
| Credentials | The client has active access to the required account and resources. |
| Execution admission | The operation fits within your current policy and spend limits. |
| Destination | The recipient and output location are authorized to receive the result. |
Passing one check never bypasses the others. Connecting a data source only grants access to the records you authorize, and a work key cannot change account settings or approve payments.
Follow readable data through the task
1. Preparation in your environment. The Compute Kit runs locally on your machine to inspect and prepare the input you authorize. Any external AI client or tool you use alongside Lithi operates under its own permissions and privacy terms.
2. Encrypted transit through Lithi control and relay. Lithi's routing and control services handle approved metadata and encrypted payloads (ciphertext). They never decrypt, summarize, or combine your content. Content is only decrypted inside an admitted executor's bounded workspace.
3. Processing on the assigned Mac. The assigned Mac decrypts only the shard it needs to run the task, then encrypts the output for the authorized recipient before sending it back. Stored results and output destinations keep their own access, expiration, and retention rules.
4. Combining the final result. Your own environment reassembles the final output. If a workflow uses an intermediate network step (a reducer) to combine partial results, that step receives only its declared inputs, and every readable group counts toward that provider's exposure limit.
Know the provider Mac boundary. A participating Mac is not a hardware confidential-computing enclave. An owner with physical or root access to that Mac could inspect memory while a task runs. Only send data that fits this boundary, and see Encryption for full transfer, execution, and storage details.
Spread placement limits one owner's access
Split locally, distributed across independent owners. The Compute Kit seals your input into encrypted shards before upload. When a job uses spread placement, Lithi distributes those shards across independently owned Macs so no single provider reaches more than the allowed share of input groups—counting all of their Macs, retries, verification passes, and combining steps. Providers cannot choose which shards they receive. Spreading limits how much any one owner can see, though each Mac still reads the shard it processes. See how your job is split across Macs for sharding rules and single-group limits.
Automatic key release within your approval. By default, Lithi's managed key-release service issues decryption keys to assigned Macs after verifying their assignment. For eligible profiles, you can keep key release on your own online Compute Kit instead. Both modes release keys automatically for approved work, retries, and repairs—while any change in purpose, destination, or scope requires new approval.
Three isolation directions answer different questions
Compute isolates work in three ways: protecting the provider's Mac from incoming tasks, keeping one customer's tasks separate from another's, and limiting who can read customer data along the way. Each layer answers a distinct question—and none replaces the others:
| Layer | What it controls | What it does not prove |
|---|---|---|
| Data minimization and pseudonymization | How much identifying or unnecessary detail leaves your environment. | That the remaining content is legally anonymous. |
| Encryption and key grants | Which authorized Mac or recipient can decrypt a specific shard or result. | That the host Mac's owner cannot inspect memory during processing. |
| XPC, sandbox, and VM isolation | Which files, network paths, and system resources a task can touch on the Mac. | That a root user on the host Mac cannot read task memory. |
| Verification and receipts | Which quality and integrity checks passed before a result was accepted. | That every output is error-free or that no host memory was read. |
Exposure is cumulative and counts at the point access is granted
Limits apply per provider owner, not per Mac. For every run, Lithi tracks how many distinct data groups a provider owner can reach across all of their Macs—including primary execution, verification, combining, and retries. A data group (atomic group) is a record or set of related items that must stay together. Reading the same group twice counts once, and adding another Mac, rotating a device key, or re-enrolling never increases a provider's allowance.
Exposure counts as soon as a key is granted. If a Mac receives decryption access and later times out, fails, or returns no output, that grant still counts toward the provider's exposure limit. Because of this, exposure tracking, accepted results, and billing each use their own counts.
Use Kit helpers within the approval boundary
Supported Compute Kit helpers check each request's account, operation, input limits, and verification rules against your approval before sending it. Permission to upload encrypted shards is separate from permission to spend: uploading sealed files never starts a paid run on its own. When the request reaches Lithi, the service independently verifies identity, file digests, expiration, spend ceilings, and active policy. Kit skills help your agent prepare requests, while the Kit and service enforce the rules.
Treat content as data, not permission
Untrusted text inside a document, web page, or model output is treated strictly as data—it can never grant tool access, approve spending, add output destinations, or change security policy. Standard structured tasks cannot run arbitrary shell commands on a host Mac, and code or build workloads require their own isolated execution path.
Input validation and sandboxing reduce risk, though no filter can guarantee immunity against every parser bug or malicious input. Always review high-impact results before acting on them. A cryptographic signature proves who signed a file and that its bytes were not altered, not that the model's answer is factually right.
Stop and preserve safe evidence
1. Pause work and lock down access. If you suspect an exposure, stop the affected job and revoke or rotate access in your account controls.
2. Save safe diagnostic details. Record the job or request ID, timestamp, client version, and error code. Never paste API keys, signed URLs, banking details, or raw customer files into a support or security ticket.
3. Understand what each action completes. Canceling a job, revoking credentials, closing an incident, and deleting stored data are separate steps—and an expired link or key does not automatically erase existing temporary, backup, or destination copies.
Report a security issue with the affected surface and the smallest safe reproduction steps. An automated acknowledgment confirms we received your report, not that the issue is resolved.