E2B gives agents a computer. What gives them a microcontroller?

Ask an agent to write a UART driver for an nRF52840, then ask it to prove the driver works. It can spin up an E2B sandbox in under 200 milliseconds. It can install Python, Node, a compiler, a whole Debian userland, in about a second. It cannot spin up a UART. There's no pip install nrf52840 for the thing the driver is actually supposed to talk to.

That's a gap in the whole AI agent sandbox category, and nobody selling one is hiding it — because until an agent needs to touch real hardware, it was never their problem to solve.

What the AI agent sandbox boom actually solved

The sandbox market exists because agents got hands. Give a model a shell and a filesystem and eventually it rm -rfs something it shouldn't, or gets prompt-injected into downloading a binary and running it — that exact chain, from a poisoned webpage to a live command-and-control connection, is a documented security-research finding, not a hypothetical.¹ The fix was cutting the blast radius: give the agent its own disposable machine instead of yours.

By 2026 that idea is a whole industry. E2B boots an isolated Firecracker microVM in around 200ms and hands the agent a shell, a filesystem, and a network namespace.² Modal does roughly the same job on gVisor, with GPU access if the workload needs it.²³ Daytona, Northflank, Blaxel, CodeSandbox, Fly.io — each with different isolation primitives and pricing models — all follow the same pattern. E2B's own pitch is refreshingly literal about the scope: "if you can run it on a Linux box, you can run it in the E2B sandbox."⁴

That's the whole category: a Linux box.

They all stop at the same place

A sandbox is a fence around a kernel. Firecracker draws that fence with hardware virtualization — every sandbox gets its own guest kernel, and a compromised guest can't see past its own VM boundary. gVisor draws it differently: a userspace process intercepts every syscall the guest tries to make and decides what the host actually sees.⁵ Everything a sandbox protects and grants is defined in terms of what a process on a Linux-shaped kernel is allowed to do.

You can see how literally that's true in what Firecracker actually emulates for the guest: network, block storage, and a serial console. That's the device list.⁵ No GPU passthrough by default, no GPIO, no raw bus access — because none of that exists on the other side of a syscall either. The fence sits exactly where the OS abstraction sits, because that's the only boundary the isolation technology knows how to reason about.

Firmware doesn't have a syscall table

A large share of the code an agent might be asked to write has no syscall table to sandbox in the first place.

Bare-metal firmware on a Cortex-M or a RISC-V microcontroller doesn't run on top of a kernel. It is the closest thing to one, in the sense that matters: it owns the reset vector, it initializes its own clock tree before main is even reachable, it handles its own interrupts through a vector table it wrote itself, and it talks to a UART or an SPI bus by writing to a specific memory address — not by calling a library that calls a driver that calls a syscall. There's no userspace to fence off, because there's no kernel underneath granting it one.

A microVM protects a guest kernel from a host kernel. That's a real, well-understood problem, and Firecracker and gVisor solve it well. It is also a completely different problem from "does this firmware sequence the clock-enable bit before it touches the UART's baud-rate register" — a question a Linux sandbox has no vocabulary for, because the answer lives below the exact layer sandboxes were built to isolate.

I've made the proving-it-works half of this argument before: LLMs can write firmware, but proving it runs is the part they can't do. This is the sandbox half. What agents need when the target is embedded hardware, next to what a Linux sandbox actually hands you:

What firmware work needs	What a Linux sandbox gives you
A specific ISA (Cortex-M, RISC-V) with no OS underneath it	A guest kernel on x86-64 or ARM64
Memory-mapped peripheral registers: GPIO, UART, SPI, I2C, ADC, timers	virtio network, virtio block, serial console — the only devices Firecracker models5
A real interrupt vector table and ISR-level timing	The guest's own virtualized interrupts, invisible to "your" process
A reset vector and clock-tree init before anything else runs	An init process that's already running by the time you connect
Bus-accurate timing: baud rates, clock gating, peripheral state machines	Wall-clock time from the host scheduler
Often: no filesystem, no TCP/IP, no syscalls, no OS at all	A full POSIX filesystem, network namespace, and package managers
A debug/flash interface — SWD, JTAG, some way to observe silicon	SSH or a PTY into a Linux shell

None of this is a knock on E2B or Modal. They built exactly what the market asked for: safe, fast, disposable compute for code that assumes a Linux box underneath it. Firmware is the workload that doesn't — not out of neglect, but because the hardware it targets was never designed to run an OS at all.

The empty column

Go read any "E2B alternatives" or "best sandboxes for AI agents in 2026" comparison post — there are plenty now, and the good ones are genuinely useful, stacking up boot time, isolation model, pricing, GPU support, BYOC.²³⁶ Not one has a column for "can this run my firmware against something that models the actual chip." It's not an oversight; it's just not the axis those products compete on. (Every layer of the agent stack has been getting its own dedicated infra company lately — search, memory, browser, compute — and the hardware slot is a familiar kind of empty. I mapped the rest of the agent infrastructure stack elsewhere; this post is just the hardware slot.)

The specific version of that gap is this: you can't syscall-intercept your way to a chip that doesn't have syscalls. Isolation technology, however clever, is built to sit at a boundary that has to already exist. Below the register level, there isn't one.

What actually has to sit below the line

Filling that gap honestly means building something that isn't a sandbox at all. What firmware work needs is a model of a specific chip — its registers, its peripherals, its interrupt timing, its boot sequence — accurate enough that running a real ELF against it produces a real answer: did the UART actually transmit, did the state machine ever leave its init state, did the firmware hang forever waiting on an event that will never fire. That's a different kind of emulator wearing none of the isolation machinery above, because there's no host kernel to protect anyone from in the first place.

That's the specific gap my own team works on, so I'll name it once and move on. Chiplab runs real firmware ELFs against simulated STM32 and Nordic boards⁷ — not a Linux VM with extra steps, but a peripheral-level model of the silicon a given microcontroller target actually compiles for. It's early, and it doesn't replace a bench any more than a Linux sandbox replaces a datacenter. It's just the shape of thing that has to exist below the syscall line, because nothing above that line was ever going to reach it on its own.

That's the same shift I trace more broadly in why hardware is becoming an API for agents — this post is just the sandbox-shaped slice of it.

Can an AI agent sandbox run firmware for a microcontroller?

No, not the ones on the market today. E2B, Modal, Daytona, Northflank, Blaxel, CodeSandbox, Fly.io — every one of them isolates a Linux-shaped kernel boundary, whether that's Firecracker, gVisor, or Kata underneath. A microcontroller's firmware runs below that boundary: no OS, no syscalls, nothing to virtualize. What you need there isn't a sandbox. It's a model of the chip itself.

The loop breaks at the machine

E2B, Modal, and the rest solved something real: safe, fast, disposable compute for agents that assume a Linux box. That's most agent workloads, and the category earned its funding rounds fair and square.

But "give the agent a computer" and "give the agent a chip" aren't the same sentence with one word swapped. One ends at a syscall table; the other starts below it, on hardware that was never designed to have an OS looking over its shoulder. Every chip is an island, and no amount of Firecracker builds a bridge to one — because the bridge has to be a different kind of thing entirely.

Sources

Footnotes

1. Firecrawl, "AI Agent Sandbox: How to Safely Run Autonomous Agents in 2026," citing Johann Rehberger, "ZombAIs: From Prompt Injection to C2 with Claude Computer Use," 2024. https://www.firecrawl.dev/blog/ai-agent-sandbox ↩

2. Northflank, "E2B vs Modal: comparing AI code execution sandboxes in 2026." https://northflank.com/blog/e2b-vs-modal ↩ ↩² ↩³

3. Blaxel, "E2B Alternatives: Sandbox Environments for 2026." https://blaxel.ai/blog/e2b-alternatives-sandbox-environments ↩ ↩²

4. E2B, official site. https://e2b.dev ↩

5. SoftwareSeni, "Firecracker, gVisor, Containers, and WebAssembly — Comparing Isolation Technologies for AI Agents." https://www.softwareseni.com/firecracker-gvisor-containers-and-webassembly-comparing-isolation-technologies-for-ai-agents ↩ ↩² ↩³

6. Jimmy Song, "The New Era of Cloud Agent Infrastructure: In-Depth Analysis of E2B and Browserbase Global Trends." https://jimmysong.io/blog/e2b-browserbase-report ↩

7. Chiplab. https://veecle.ai/chiplab ↩