Vercel's $1M Sandbox Bounty and Lovable's AI Opt-Out

Two things happened this week that matter more than they look. Vercel admitted its own sandbox isolation model had a gap and put $1M behind finding more like it. And Lovable changed what happens to your data by default, starting in September. Neither story is loud. Both are worth ten minutes of your time.

TL;DR

• Vercel launched a $1M bug bounty for Vercel Sandbox after acknowledging that agents running untrusted code can escape containment through a network path, without ever crossing the VM boundary.
• Alongside it, Vercel shipped a team-wide AI Gateway provider allowlist, key-free JWT signing via Vercel KMS, and short-lived, read-only GitHub tokens for deploying from users' repos.
• Lovable will start using Free and Pro plan customer data for AI model training on September 9, 2026, unless you opt out. Business and Enterprise workspaces are excluded. (Lovable changelog)
• r/vibecoding is building its own security checklists faster than most tooling can: a pre-launch secrets checklist and a 36-point review before shipping a booking SaaS both landed this week.

Vercel says sandbox escapes don't need a VM boundary crossing

MicroVMs are the standard way to run untrusted AI-generated code: one guest kernel per workload, isolated from the host and from every other workload. Vercel's own research, referenced in its $1M hacker challenge post, found that agents don't need to break that wall at all. They only need one network path the security model didn't account for. That's the same point Vercel made in an earlier post, A sandbox without a network boundary is only half a sandbox.

If your app lets an AI agent execute code on a user's behalf — a code interpreter, a sandboxed "run this" feature, anything built on top of Sandbox-style infrastructure — this is the part of the threat model that actually gets exploited. Isolation isn't just about the container. It's about what the container can still talk to.

New guardrails: allowlists, key-free signing, scoped tokens

Three smaller Vercel changes this week point at the same lesson: reduce what a leaked credential or a compromised agent can actually do.

• The AI Gateway provider allowlist lets a team restrict which AI providers can serve requests at all, enforced at the gateway, not per-request. That closes off a class of mistake where a stray config change routes traffic somewhere it shouldn't.
• Vercel KMS signs JWTs from your functions without a private key ever touching your code or your environment variables. The key stays inside the key management service; only the public key is exposed to verifiers.
• Vercel for Platforms can now deploy from a user's GitHub repo using a token that's read-only, scoped to one repository, and valid for 24 hours or less.

None of these are exotic. They're the same principle applied three times: don't hand out more access than the task needs, for longer than the task needs it. That's the same principle behind Row Level Security on a database, or scoping an API key to one route instead of your whole account.

Lovable's data-training default flips in September

Starting September 9, 2026, Lovable may use customer data from Free and Pro plan projects for AI model training, unless you opt out. The setting lives in Account settings → Privacy as Data collection opt out, and it only covers your own data — it doesn't change the setting for other members of a shared workspace. Business and Enterprise workspace data is excluded from training entirely.

If your app touches anything you wouldn't want reused as training data — customer conversations, proprietary prompts, anything under an NDA — check that setting before the deadline, not after.

What vibe-coders are already checking themselves

Two posts on r/vibecoding this week are effectively crowdsourced security audits. One is a running checklist a builder now runs before letting anyone touch a project: no API keys or passwords visible in page source or the Network tab, .env never committed, and hard limits on anything that costs money per call. Another describes a 36-point review run against an isolated copy of a booking SaaS with synthetic tenants before launch — a static code review plus an actual attempted attack, done deliberately instead of skipped.

That's the right instinct. The tooling underneath is getting better guardrails, but nothing ships them on by default for you automatically. Someone still has to check.

FAQ

Should I opt out of Lovable's AI training?

It depends on what's in your project. If you're on a Free or Pro plan and your app handles anything sensitive — customer data, proprietary logic, private prompts — go to Account settings → Privacy and enable Data collection opt out before September 9, 2026. Business and Enterprise workspaces are excluded from training by default.

How do AI agents escape sandboxes without a VM escape?

According to Vercel's own research, agents running untrusted code don't need to break the VM boundary at all. They can get out through a network path the isolation model didn't restrict — meaning the sandbox's network rules, not just its kernel isolation, decide how contained an agent actually is.

What should I check before I share a vibe-coded app link?

At minimum: no API keys or passwords visible in page source or the browser's Network tab, .env is in .gitignore and was never committed, and anything metered per call — especially AI APIs — has a hard usage limit. Both checklists shared on r/vibecoding this week start there.

The bottom line

The infrastructure is getting harder to break by accident — allowlists, scoped tokens, key-free signing, a $1M incentive to find what's left. But every one of those controls has to be turned on by someone who knows it exists. Check your Lovable privacy setting before September. Check your own app the way the r/vibecoding checklists do, before you hand anyone the link.