/confidential/explainer
What is confidential computing?
A hardware feature that encrypts a VM's memory while it's running. The hypervisor, the host kernel, the physical machine — none can read it. The CPU does the encryption; the keys never leave the silicon.
| Technology | Vendor | What it does | Availability |
|---|---|---|---|
| AMD SEV-SNP | AMD | Encrypts VM memory; attests the launch was untampered | Azure DCasv5, GCP N2D |
| Intel TDX | Intel | Trust Domain Extensions; encrypts + isolates from host | GCP C3, Azure DCesv5 |
| Arm CCA | Arm | Realm management; memory encryption + attestation | Maturing (future) |
confidential tier uses AMD SEV-SNP today · Intel TDX planned
/confidential/why-agents
Why this matters for AI agents
An autonomous agent is a worst-case in the threat model — all three of these at once:
- 01
It runs untrusted code — generated from a prompt, a tool call, or adversarial input.
- 02
It touches sensitive data — credentials, PII, proprietary data, all held in memory.
- 03
It runs on infrastructure you don't fully control — the provider's hypervisor can read VM memory.
Without confidential computing
/confidential/attestation
The two-layer binding
Key release is gated on two independent proofs. A forged report fails layer 1; a replayed one fails layer 2. Only a genuine SEV-SNP CVM, running right now, with the anchored key, produces evidence the control plane accepts.
Hardware anchoring
- VCEK-signed AMD SNP report
- VCEK chain → genuine AMD Milan ARK
- SHA256(var_data) == REPORT_DATA[..32]
- binds the vTPM AK into the report
Freshness + nonce
- tpm2_quote signed under the AK
- covers SHA256(canonical_report_data)
- fresh, unreplayable per-request nonce
- only the live anchored AK can sign it
control-plane gate
both layers must hold — else nothing is released
DEK released on attestation match — workspace secrets unsealed
The gate is over attestation evidence, not over key material: the DEK is wrapped under a software KEK held by the runtime. Hardware-binding via AWS KMS is a tracked follow-on.
/confidential/single-cvm-direct
Why not nesting?
You might expect: boot a confidential VM, then run microVMs inside it. That's architecturally impossible on managed cloud.
AMD SEV-SNP strips the hardware virtualization extensions from the leaf guest — a confidential VM cannot also be a hypervisor. Verified on silicon: /dev/kvm is absent on a DCasv5; the svm CPU flag is zero.
So the confidential tier runs the workspace directly inside the CVM — no nested microVM. The CVM is the boundary; OpenShell provides in-process governance. One CVM per sensitive workspace.
/confidential/proof
The proof
- nesting block confirmed/dev/kvm absent · svm=0
- OpenShell sandbox spawned in-CVMok
- command ran over the SSH control channelok
- attestation produced 2-layer evidenceL1 + L2
- control plane released the DEKon evidence
- seal → unseal restored plaintextbyte-identical
read the full bring-up report