Object storage platforms purpose-built for AI agent sandboxing

Here's the thing nobody tells you until an agent chews through your storage bill: agents don't just fetch data anymore. They write to a workspace, run code against it, crash, come back an hour later, and expect the files to still be sitting right where they left them. That's a filesystem problem wearing a storage problem's clothes, and most of the industry built the wrong layer to fix it. I've watched this happen at three different companies now, and the pattern never changes.

Let me tell you about the first time I saw this go sideways. A team I worked with had an agent running a multi-hour data pipeline, checkpointing every few minutes to what they assumed was a normal disk. It turned out to be an object store wearing a filesystem costume, and when the agent tried to flock a file mid-write, nothing happened. not an error, not a crash, just silence, the software equivalent of asking a mannequin for directions. Three hours of work vanished, because the storage layer had nodded along without understanding a word.

Start with the basics, which turn out to be less basic than they sound.

Agents running bash, editing files, pushing commits, all of that expects POSIX behavior: atomic rename, hard links, symlinks, sparse files, flock/fcntl, mmap. That's the native tongue of every Linux tool ever written. Object storage speaks a different dialect entirely, one where trying to flock an S3 object or mmap a GCS blob gets you nothing but silence. The instant an agent runs a real command against a real file, something has to translate between these two worlds, and that translation is exactly where latency and the weirdest bugs you've ever debugged go to hide.

Then there's the read pattern, which is its own small nightmare. Agents make tiny, random reads, a few KB here, a couple MB there, grabbing a config file or a log fragment mid-task, and they want it back in under a millisecond. A cold GET from an object store takes seconds instead, and doing that math across a few thousand file touches in one session means you've built an extremely expensive way to make an agent sit around twiddling its thumbs.

Persistence is the next wall, and it's a tall one. A workspace has to survive between sessions, and ideally mount on multiple servers at once so parallel runs can share it. Checkpoint and restore need speed too, because agents suspend and resume constantly; if restoring takes longer than the model itself takes to think, you've stacked latency on top of latency like a bad casserole. E2B's Firecracker sandboxes auto-suspend after 15 seconds idle and resume in under 25 milliseconds, which sets a decent bar for what "fast enough" looks like. A newer academic project called DeltaBox pushes further in a different direction: it freezes only the agent process during checkpoint while a proxy daemon buffers the in-flight API responses, so the checkpoint hides inside time the model was already spending thinking. That's an architecture decision, and it matters more than whatever SSD happens to sit underneath.

Round that out with elastic capacity (nobody knows in advance if a session needs 1 MB or 1 GB), isolation that doesn't force a data copy, and serverless execution sitting next to the filesystem instead of across the room from it. Seven requirements, all told, and most platforms handle maybe two of them well — I say that as someone who's tried to make the other five work with duct tape.

Why should you care past the engineering diagram? A Docker container shares the host kernel, so a container escape is never just your problem, it's the whole host's problem (MITRE files this one as T1611, for anyone who enjoys their disasters cataloged neatly). In November 2025, three separate runc vulnerabilities hit Docker, Kubernetes, containerd, and CRI-O all at once, which is the kind of week that makes a security team age five years. A 2025 Veracode report found 45% of AI-generated code fails basic security tests, so the code running in your sandbox is untrusted by default. The isolation layer has to assume hostility, and the storage underneath has to assume the agent will eventually do something dumb, whether on purpose or by accident. Persistence and security here are tightly linked conversations, two sides of the same coin.

How object storage became the default persistence layer for sandboxes anyway

Object storage won this fight on cost and availability, and that distinction matters more than most vendors want to admit.

S3-class storage runs at roughly a tenth the cost per terabyte of a parallel file system, it basically never goes down, and every cloud already has one sitting around collecting dust and workloads. So teams reached for it, the way you reach for the wrench that's already in your hand instead of walking to the garage for the right one. Cloudflare's agent shell keeps workspace state in R2-backed durable storage (SQLite paired with R2) so files stick around between executions. Daytona built volumes on S3-backed FUSE mounts, dressing object storage up in a filesystem costume. Plenty of other teams just flush outputs to S3 or R2 when a session ends and call it a day, treating the bucket like an archive instead of somewhere an agent actually lives and works.

Here's the catch, and it's a real one: FUSE is a bridge, and bridges charge tolls. Wrapping object storage in a filesystem interface adds a translation layer, and that layer drags back in the exact latency and semantic gaps agents were trying to escape in the first place. The bucket underneath still has no idea an agent is running against it; it just sees GETs and PUTs, blinking uncomprehendingly, doing its best. Snapshot pricing looks fine at small scale — E2B charges $0.20 per GB per month for it — but the actual traffic shape of a live agent workspace (constant, small, frantic reads and writes) doesn't fit the shape of per-request object pricing at all. It's a bit like paying a toll every time you walk from the kitchen to the living room: fine once, as a guest passing through, but miserable if you actually live there.

Quick riddle, since we're on the subject: why did the agent refuse to move into its object-storage apartment? Because there was no lease on latency — every trip to the fridge cost a toll, and the landlord called it a "feature."

That's the gap the newer platforms are chasing: keep the bucket as the source of truth and the price floor, but put a real filesystem in front of it, with a cache that's actually warm when you need it and not some theoretical warmth that shows up three seconds late.

What the GPU starvation problem reveals about storage architecture for agents

Meta found that 56% of GPU cycles in its training pipelines sat stalled, waiting on data, which means more than half the compute bill just vanished paying for nothing. That's the kind of number that makes a finance team's eye twitch. Meta built an entire dedicated Data PreProcessing Service just to claw that back, which tells you how seriously the largest AI shop on the planet takes idle silicon.

Agents catch the same disease with different symptoms. Every time an agent stalls on a cold fetch from object storage, or sits waiting on a slow checkpoint restore, that's compute you already paid for, doing absolutely nothing, again. Training workloads write huge sequential checkpoints and need high sustained throughput, which is a relatively tidy thing to plan around. Agent workloads flip that completely: small, random reads and writes, high IOPS, almost zero patience for latency. Harder to optimize for, and a lot less forgiving when the architecture guesses wrong.

The training world already solved a version of this with tiered storage. Keep a hot NVMe cache in front of the object store for whatever's active right now, replicate to the bucket asynchronously for durability later. Nothing exotic about it; it's just correctly matched to the problem. Get that right in training environments and checkpointing alone speeds up by roughly 2x. Pair it with network-level tuning and SkyPilot's benchmarks showed 6 to 7x end-to-end speedups, before a single GPU even entered the picture. Storage architecture, done right, is leverage: a lever long enough, placed at the right point, moves a boulder with one hand. Done wrong, it's a quiet, expensive stall nobody notices until the invoice lands on someone's desk.

How current platforms handle persistent sandbox storage, and where each approach sits

No platform wins every requirement here, so ranking them top to bottom is less useful than asking what each one actually optimized for. They all made trade-offs, and the interesting part is which trade-off.

Ephemeral-first, microVM platforms like E2B run on Firecracker, keep the root filesystem in RAM, auto-suspend after 15 seconds idle, and resume in under 25 milliseconds. Isolation is strong and resume is fast, but state only survives as long as the memory snapshot does, which is great for short tasks and less great for an agent that's supposed to accumulate context over days.

Edge-native platforms like Cloudflare Workers paired with R2 start V8 isolates in single-digit milliseconds across 300-plus edge locations, billing from $5 a month. Isolates start roughly 100x faster than containers and use 10x to 100x less memory, which is a genuinely wild number the first time you see it. Persistence rides on R2-backed durable storage, a great fit for latency-sensitive, geographically scattered agents, though POSIX semantics are thin on the ground here.

High-performance object storage platforms, MinIO AIStor and WEKA among them, push real throughput: MinIO benchmarks show 10 GB/s GET and 5 GB/s PUT per node on NVMe-tuned setups, and WEKA targets HPC and AI workloads needing very low latency behind an S3 interface. Both were built for training infrastructure first, with agent sandboxing tagging along as an afterthought, and neither ships serverless execution baked in.

Kubernetes-native stateful sandboxes got a real upgrade at KubeCon Atlanta in 2025, courtesy of the kubernetes-sigs/agent-sandbox project's new Sandbox CRD. It treats an agent as a stateful singleton rather than a disposable replica: stable identity, a persistent volume claim, explicit suspend and resume controls. Suspend snapshots the state and scales the pod to zero while the PVC stays intact; resume re-mounts that same PVC like nothing happened. It's a solid pick if you already live in Kubernetes, though it adds real operational weight if you don't, and the storage backend is only as good as whatever got bolted onto the PVC in the first place.

Sprite-based, object-storage filesystems prove the concept works at all, which is more than you can say for a lot of approaches on this list: a 100 GB ext4 filesystem sitting on object storage, live checkpoints around 300 milliseconds, sub-second restore, zero idle charges during auto-sleep. Object-storage economics and real filesystem behavior, in the same box, at a checkpoint speed that doesn't make you flinch when you watch the clock.

Archil comes at this from a different angle entirely. It mounts directly onto a bucket you already own, S3, GCS, R2, Azure Blob, or anything S3-compatible, and presents it as a real POSIX filesystem, with no migration, no ETL job, and no rewriting code you already trust. Reads that hit the NVMe cache come back sub-millisecond; a miss fetches from the source bucket and gets cached for next time, which is a direct answer to that hot-working-set latency problem from earlier. Full POSIX semantics are all there too: atomic rename, flock/fcntl, mmap, fsync, hard links, symlinks, sparse files, so existing tooling just runs, unmodified, without anyone having to hold their breath. The bucket stays the source of truth in your own account; Archil doesn't keep a persistent copy outside it, and access can get revoked whenever you decide you're done. Capacity scales with what's actively cached instead of what you guessed and pre-provisioned months ago, and disks can mount on multiple servers at once, which is what lets parallel agent runs actually share a workspace instead of fighting over one. It also ships serverless execution right alongside the filesystem, so an agent runs bash commands directly against its own files without a separate sandbox hop in between. The bet underneath all of it: a filesystem is the right primitive for agent infrastructure, meant to replace block storage outright, not sit next to it as one more layer somebody has to babysit.

The data movement cost that most sandbox architectures quietly impose

Egress fees from the major clouds usually land between $0.05 and $0.12 per gigabyte, which sounds small until you run the math. A single 8-GPU cluster with moderate data movement lands somewhere around $31,000 to $43,000 a year, just for data leaving the building, and pulling a large training corpus out of AWS entirely gets you to roughly $92,000 in egress alone, before anyone's engineering time even shows up on the invoice.

Agent sandboxing hides this cost differently than training does, and that's the part people miss. Training racks up one enormous transfer you can see coming from a mile off, like a storm on radar. Agent workloads spread the same cost across a thousand small transfers instead, reads, writes, checkpoints, scattered across sessions, invisible one at a time and expensive the second you add them all up. Nobody notices the water bill climbing one drop at a time, and then it shows up all at once, and somebody has to explain it in a budget meeting.

Platforms that make you copy data into a proprietary store before an agent can touch it are asking for three things nobody actually wanted: an ETL pipeline you didn't sign up to build, a second copy of your data you now have to secure, and a bill for moving it there in the first place. The better shape looks different: cache nodes sit next to compute, nothing crosses a region boundary unless someone explicitly configured it that way, and the bucket never leaves the customer's account. The storage vendor's job, at the end of the day, is best understood as a cache, closer to a utility than a landlord.

Object storage overall is growing at a 19.1% compound annual rate, pulled largely by AI workloads, so the volume of data agents push through this pipe keeps climbing. Any architectural mistake made today gets a little more expensive every quarter it's left alone. Compounding interest, except the debt is technical and the collector is your cloud bill.

What "purpose-built for agent sandboxing" actually has to mean in practice

Bolting a filesystem on top of something isn't the same as building for this from the ground up. That distinction might sound like something only an engineer would care about, but it's the whole ballgame. Purpose-built means hitting all seven requirements at once: POSIX semantics, hot-cache latency, persistent shared state, fast checkpoint and restore, elastic metered capacity, isolation without a forced migration, and execution that lives next to the storage instead of across a network hop.

The filesystem part matters specifically because of how these models actually got trained. Frontier models learned overwhelmingly from bash and file manipulation, so agents reach for ls, cat, grep, and mv on pure instinct, the same way you reach for your phone before you're even awake. Object storage SDKs sit much further down that instinct list, because that was never the language they grew up speaking. Try to bridge that gap with a pile of bespoke MCP tools instead, and you end up burning context window on plumbing, which feeds straight into what people are now calling context rot: a model's performance degrading as its context fills up with noise instead of signal. Context works better discovered as the agent actually needs it, rather than front-loaded into one giant prompt like a suitcase packed for a trip you're not sure you're taking. That only works if reading a file is cheap enough, and fast enough, that the agent doesn't think twice about doing it again.

Most of what an agent actually produces, code, logs, intermediate outputs, model responses, is unstructured by nature. Forcing that into a database schema before it's even useful is friction nobody asked for and nobody thanked you for adding. Worth saying plainly: filesystems and databases each have their place, and anything with a clean schema belongs in a database, full stop. Everything else fits more naturally on a filesystem that doesn't demand a schema decision on day one just to save a log file nobody will read twice.

Sizing up a platform? Ask these:

• Real POSIX semantics, or does your existing code need a rewrite nobody budgeted for?

• Your bucket as the actual source of truth, or is the vendor quietly keeping a second copy somewhere?

• Capacity that flexes from megabytes to gigabytes without you having to pre-provision anything?

• Checkpoint and restore fast enough that scaling idle agents to zero doesn't punish you the moment they wake up?

• Execution happening where the data already lives, instead of dragging the data to the code first?

Global AI infrastructure spending cleared $250 billion in 2025, and object storage is the fastest-growing slice of it, at that same 19.1% CAGR. Agent workloads keep landing on whatever storage layer happens to sit underneath them, whether that layer got built for the job or just happened to be lying around when someone needed to ship. The bill for guessing wrong doesn't stay flat: it scales with everything else you're already paying for, quietly, in the background, until it isn't quiet anymore.