Compute security
What you approve before Compute runs your work, who can read your data along the way, and what to do if something looks wrong.
Choose the work, the data, and who may receive the result. Review those choices before you approve a Compute job. Encryption protects a named data path; it does not replace permission or make the computer doing the work confidential from its owner.
For example, a quote may cover classifying approved files and returning the result to one destination. Compute still checks the data profile, current access, execution limits, and destination before it admits that job. Changing the recipient or purpose requires the matching review again.
Review the work before it runs
A price preview helps you assess a task. A signed quote records the proposed work, price limits, and expiry. Neither alone approves execution.
You approve the exact work, or use an existing approval policy that covers it. Compute still checks current access, supported operations, data policy, and available limits before admitting the job. Eligible retries, redrives, repairs, and accepted-result replays run within that approved scope without a new human approval. A refused request is not completed work. If an earlier submission lost its response, find its existing status before creating another run. A changed destination, purpose, data scope, or other material term needs new authority.
Check each permission independently
| Review | What it determines |
|---|---|
| Data profile | Whether the actual input category and purpose are permitted. |
| Encryption | How the named transfer or stored object is protected. |
| Jurisdiction | Whether source, processing, storage, and destination restrictions allow this path. |
| Credentials | Which account and resources the acting client may access. |
| Execution admission | Whether this specific operation may run under the current limits and policy. |
| Destination | Which recipient and exact output location may receive the result. |
Passing one check does not pass the others. A connected source is not permission to read unrelated records. A work key does not grant account administration or payment authority.
Follow readable data through the task
Customer-local Lithi code may inspect and prepare input you authorize in your own environment. Your other AI tools have their own permissions and data-handling terms.
Ordinary control and relay services handle approved metadata and ciphertext: encrypted content they do not need to read. They are not an alternate place to decrypt, summarize, or combine customer content. Lithi-side content processing requires an explicitly admitted executor and its bounded memory or workspace.
The executor needs readable data to perform the task. Results must be encrypted for the authorized recipient before leaving it. Result storage and destination access retain their own scope, expiry, and retention rules.
When the workflow combines pieces, your environment performs the final join. A network reducer, when used, receives only its declared scoped inputs, and each readable group counts toward its owner's cumulative exposure.
A participating provider Mac is not a confidential-computing enclave. A privileged owner with physical or root-level access may inspect ordinary execution memory. Do not send data whose protection requirements cannot tolerate that boundary. The encryption explanation describes the separate transfer, execution, and storage limits.
Spread placement limits one owner's access
The Kit seals supported inputs into encrypted blocks locally. For work admitted under spread placement, Lithi plans bounded pieces across independently owned Macs. The selected profile limits the distinct input groups one owner can reach in that run, counting all their Macs, retries, checking, reducers, and combining. Providers do not choose their assignments. Each Mac reads its granted piece; spreading limits one owner's access but is not confidential computing. See how your job is split across Macs for the exact rules, single-group limits, and key-release custody statement.
Managed key release is the default. Qualified customer-held profiles keep release on an online customer kit. Both custody modes act automatically under the approved job or policy, so a human is not asked to approve each key grant, retry, redrive, or repair. A new purpose, destination, or wider scope still requires its own authority.
Three isolation directions answer different questions
Compute isolation works in three directions, and each answers a different question: protecting the Mac owner's machine from customer work, keeping one customer's work away from another's, and limiting who can read customer information — including the Mac that runs it. Passing one direction does not satisfy another.
| Protection | Question it answers | What it does not establish |
|---|---|---|
| Minimisation and pseudonymisation | How much identifying or unnecessary information is disclosed | That all remaining content is anonymous |
| Encryption and artifact grants | Who can obtain and decrypt which authorized object | Confidentiality from the host while it computes on the data |
| XPC, sandbox, and VM boundaries | What authority customer work can acquire on the Mac | That the Mac's privileged owner cannot inspect plaintext |
| Independent verification and receipts | Which stated checks passed, and what was accepted | Universal correctness, or that nothing else was copied |
Exposure is cumulative and counts at the point access is granted
A bound on one shard is not a bound on one provider. For each run, Lithi counts the distinct atomic groups a provider can reach across all its Macs, including work, checking, combining, and retry attempts. An atomic group is a record or another set of related data that must stay together. Repeated access to the same group counts once; using another Mac does not create a new allowance. Changing a device key, re-enrolling, using a second machine, or moving work does not reset it.
Disclosure is counted when access is granted, not when work wins. An attempt that failed, timed out, or returned nothing may already have received access to its input. Its grant still counts. Accepted output, billing, and disclosure therefore use different denominators.
Use Kit helpers within the approval boundary
Supported Compute Kit helpers check a request's account, operation, input bounds, and verification policy against the approval it carries. Transfer permission is separate from spend approval: it can authorize moving sealed bytes to a named destination, but it does not authorize paid execution. Service admission still checks identity, digests, expiry, ceilings, and current policy. Kit skills guide these choices; they do not enforce them.
Treat content as data, not permission
A document, retrieved page, or model answer cannot grant tools, spending, new destinations, permissions, or policy changes. Fixed-schema work does not authorize arbitrary host commands. Development work requires its separate qualified isolation path.
Input checks and isolation reduce risk; they do not prove that every parser flaw, malicious input, or escape is impossible. Review uncertain or high-impact results before using them. A signature proves its stated signer and bytes, not that every answer is correct.
Stop and preserve safe evidence
For a suspected exposure, stop the affected activity and verify access changes through the responsible account controls. Keep the safe job or request reference, time, client version, and error code. Do not include secret values, signed links, banking details, or customer files.
Cancellation, access revocation, incident closure, and deletion are separate outcomes. Expired access does not prove erasure of every temporary, backup, or destination copy.
Report a security issue with the affected surface and minimum safe reproduction. A report acknowledgment is not confirmation that the incident is resolved.