Notion Workers run untrusted code at scale with Vercel Sandbox

Notion Workers let you write and deploy code to give Custom Agents new powers: sync external data, trigger automations, call any API. With Workers, developers can build agents that sync CRM data on a schedule, open issues when error rates spike, and turn Slack threads into formatted content.

Under the hood, every Worker runs on .Vercel Sandbox

Notion wanted to let anyone extend their platform with custom code. That's a hard infrastructure problem, but an even bigger security problem. Every Notion Worker runs arbitrary code generated by a third-party developer or agent, on behalf of a Notion user, potentially inside an enterprise workspace.

Without proper isolation, a Worker would run in the same environment as the Custom Agent, with access to its secrets, permissions, and everything else in that execution context. A single prompt injection could exfiltrate credentials or access another user's data.

The requirements were clear:

Vercel Sandbox runs each Notion Worker in an ephemeral Firecracker microVM. Every VM boots its own kernel, providing stronger isolation than containers. Each execution gets its own filesystem, its own network stack, and its own security boundary. When the Notion Worker finishes, the microVM is either destroyed or snapshotted for later retrieval.

To support workloads like Notion Workers at scale, Vercel Sandbox provides several critical capabilities:

Sandbox's firewall proxy can intercept and inject API keys into outbound requests at the network level, so credentials never enter the execution environment. For agent-driven workloads, this eliminates the most dangerous prompt injection vector: an agent being tricked into exfiltrating secrets. (We wrote about this architecture in depth in ).Credential injection.security boundaries in agentic architectures

Sandbox supports dynamic network policies that can be updated during runtime without restarting the process: start with internet access to install dependencies, then lock down egress before running untrusted code. Platform builders can pass these controls through to their own customers.Network policies.

Install dependencies once, snapshot the filesystem state, and resume from that snapshot on subsequent invocations. Combined with active-CPU billing, where CPU costs only accrue when your code is actually executing, not waiting on I/O, this keeps costs predictable as usage scales.Snapshots.

Notion Workers isn't a one-off feature. It's the beginning of Notion becoming a developer platform.

This shift requires infrastructure that Notion shouldn't have to build. Secure code execution, credential management, network isolation, file-sytem based snapshotting: these are hard problems that compound as the platform scales.

Vercel Sandbox handles the infrastructure complexity so Notion can focus on the developer experience.

Notion Workers support three main patterns: third-party data syncing, custom automations, and AI agent tools.

Developers use them to sync external data, such as CRM records, analytics, and support tickets, into Notion on a schedule. A Worker can also be attached to a button, triggering arbitrary code with a single click. And when Notion's custom agents invoke Workers as tool calls, they become far more capable than agents limited to pre-built integrations.

Notion Workers requires the same capabilities as other agent platforms. Any platform that wants to let users or agents run custom code faces the same set of problems: isolation, credential security, network controls, and scale.

provides these as capabilities out of the box. If you're building a platform that needs to run untrusted code, whether for AI agents, developer plugins, or workflow automation, then this is how you do it.Vercel Sandbox

Read more

The problem: safely running code from any developer or agent

Why Vercel Sandbox

The bigger picture: Notion as a developer platform

What developers are building with Notion Workers

Extend your platform with Vercel Sandbox

• :One Notion Worker can never access another's data or stateHard isolation

• :Notion Workers need API keys to talk to external services, but those secrets can never be exposed to the code itselfCredential security

• : Enterprise customers need guarantees about the external services a Worker is allowed to reachNetwork controls

• :Workers need to support millions of users running concurrent executions without performance degradationScale

• Workers need fast cold starts, which require the ability to snapshot and restore filesystem stateState preservation:

• A billing model that is built for agents with low CPU utilization ratesEconomics: