.png){kind=logo}
Your virtual machines, sealed at the silicon
Buckypaper runs the VMs you already have inside hardware-enforced trusted execution environments — memory encrypted during execution, the operator excluded, every boot attested. No changes to your workloads.
Migrating an estate? Buckypaper is the landing zone of the VMware exit.
The VM you know, inside a boundary nothing else can read
A Buckypaper VM behaves like any virtual machine your team operates today — same images, same tooling, same lifecycle. The difference is where it runs: inside a hardware enclave whose memory is encrypted during execution, with keys that never belong to the infrastructure and release only against a successful attestation of the exact VM state you approved.
That single change removes the assumption the rest of your security stack exists to compensate for — that whoever operates the host can read the guest. Hypervisor administrators, cloud operators and anyone with physical access to the machine hold no readable path to the workload. It's the operator-exclusion mechanism, packaged as the most familiar unit in infrastructure: a VM.
Each is enforced in hardware and evidenced cryptographically, not asserted in a report.
VM memory stays encrypted while the workload executes — the in-use gap that at-rest and in-transit encryption leave open is closed at the silicon.
Every VM proves its integrity cryptographically before keys release: the image, configuration and platform state are measured, and evidence is available for your auditors on demand.
Disk and secret keys live in vHSM/Vault under your custody — released to a VM only when its attestation matches policy, never held by the host.
NIST-standardized algorithms protect VM encryption against “harvest now, decrypt later” — the property that made Buckypaper part of the NATO DIANA architecture.
Existing images move into confidential VMs without application changes — which is what keeps migration projects scoped in weeks.
European providers, hyperscalers, or your own datacenter — the protection model is identical, so placement follows your requirements, not the architecture's.
Workload starts
Code, config and platform state measured by the CPU
Evidence produced
Hardware-rooted attestation report, signed
Policy checked
Nitride verifies the measurement against your policy
Keys released
vHSM and vault unseal — only now, only to this workload
Workload starts
Tampered image, injected container or rogue host
Evidence produced
Measurement does not match what you approved
Policy rejects
Mismatch logged with its reason, for the audit file
Nothing released
No keys, no secrets — the data stays ciphertext
What teams ask about Buckypaper
Do we have to modify our VM images?
No — existing images run inside confidential VMs without application changes. The enclave boundary is provided by the platform and the underlying silicon, not by your code.
What's the performance impact?
Memory encryption runs in hardware, designed to preserve computing performance.
How does this relate to Dyneemes and eMCP?
Buckypaper is the VM tier; Dyneemes is the Kubernetes tier that can run on it; eMCP is the control plane operating both across your clouds. Most estates run all three.
Bring an image. Watch it seal
A representative VM, your cloud of choice, attestation evidence at the end — the shortest possible path from claim to proof.
Coming from VMware? The exit path. Kubernetes estate? Dyneemes.
