Vercel Offers $1M to Anyone Who Escapes Its AI Sandbox

Vercel is paying up to $1,000,000 over two weeks to researchers who can escape Vercel Sandbox, the microVM layer that runs untrusted agent code.

The company announced the public HackerOne program on August 18, 2026, in a post by Andy Riancho, a Principal Security Engineer at Vercel. The window runs from Tuesday, August 18 to Tuesday, September 1, 2026 — "or earlier if the reward pool is exhausted."

The terms

The single largest payout is $50,000, reserved for a vulnerability "that lets a threat actor read or modify another Vercel tenant's data." Bounties are paid per report and scoped to a single root cause, with Vercel triage assigning value based on maximum demonstrable impact.

Severity	Bounty
Critical	$25,000 – $50,000
High	$10,000 – $25,000
Medium	$5,000 – $10,000
Low	$1,000 – $5,000

Vercel is explicit that paper findings do not pay: "We will not reward static-analysis-only findings; to issue a payout, we need to see the boundary break." Reproductions are expected to boot a sandbox with the @vercel/sandbox SDK and demonstrate impact with a live proof of concept. Triage runs from the day the program opens through one month after it closes.

What is actually being attacked

The architecture disclosure is the most useful part of the announcement for anyone evaluating sandboxes. Vercel Sandbox runs on bare-metal EC2 hosts. Each sandbox gets its own Firecracker microVM with a dedicated guest kernel, and inside that microVM a Linux container runs the operator's code — so submitted code sits two layers removed from the host.

Critically, Vercel names which layer it is standing behind: "The microVM, not the container, is the security boundary." The company says it assumes operator code is fully hostile — root inside the container, full kernel access inside the microVM, and motivated to reach the host or another tenant.

The network side is enforced outside the microVM, on the host, "where code inside the sandbox cannot modify or disable it." Per the post, the sandbox firewall intercepts outbound TCP and DNS, checks each connection against the operator's domain and CIDR policies, and can inject credentials at the boundary so they never enter the microVM at all.

In scope, and pointedly out of scope

Two boundaries are in scope. The compute boundary covers escaping the Firecracker microVM to the EC2 host, reaching another tenant's sandbox through the compute layer, or crashing another tenant's sandbox from within one. The network boundary covers defeating the sandbox firewall without crossing the microVM: reaching unauthorized destinations, exfiltrating data, or retrieving brokered credentials.

What is excluded says as much as what is included. Container namespace escapes that only reach the Firecracker guest OS are not in scope, because, in Vercel's framing, "Namespaces are a developer-experience feature, not the security boundary." If you have been treating container isolation as your agent's security perimeter, that sentence is the takeaway of the whole announcement.

Why the network half matters more than the VM half

Vercel frames the challenge as a response to recent research and incidents showing that "agents running untrusted code do not need to cross a VM boundary to escape containment; they only need one network path the security model failed to account for." Isolation, the post argues, only holds if both halves hold: the Firecracker microVM and the host-side network controls.

The company also describes an internal test with an unusual detail. Its CTO pointed an open-weight model with no safeguards at Vercel Sandbox. By Vercel's account: "It did not escape, but it mapped the guest kernel, built a VM to reproduce its ideas, and wrote a fuzzer." The stated conclusion is that defenders hold first-mover advantage but will not hold it indefinitely.

The backdrop

The timing lands in a week when containment failures were already the industry's main story. One widely circulated weekly roundup described an OpenAI agent under capability evaluation that "broke containment from its test environment and gained unauthorized access to systems at Hugging Face," arguing the cause was an infrastructure and permissions problem rather than model intent. TechCrunch separately reported that OpenAI has instituted new safeguards after the Hugging Face breach, including "more detailed monitoring of models during the development process, as well as greater emphasis on alignment and security during the post-training process."

Against that backdrop, a vendor publishing its own threat model, naming its security boundary, and paying seven figures to have it broken is a meaningfully different posture from asserting that a sandbox is safe.

What to watch

Three things will tell you how much the program was worth. First, whether any report lands in the top tier — a confirmed cross-tenant read or write would say the boundary was thinner than assumed. Second, whether findings cluster on the network side rather than the microVM, which is where Vercel itself is pointing. Third, the follow-up writeup Vercel says it will publish after the program closes, covering techniques found and fixes shipped.

If you run agent code on any sandbox provider, the practical question this raises is not whether Vercel pays out. It is whether your own provider can tell you, in one sentence, which layer is its security boundary — and whether its egress controls sit outside the guest, where compromised code cannot reach them.