Vercel Sandbox Drives Make Agent State a First-Class Risk

Vercel announced Drives for Vercel Sandbox in private beta on June 5. The short version: a Sandbox can now mount persistent, attachable storage whose lifecycle is independent from the sandbox itself.

That sounds like a small storage feature. It is not. For AI coding agents and generated-code workflows, persistent storage changes the security model from “throw away the box when the weird robot is done” to “the weird robot may leave things in a closet for the next robot.” Closets are useful. Closets are also where incident reports go to mature.

What changed

Vercel Sandbox is Vercel’s compute primitive for running untrusted or user-generated code. The Sandbox docs describe it as a way to run AI agent output, user uploads, third-party scripts, code playgrounds, and development servers in isolated Linux environments.

The new Drives feature adds detachable persistence:

• create a drive once;
• mount it at a configurable path when starting a sandbox;
• stop the sandbox while the drive remains available;
• attach the drive to a later sandbox.

The changelog says the beta SDK is @vercel/sandbox@beta and the beta CLI is sandbox@beta. The broader SDK reference now lists drives alongside files, ports, snapshots, sessions, and network policy.

The operational detail that matters: the Drives concept docs say drives can be mounted read-write or read-only, mount paths must be absolute and non-overlapping, and drives are currently single-reader/single-writer. Deleting a drive permanently removes its data, and a drive cannot be deleted while attached to a running sandbox.

This is private beta, and the changelog says availability is limited to Pro and Enterprise teams. Translation: this is not “every hobby project now has durable agent scratch disks.” It is a signal about where hosted agent infrastructure is going.

Why builders should care

The first wave of AI sandboxing was mostly about containment: give the agent a small disposable place to run commands, install dependencies, edit files, and hopefully not reenact the last scene of a disaster movie with rm -rf.

That was necessary, but it was also incomplete. Real developer workflows are stateful:

• dependency installs are slow;
• build caches matter;
• package managers keep metadata;
• language servers and test runners produce artifacts;
• agents need working directories that survive more than one command;
• interactive coding sessions often need continuity across attempts.

Persistent drives make those workflows less painful. If a coding agent has to install the same dependency tree on every run, your “AI acceleration” becomes a very expensive progress bar. A reusable drive can turn repeated sandbox startup work into cached state.

But persistence also creates memory. Memory creates responsibility.

A disposable sandbox can still leak secrets during its lifetime, but once it dies, most of its local filesystem dies with it. A persistent drive can keep:

• credentials accidentally written by tools;
• .env files produced during debugging;
• package-manager tokens;
• poisoned dependency caches;
• generated code that the next task treats as trusted context;
• test fixtures containing production-ish data;
• logs with request bodies, stack traces, or API responses.

That does not make Drives bad. It makes them infrastructure. Infrastructure has policies, ownership, retention, and boring names in spreadsheets. Glamorous, no. Necessary, yes.

The practical model: sandbox, drive, and trust boundary

Treat a sandbox as execution. Treat a drive as state. Do not blur the two.

A reasonable operating model looks like this:

1. Separate drives by trust level. Do not reuse the same persistent drive across unrelated customers, repos, tenants, or agent identities. “It was convenient” is not a compliance boundary.
2. Prefer read-only mounts when sharing baseline state. A prewarmed dependency cache is useful. Letting every untrusted run mutate the shared cache is how you invite cache poisoning to move in and start receiving mail.
3. Make drive lifecycle explicit. Drives need creation, ownership, retention, deletion, and audit rules. If the drive outlives the sandbox, your cleanup job cannot stop at sandbox termination.
4. Scan state, not just code. If a drive can contain generated artifacts, downloaded packages, logs, and secrets, it belongs in your security scanning plan.
5. Assume agents will write surprising things. Humans already leak secrets into shell history and log files. Agents add scale, speed, and the serene confidence of a junior developer who has never been paged.

The single-reader/single-writer constraint is also worth noting. It simplifies some consistency problems, but it means you should not design around broad concurrent sharing yet. If you need many sandboxes reading the same baseline, use read-only patterns or separate initialization flows until the product’s concurrency model matures.

What this says about agent infrastructure

The interesting part is not just that Vercel added storage. It is that agent platforms are converging on the same primitives normal platforms needed years ago:

• isolated execution;
• persistent volumes;
• snapshots;
• network policy;
• observability;
• lifecycle APIs;
• cost controls;
• admin governance.

The names are shinier because AI is involved, but the physics are old. State is where speed comes from. State is also where weird bugs, stale assumptions, and security surprises live.

For teams building agentic developer tools, this is the real takeaway: sandboxing is no longer a checkbox feature. It is a stack. Execution isolation is one layer. Persistent state is another. Network policy, identity, logging, retention, and cache hygiene are the rest of the sandwich. Ignore one layer and the sandwich becomes soup.

Caveats

This is a private beta, so the details may change. Vercel’s public docs establish the basic behavior and constraints, but they do not answer every operator question yet: drive quotas, retention defaults, audit-log coverage, encryption controls, cross-project boundaries, and malware scanning expectations are the things security teams will want nailed down before broad rollout.

That is normal for a beta. It is also exactly why teams should prototype with a threat model, not just a demo script.

Bottom line

Persistent drives make AI sandboxes more useful because real work needs state. They also make them more dangerous because real incidents love state.

If you adopt them, do it like an operator: separate trust zones, mount read-only where possible, clean up deliberately, and treat every durable agent workspace as a small filesystem with a long memory and questionable taste in souvenirs.