Private compute & AI
Lit Protocol vs Fortanix
See who can approve the next release.
Check which software is running and who can approve its replacement.
Scope: Lit’s on-chain approval method for confidential containers and Fortanix Confidential Computing Manager (CCM). Contact Lit to plan an AI deployment.
Operator authority
Three questions about operator authority.
| Control | Lit · On-chain approvals | Fortanix |
|---|---|---|
| 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.[2][1] | CCM’s role and domain administration govern which applications receive certificates. Inspect who can grant those roles and approve domains in the organization’s actual deployment.[4] |
| 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.[1][6] | CCM Administrator or Editor roles can approve a build. Certificate issuance depends on approval. Those role holders are therefore part of the application’s trust boundary.[4] |
| 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.[2][1] | CCM can deny certificate issuance when required build or domain approval is absent. Applications that rely on those certificates depend on the approval administrators and CCM service.[4] |
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.[2][1]
- Fortanix
- CCM’s role and domain administration govern which applications receive certificates. Inspect who can grant those roles and approve domains in the organization’s actual deployment.[4]
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.[1][6]
- Fortanix
- CCM Administrator or Editor roles can approve a build. Certificate issuance depends on approval. Those role holders are therefore part of the application’s trust boundary.[4]
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.[2][1]
- Fortanix
- CCM can deny certificate issuance when required build or domain approval is absent. Applications that rely on those certificates depend on the approval administrators and CCM service.[4]
The Lit advantage
On-chain rules govern runtime key access
Lit uses public contracts to determine which software can receive runtime keys. Teams can inspect approved code hashes and approval history without access to a private management console.[1][2]
How confidential AI worksWhat control means in practice
An approved certificate or valid attestation does not remove the authority of whoever approves the next build. Lit makes that authority and its decisions publicly inspectable. The rules for changing those approvals remain part of the security model.[4][6]
Shared protections
Both identify confidential workloads through attestation and measurements. Fortanix CCM uses approved builds and domains when issuing application certificates.[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.