← Back to blog

    I Asked Opus 4.6 to Fingerprint Sandbox Vendors

    Mohamed Habib · March 17, 2026

    Disclaimer: All fingerprinting was performed by Claude. There may be inaccuracies — this is not intended to be a thorough or definitive audit, but rather a curiosity-driven exploration.

    I've been very curious about the types of isolation, hardware and machines that power all the available sandbox providers. It seems that there is no one solution but a series of tradeoffs which govern startup time, security isolation levels and general platform scalability. There is an excellent overview of the types of isolation here.

    What I was more interested in is what the agent that launches a VM sees from the inside. What does it look like and what can we learn about the platform based on what we see inside the sandbox VM. With the help of claude I wrote some fingerprinting code to inspect each platform: github.com/diggerhq/sandbox-fingerprinting. I also tried to fact check this information based on what each provider has made publicly available. I hope to be corrected if there is any incorrect information in the results. Without further ado lets dive into the results.

    Executive summary

    Without going into too much of the details, here are the overview of where each platform is hosted, what the host machines of the sandboxes look like and the types of isolation provided.

    E2B

    Hardware (KVM)

    Host: GCP

    CPU: Intel Xeon @ 2.60GHz

    Isolation: Firecracker microVM

    Daytona

    Container (cgroup v2)

    Host: Hetzner bare-metal

    CPU: AMD EPYC 9254 24C/48T

    Isolation: Docker + Sysbox

    Modal

    Kernel (syscall)

    Host: Azure

    CPU: AMD EPYC

    Isolation: gVisor (on Azure VM)

    Blaxel

    Hardware (KVM)

    Host: AWS

    CPU: Intel Xeon @ 2.90GHz (Ice Lake)

    Isolation: Firecracker + Unikraft

    Sprites

    Hardware (KVM)

    Host: Fly.io

    CPU: AMD EPYC

    Isolation: Firecracker microVM

    exe.dev

    Hardware (KVM)

    Host: Latitude.sh bare-metal

    CPU: AMD EPYC 9554P 64C

    Isolation: Cloud Hypervisor VM

    Isolation spectrum

    Container

    Shared host kernel, lightweight

    Daytona Sysbox

    Modal gVisor

    microVM

    KVM-backed, minimal overhead

    E2B Firecracker

    Blaxel Firecracker + Unikraft

    Sprites Firecracker

    Full Hypervisor

    EC2-like, highest isolation

    exe.dev Cloud Hypervisor

    Isolation categories

    Container level isolation

    Both Modal and Daytona are relying on container-based isolation with different takes. Sysbox is a project to make containers behave more like VMs. gVisor adds an additional layer for containers so that they are not vulnerable to escape attacks to the host kernel. Since containers in general share the host kernel this is important to offer an additional level of isolation when running fully untrusted code. The advantage of container isolation is that it is super lightweight and already widely used from the k8s world.

    microVM level isolation

    Firecracker seems to be a common choice amongst providers and wisely so. It is a battle tested solution already powering projects like AWS Lambda. E2B, Blaxel and Sprites are relying on this tech. Of interest it seems that Blaxel is layering unikernels on top of Firecracker VMs, which makes me curious on the reason behind that. Perhaps it is to further reduce the startup time of the sandbox providers.

    Hypervisor isolation

    Offering a full hypervisor means the sandboxes offer highest level of isolation and matching EC2-like behaviour. But it comes with its own penalties of course around startup time and memory overhead for the platform host machine. Only exe.dev seems to be taking this path so far, relying on Cloud Hypervisors for their platform. Excited to see more platforms based on hypervisors.

    There is no one-size-fits-all. The choice between container, microVM, and full hypervisor isolation is a tradeoff between startup time, security guarantees, and platform complexity.

    Detailed fingerprints

    In case you are curious about more of the details here are some more detailed fingerprint reports from each platform. Since I was testing it from SF the region mentioned is likely based on proximity to my location.

    E2B

    Firecracker

    Infrastructure

    HypervisorFirecracker (confirmed by ACPI OEM ID FIRECK)
    KVM backendYes
    Host CPUIntel Xeon @ 2.60GHz (Cascade Lake/Ice Lake, AVX-512)
    HostingGoogle Cloud Platform
    ASNAS396982 Google LLC
    LocationThe Dalles, Oregon

    VM Specs

    2

    vCPUs

    482 MiB

    RAM

    22.9 GiB

    disk (ext4)

    None

    swap

    Daytona

    Docker + Sysbox

    Infrastructure

    HostingHetzner (AX-series dedicated)
    CPUAMD EPYC 9254 24-Core / 48 threads — bare metal
    RAM384 GiB (377 GiB visible)
    StorageSoftware RAID — 439 GB ext4 + 3.5 TB XFS
    Host OSUbuntu 24.04 LTS, kernel 6.8.0-94-generic
    RuntimeDocker Engine + Sysbox (Nestybox)
    cgroupv2 unified hierarchy

    VM Specs

    1

    CPU core

    1 GiB

    RAM (cgroup)

    3 GiB

    root overlay

    172.20.x

    Docker bridge

    Modal

    gVisor

    Infrastructure

    IsolationgVisor (confirmed by kernel cmdline, dmesg, env var)
    Host kernelHidden; gVisor presents fake "4.4.0"
    Host CPUAMD EPYC (AMD-specific flags: sse4a, misalignsse, topoext)
    CloudMicrosoft Azure
    Regioneastus
    Public IPNot accessible (no outbound internet)

    Modal's gVisor leaks the host's full 448 GiB memory through /proc/meminfo — a known gVisor behaviour, not the actual container allocation.

    VM Specs

    1

    vCPU (default)

    ~448 GiB

    visible RAM *

    512 GiB

    root (9p mount)

    16 GiB

    /dev/shm

    Blaxel

    Firecracker + Unikraft

    Infrastructure

    HypervisorFirecracker (confirmed by MPTABLE: OEM ID: FC)
    UnikernelUnikraft (unikraft in kernel cmdline, ukp-fuse mount)
    Host CPUIntel Xeon @ 2.90GHz (Ice Lake — AVX-512 VNNI, VBMI2)
    HostingAWS us-west-2 (Portland, Oregon)
    InstanceLikely c6i or m6i (Xeon Platinum 8375C)

    Unikraft signals detected

    unikraft in kernel cmdline

    Unikraft framework driving the boot

    ukp_initrd block device (~203 MiB)

    Compressed base filesystem image

    ukp-fuse on /uk/libukp

    Unikraft platform library via FUSE

    PID 1: /init unikraft /bin/metamorph-wrapper

    Custom init chain

    VM Specs

    2

    vCPUs

    3.8 GiB

    RAM

    1.9 GiB

    ramfs (no disk!)

    None

    swap

    Sprites

    Firecracker
    HypervisorFirecracker (kernel cmdline, MPTABLE OEM ID)
    KVM backendYes
    Host CPUAMD EPYC (model masked by Firecracker)
    HostingFly.io own infrastructure
    IPv4 exitCacheFly transit (AS30081), Los Angeles
    IPv6Fly.io allocation (AS40509)

    exe.dev

    Cloud Hypervisor

    Infrastructure

    HypervisorCloud Hypervisor (Intel/open-source, not Firecracker or QEMU)
    KVM backendYes
    Host CPUAMD EPYC 9554P 64-Core (single-socket, Zen 4 Genoa)
    HostingLatitude.sh bare metal (AS396356, Los Angeles)
    MetadataCustom JSON at 169.254.169.254 — NOT AWS/GCP/Hetzner format

    VM Specs

    2

    vCPUs (no SMT)

    7.2 GiB

    RAM (dedicated)

    18.6 GiB

    virtio-blk ext4

    None

    cgroup limits

    The fingerprinting code and full raw results are available on GitHub. If you spot any inaccuracies or have additional data points, please open an issue or PR.