Privatemode
Edgeless Systems' hosted inference service with confidential model workers and a client-verifying proxy or SDK.
INPUT / OUTPUT PRIVACY
Stage 1Partial proof
ASSESSED DEPLOYMENT
Client-verifying proxy / SDK
Verification labels describe capabilities established by the cited sources. This review did not perform live cryptographic attestation, reproduce production builds or complete an independent security audit.
Who actually runs the models?
Edgeless Systems serves open-weight models using vLLM on Scaleway and Lyceum infrastructure. Its workers load the models and perform inference; they do not forward prompts to a choice of upstream model APIs.
Deployment and TEE coverage
Assesses the proxy or SDK path with reviewed reference values. The proxyless API lacks client-side attestation and is excluded from the higher request-path assurance.
CPU confidential VMs and NVIDIA confidential GPUs protect the model workers. The measured runtime policy identifies containers; workers verify GPUs before activation. This is scoped to the documented verified API deployment.
Why Stage 1?
Stage requirementsAt least one content layer has independently checkable technical evidence, including partial proof within a layer. The full privacy boundary is incomplete. The stage tooltip distinguishes partial findings from fully met requirements for Stage 2.
STEPS FOR STAGE 2
2 of 3 requirements for Stage 2 met. Missing proof: Logs & storage.
- Request pathMet
Private inputs and outputs across the request path, with E2EE or an equivalent attested channel that protects against intermediaries and binds keys to the accepted workload.
Independently auditable. Attestation before key exchange
- Inference executionMet
Protected inference with a verifiable workload identity and protection covering the CPU, GPU and every place content is processed.
Independently auditable. Containers + verified GPUs
- Logs & storageNot established
No content logging, persistent storage, human review or training. Any temporary content-derived cache must have verifiable isolation and enforced removal.
Documented only. Isolated blocks until eviction
Identity and operational metadata are assessed separately below. They do not set the content stage; prompt or response content in telemetry remains part of the content-retention assessment.
Request path
Independently auditableVerified proxy / SDK. The client checks the coordinator and expected manifest before exchanging keys with the attested secret service. Only admitted workers receive prompt keys. Public, reproducible code and independently derived reference values support auditing; clients must review and pin the deployment they accept.
Inference execution
Independently auditableMeasured workers. The runtime policy pins workload images and configuration. GPU activation is gated by in-worker verification. Model disks are read-only and integrity-checked with dm-verity. These checks can be inspected through public code and reproduced reference values, subject to the accepted deployment manifest.
Logs & storage
Documented onlyCache removal gap. The service documents no persistent content storage or training. KV blocks remain inside confidential CPU/GPU memory. The proxy uses a fresh salt per request by default, preventing reuse, but old blocks can remain until eviction under memory pressure. Losing or rotating a salt prevents lookup; it does not erase those blocks. The reviewed design establishes isolation, but no bounded expiry or verified clear operation sufficient to establish cache removal for Stage 2.
Identity & metadata
Documented only90-day operations. The provider documents up to 90 days for IP addresses, API keys, timing and operational request metadata. Per-key token usage is retained permanently for billing. Some routing fields are unencrypted. This establishes declared collection and retention, not technically verified deletion.
Remaining trust assumptions
- AMD or Intel CPU isolation, NVIDIA GPU isolation and vendor attestation roots.
- Contrast coordinator, secret service, measured worker policy and the locally trusted verifier.
- Reviewed and pinned manifest/reference values; accepting arbitrary future manifests delegates update trust.
Limits of this assessment
- Proxyless calls do not receive the client-verification assurance assigned here.
- Confidential prompt caching does not eliminate timing risks by itself; cache isolation matters.
- A new cache salt prevents reuse but does not erase old content-derived blocks; their removal lifetime remains unresolved.
- Operational and billing metadata remain visible and retained.
Primary-source record
6 sources · reviewed 2026-10-06
Sources reviewed 2026-10-06