confidential agent execution
Hardware-attested execution boundary.
Give every AI agent a governed sandbox — a Firecracker microVM (own kernel) on the standard tier, or an OpenShell sandbox inside a hardware-attested SEV-SNP CVM on the confidential tier. Self-hosted. Apache-2.0.
curl -fsSL https://github.com/Mindpool-Labs/ne-enclave/releases/latest/download/install.sh | sh- Apache-2.0
- Rust
- Firecracker
- SEV-SNP confidential mode in preview
/runtime/options
Every agent execution option has a catch
NeuronEdge Enclave is the fourth option — self-hosted Firecracker microVMs with optional hardware-attested confidential mode. You own the infrastructure; the agent can't escape it.
Containers (Docker, gVisor)
Share a kernel with the host. Container escapes are real — and agent-generated code is exactly the threat model where a shared-kernel boundary isn't enough.
Managed sandboxes (E2B, Modal)
Solve isolation but move your data to someone else's infrastructure. Regulated enterprises routinely can't get them approved: residency, DPAs, attestation gaps.
No boundary
Agents run on the developer's laptop or a shared CI runner. The blast radius of a compromised agent is the whole machine.
NeuronEdge Enclave
Separate kernel per workspace, optional SEV-SNP encryption + attestation. Self-hosted, open-source, governed.
/runtime/thesis
Four words, each load-bearing
- hardware-attested
- Secrets are released only when attestation evidence matches policy. The evidence primitive was exercised on Azure DCasv5 silicon; the confidential lane it belongs to is still preview.
- agent execution
- Primitives (create / exec / snapshot / fork / destroy) built for agent planning loops, not human dev environments.
- customer-owned
- A self-hostable binary. Single-host for evaluation, multi-host for production. Your infrastructure.
- apache-2.0
- The runtime is open-source forever. No vendor lock-in on the execution layer.
/runtime/status
What is supported, and what is not
Mirrored from the runtime's public capability ledger. The standard profile is supported; the Azure confidential profile is preview until its signed release gate passes. We publish the unpromoted rows because those are the ones a regulated buyer has to see.
- Firecracker microVM isolation (separate kernel per workspace)supported
- gRPC + REST API + CLI + Python/TypeScript SDKssupported
- Per-workspace networking (netns + TAP + deny-by-default egress)standard profile · subject to documented limitssupported
- PII redaction on egress (openshell-pii, via the privacy router)HTTP/1.1 cleartext · regex tier-1 · request direction · opt-in per workspacepartial
- Credential rewriting on egressplanned
- Runtime supply-chain enforcement (OSV / OPA / CVSS)ships in our OpenShell fork; not yet absorbed into the runtimeplanned
- Signed, independently-verifiable audit event streamsupported
- Snapshot / restore / fork / live-state snapshotstandard profile only · not implemented for confidential-azuresupported
- Warm pool (pre-forked microVMs, ~2ms pool-hit create)supported
- Host-based ingress routingsupported
- Single-binary self-host install + hardened systemd unitssupported
- Confidential execution (confidential-azure — SEV-SNP CVM, one workspace per CVM)promotion gated on the signed v0.2.0 Azure artifact runpreview
- Azure vTPM SEV-SNP evidence primitive (2-layer TPM-Quote binding)attests the host-CVM/OpenHCL launch, not workspace guest codeverified
- Signed release bundle, SPDX SBOM, Sigstore provenanceimplemented for the v0.2.0 candidate; no release evidence until the gates passpartial
- Sealed-snapshot key release against a live KMSsoftware KEK today · AWS KMS backend is mock-tested onlyplanned
- Intel TDX confidential modeplanned
- Per-microVM hardware attestation (bare-metal SNP)v2
/runtime/tiers
Standard and confidential, one runtime
Selected by a single environment variable. Nothing else in your code changes.
Standard tier
defaultEach workspace is a Firecracker microVM with its own kernel. Real isolation for multi-tenant or untrusted-code workloads.
Confidential tier
DCasv5The workspace runs inside an AMD SEV-SNP CVM. Memory is encrypted, the cloud operator is excluded, and key release is gated on hardware-rooted attestation evidence.
same API · same SDKs · same audit surface
/runtime/attestation
How the proof is made
Confidential mode is a chain of trust. Each link is checked before anything downstream is trusted — including the secrets your agent needs.
- launch
CVM launched
OpenShell sandbox inside an attested SEV-SNP VM
- measure
CVM launch measured
host launch digest (UEFI + paravisor TCB)
- attest
SEV-SNP attests
hardware-signed report + TPM-Quote nonce
- verify
evidence verified
checked against policy, anchored to AMD ARK
- release
key released
only on a policy match (software KEK today)
- sign
event signed
appended to audit chain
/runtime/foundations
Built on credible foundations
# production-credible, Apache-2.0, battle-tested
[dependencies]
- openshell = "agent-sandbox governance — Landlock/seccomp/netns + L7 OPA"↗
# NVIDIA OpenShell, forked
features = ["pii-redaction", "supply-chain"]
Mindpool-Labs contributions to the fork
- firecracker = "the microVM substrate that powers AWS Lambda"↗
- amd-sev-snp = "hardware memory encryption + attestation"→
- rust = "memory-safe infrastructure, top to bottom"→
Run your next agent in a hardware-isolated, governed sandbox.
Looking for design partners — regulated enterprises (finance, healthcare, government) evaluating confidential agent execution. If your CISO has blocked an agent deployment on isolation or attestation grounds, we'd like to talk.
dev@mindpool.io →