Private compute & AI
Lit Protocol vs Google Confidential Cloud
Approve private compute through on-chain rules.
Confidential hardware protects execution. The next question is who can authorize the workload, grant it data, and change those decisions.
Scope: Lit’s on-chain approval method for confidential containers and Google Confidential Space, rather than every Google Cloud confidential-computing product. Contact Lit to plan an AI deployment.
Operator authority
Three questions about operator authority.
| Control | Lit · On-chain approvals | Google Confidential Cloud |
|---|---|---|
| Who can change the permissions? | Approvers designated by the deployment’s on-chain governance authorize changes to container code or network policy. Each change creates a new measured release.[1][2] | Data collaborators set attestation conditions and resource permissions. In the standard Google IAM setup, the relevant policy administrators—not merely the workload operator—can change these grants.[3] |
| Who can approve replacement code? | The approvers authorized by the governance contracts can approve runtime releases. The key-management system checks on-chain approval and hardware attestation before releasing keys. Deploying new code is not enough.[2][6] | The administrators who can change resource grants and attestation conditions decide which replacement images gain access. Digest-based grants can reject code that has not been approved.[3] |
| Who can stop access? | The runtime host can stop execution. Key release also depends on the key-management service. On-chain approval does not guarantee continued service or recovery.[1][2] | In the standard IAM setup, access depends on the collaborator’s resource grants and cloud services. Administrators who can change those grants can withdraw access; attestation does not guarantee availability.[3] |
Who can change the permissions?
- Lit · On-chain approvals
- Approvers designated by the deployment’s on-chain governance authorize changes to container code or network policy. Each change creates a new measured release.[1][2]
- Google Confidential Cloud
- Data collaborators set attestation conditions and resource permissions. In the standard Google IAM setup, the relevant policy administrators—not merely the workload operator—can change these grants.[3]
Who can approve replacement code?
- Lit · On-chain approvals
- The approvers authorized by the governance contracts can approve runtime releases. The key-management system checks on-chain approval and hardware attestation before releasing keys. Deploying new code is not enough.[2][6]
- Google Confidential Cloud
- The administrators who can change resource grants and attestation conditions decide which replacement images gain access. Digest-based grants can reject code that has not been approved.[3]
Who can stop access?
- Lit · On-chain approvals
- The runtime host can stop execution. Key release also depends on the key-management service. On-chain approval does not guarantee continued service or recovery.[1][2]
- Google Confidential Cloud
- In the standard IAM setup, access depends on the collaborator’s resource grants and cloud services. Administrators who can change those grants can withdraw access; attestation does not guarantee availability.[3]
The Lit advantage
On-chain rules govern runtime key access
Lit requires on-chain approval for container releases and checks it before releasing runtime keys. Teams can inspect which releases were approved.[1][2]
How confidential AI worksWhat control means in practice
For private compute, control means deciding which code can use data and what it may release. Lit binds container code and network policy to releases approved on-chain. Google can separate data owners from workload operators too; the distinction is where authorization lives and who can revise it.[1][3]
Shared protections
Both use attestation to identify software. Google Confidential Space can restrict data access to specific workload image digests, so a workload operator cannot simply substitute arbitrary code and retain that access.[3][4][5]
Sources and review scope
These comparisons use published documentation and the source code linked below. We have not audited or tested the providers’ live systems. Configurations vary, and source code alone does not establish who currently owns a deployed contract or how it is configured.