Compute
Compute security
Where your plaintext can exist, what protects it in transit and at rest, which data Compute refuses, and who is allowed to change any of it.
What this section covers
Security in Compute is four separate questions. Which data you may send. Where your data exists in readable form while work runs. What protects it in transit and at rest. And who is allowed to change any of that.
Each question has its own page below. None of these pages is a certification, and none of them replaces the agreement you sign.
Verified processing
A quality preset states what a result was checked against: schema and deterministic validation, independent sample verification, a higher verification rate, or your own rubric.
Verification tells you how a result was checked. It never promises the result is correct.
Where plaintext can exist
Your data is encrypted in transit and at rest. It exists in readable form in two bounded places. A bridge validates the frozen snapshot before work starts, and the executor holds it in working memory while your approved job runs.
Queues, logs, receipts and metrics never hold it. Lithi does not claim zero knowledge.
Policies and retention
Data profiles decide what Compute accepts, and regulated or credential-bearing content is refused rather than cautioned. Policy profiles carry your locality and approval rules.
Retention depends on the data category. A working file and a signed receipt keep different clocks.
Pages in this section
- See where plaintext can exist
- Choose the data profile for your input
- Set region and jurisdiction rules
- Register credentials as references
- Understand the untrusted-input boundary
- Revoke access during an incident
- Read what each contract settles