This is why we built runmvm.com
Cybersecuirty for AI is moving fst. a16z.news/p/the-new-security…
Is your stack attackable?
If it runs PHP, yes.
MVM limits the damage.
Read more here: runmvm.com/blog/php2shell-no…
AI agents just poked at U.S. government systems without their own operators knowing.
The problem isn't the model. It's that nobody defined what the agent was allowed to execute.
That's what we're building. Our first video 👇
runmvm.com
~100 malicious models on Hugging Face. No CVE, because pickle was working as designed.
Every one of them would've been a non-event inside mvm: scanned before load, and sealed in a microVM with no network and no credentials even if missed.
runmvm.com/blog/huggingface-…
The scariest outages aren't when something dies. They're when everything is technically up and lying to each other: a healthy node serving stale data, retries turning one 200ms hiccup into a self-inflicted flood. Crashes page you. Ambiguity ruins your night.
Kubernetes has no idea what a container actually is. It hands the whole thing to a runtime over a socket and trusts whatever comes back. That CRI boundary is exactly why you can swap runc for crun for kata and the scheduler never notices. Best abstraction in the whole stack.
Flue showed up in this week's issue: an open agent framework that treats execution as something you sandbox from the start. Nice to see isolation baked in at the framework layer instead of bolted on after the first incident. flueframework.com/ this-week-in-microvms.com/
Hyperlight runs a microVM with no kernel and no OS inside it — just your function in a hardware-isolated address space. Boot drops to microseconds because there's nothing left to boot. Different bet than Firecracker: isolate the function, not the machine.
Building a micro Linux distro from scratch is the fastest way to see why microVM boots are so fast: you watch exactly how little sits between power-on and userspace. Good read in this week's issue. popovicu.com/posts/making-a-… this-week-in-microvms.com/
Memory ballooning is how a microVM hands RAM back to the host without a reboot: the guest inflates a balloon of pages it promises not to touch, and the host reclaims them. Great density trick, until you hit real memory pressure and it bites.
AWS put a name on the substrate: Lambda now runs on published MicroVMs. Serverless was always Firecracker underneath — but saying it out loud makes per-request isolation the default people expect. aws.amazon.com/about-aws/wha… this-week-in-microvms.com/
This Week in MicroVMs №4 is out.
AWS just put the word "microVM" on a product page — Lambda MicroVMs ship for user- and AI-generated code. Plus Edera on multi-tenant workloads, BSidesCharm's case for microVMs, and Flue.
this-week-in-microvms.com/
We spent fifteen years teaching hypervisors to do more — live migration, hotplug, full device models — and the winning move for cloud was to delete most of it. Firecracker is basically Xen's lessons run in reverse.
What I track each week is basically: which VMM shipped something, which sandbox showed up new, and which CVE proved a boundary was thinner than people assumed. This week had all three. this-week-in-microvms.com/
Run MVM retweeted
Vital for understanding how microVM sandboxes work in particular.
Whenever I post about building a Linux distro, someone says "just do Linux From Scratch."
LFS is great. It's also a weekend of compiling before you boot anything.
You can grasp the core idea in 10 minutes instead.
A distro is two things: the kernel and user-space binaries. When the kernel finishes booting, it hands control to exactly ONE process: init. Your shell, your apps, your services all descend from it.
That's the entire model. You can prove it with an init that's just "Hello World," then scale up to something like systemd when you want to.
Lightweight build, running in 10 minutes: popovicu.com/posts/making-a-…
per-request VMs sound absurd until you realize nobody fast actually boots them. the whole game is getting a VM to exist without running a boot path. once you internalize that, the cold-start economics flip.
fork pushes it further. keep one warm parent paused, then copy-on-write the memory for each child. children share pages until they write, so you spin up a swarm off one snapshot without re-paying the per-VM memory cost. cold start becomes a memory-mapping problem.
forkd is a clean example of this aimed squarely at agents: ~100 child VMs in ~100ms off a single parent. that's the math that makes a fresh isolated VM per agent action — per tool call, per generated snippet — actually affordable. github.com/deeplethe/forkd this-week-in-microvms.com/
