Trust Center
Compute security
How Lithi Compute scopes, approves, and separates accepted work, and where plaintext may exist on the Mac that executes it.
On this page
Lithi Compute security should be reviewed by the workflow being assessed, not by a single design statement. Name where a task begins, which information it may use, which Mac performs each step, which identity is acting, and where a person makes a decision. A diagram or component name alone does not prove what is operating for your account.
How work is scoped and approved
An accepted Compute task follows a bounded path: a quote or batch is requested, matched against current pricing, capability, and account limits, and only then accepted for execution. Execution uses the exact capability set named in the accepted quote. A task that does not fit an approved capability, or that fails a required check, is refused with a typed reason instead of running anyway.
Review one workflow at a time. Ask which product, data category, permission, service, and environment it uses, and match evidence to that scope rather than to Lithi as a whole.
How customers stay separated
Accepted work is routed to eligible Mac capacity under the current allocation and policy rules. A batch keeps its items separately identifiable so one item's outcome does not attach to another. Customer-controlled processing, Lithi service processing, and provider processing are kept as separate categories in any review; treat a claim about one as evidence for that category alone.
Where plaintext may exist during execution
Lithi uses encrypted transport on approved network paths and signed envelopes where the current protocol requires them. That protects a task in transit, and a receipt digest can bind evidence without revealing the private content it represents.
The provider Mac that executes accepted work still has to process the task, so it exists as ordinary, unencrypted data in that Mac's memory while it runs. A participating provider Mac is not a confidential-computing enclave, and Lithi does not claim otherwise. Provider-facing Lithi surfaces are designed to stay blind to customer content, but a privileged owner with physical or root-level access to that Mac may still be able to inspect ordinary unified memory during execution. Match the sensitivity of the work you send to this boundary; see encryption evidence for the path-by-path detail.
Reviewing a connected account
Where a workflow connects a provider account, review it by provider, resource, purpose, permission, and current connection state. A catalog entry shows what may be supported; it does not prove that a connection exists or works for your account. Read the provider's consent screen, confirm the account and requested permissions, and allow only the resources the task needs. Remove access you no longer need in Lithi and, where available, in the provider's own account controls.
What this review covers
| Field | Record |
|---|---|
| Scope | A named Compute workflow, data category, identity, service, and environment. |
| Status | Review guidance; live customer configuration is not established by this page. |
| Owner | Lithi trust team |
| Evidence | Current architecture material, the accepted quote and policy record, and environment-specific control evidence. |
| Last reviewed | 2026-09-03 |
| Limitation | This page does not prove deployment, isolation, authentication, recovery, or a specific provider's behavior. |
Limits
Products, configurations, connections, and environments can differ. No single control proves the whole workflow. An unresolved security question should name the workflow, version, environment, identity, data category, and evidence period.
Primary action
Request current security evidence