/security/posture
Security posture at a glance
Two execution tiers. Signed audit. Open source. The security model is the product.
Per-workspace kernel isolation via Firecracker + jailer (chroot, cgroups, seccomp, namespaces). The host operator is trusted.
The workspace runs inside an AMD SEV-SNP CVM — operator-excluded, hardware-attested. Key release is gated on a two-layer binding validated to the genuine AMD Milan ARK. The lane stays preview until the exact signed v0.2.0 candidate passes its Azure artifact gate.
Every workspace action is a signed event in an independently-verifiable Merkle chain. Any party holding an exported manifest can detect edits, broken links, and tail truncation.
Apache-2.0. The runtime code is public, auditable, and forkable. No security-through-obscurity.
/security/claim-ceiling
What's proven — and what's honestly not
We publish the full ceiling because the honest claim is the product. No overclaim.
Per-workspace kernel isolation (Firecracker + jailer)
Standard profile · lifecycle e2es boot real Firecracker via jailer
Signed, independently-verifiable audit chain
nee audit export + nee audit verify
Azure vTPM SEV-SNP evidence primitive
DCasv5 2026-06-29; 2-layer TPM-Quote binding, validated to the baked Milan ARK
Confidential agent execution (confidential-azure profile)
DCasv5 2026-06-30 round-trip passed; promotion gated on the signed v0.2.0 artifact run
Operator-excluded memory encryption
SEV-SNP: the cloud operator sees ciphertext — within the preview lane above
Attestation-gated key release (sealed snapshots)
CP WASM gate → DEK; seal→unseal byte-identical. Software KEK, not KMS-bound
Confidential snapshot / restore / fork
Not implemented — the profile contract rejects these operations
Runtime supply-chain enforcement (OSV/OPA/CVSS)
Not implemented in standard workspaces; lives in the OpenShell fork
Per-workspace hardware isolation (nested SNP)
Impossible on managed cloud (AMD strips virt extensions)
Guest-code measurement
TCB = host-CVM/OpenHCL launch, not agent code. Tracked follow-on
KMS-hardware-bound key release
Software KEK (no HSM); the AWS KMS backend is mock-tested only, never run against a live account
mTLS runtime↔control-plane
API-key over TLS today
Intel TDX
Needs DCesv5 silicon
Honest ceiling
/security/threat-model
The threat model in plain language
what the confidential tier protects against
A compromised cloud operator reading live workspace memory
SEV-SNP memory encryption excludes the cloud operator from live CVM memory — under subpoena they can produce only ciphertext. (Note: this covers live memory only; sealed-snapshot key material is wrapped under a software KEK — see below.)
A compromised host kernel
SEV-SNP integrity protection detects tampering with the CVM's memory pages.
A replayed attestation
The two-layer binding (boot-fixed report + fresh TPM-Quote nonce) means stale or replayed evidence is rejected. Only the live, hardware-anchored key can sign a fresh quote.
what it does not protect against
A compromised agent producing wrong outputs
NeuronEdge Enclave solves execution-boundary safety, not agent alignment. A jailbroken agent contained by Enclave cannot escape the microVM/CVM boundary by design — but it can still produce incorrect or harmful results within its workspace.
Side-channel attacks on the CVM
SEV-SNP has known side-channel limitations (cache timing, etc.). This is a property of the hardware, not of Enclave. We name it honestly.
The paravisor (Azure only)
Azure's OpenHCL paravisor is inside the measured, attested set. On Azure the TCB honestly includes it; the VCEK→ARK signature chain is identical. The bare-metal/GCP (/dev/sev-guest) attestation arm is implemented but not yet silicon-validated — only the Azure OpenHCL arm is verified today.
A runtime insider holding the key-encryption key
Sealed-snapshot data-encryption keys are wrapped under a software KEK held by the runtime/Worker, not hardware-bound to a KMS. The attestation gate is over evidence (policy match), not over key material — an insider with the KEK can unseal. Hardware-binding via AWS KMS is a tracked follow-on.
/security/attestation
Exercised on Azure DCasv5 silicon
The confidential profile is not a slide-deck claim — this round-trip ran on real AMD silicon. It is still preview: the ledger promotes a lane only once the exact signed candidate passes its artifact gate and publishes without a rebuild.
- Nesting block confirmed empirically (/dev/kvm absent, svm cpu flag absent — AMD SEV-SNP strips virtualization extensions from the leaf guest)
- OpenShell sandbox spawned in-CVM
- Command ran over the SSH control channel
- Attestation evidence produced (2-layer binding: boot-fixed report + fresh TPM-Quote nonce)
- control plane released the DEK only on that evidence
- seal→unseal restored byte-identical plaintext