Web Directions Year round learning for product, design and engineering professionals

Shipping Sandboxed Workers for Notion Agents

The moment you let developers extend a system with custom code, you've opened a door you can never fully close. It's powerful — users can do anything — and terrifying for the team that has to maintain the platform. Add AI agents to the equation and the problem gets more acute. An agent is not just running code; it's running code autonomously, making decisions, accessing data, potentially escalating privileges or making irreversible changes.

Notion approached this challenge head-on when they set out to let developers extend AI agents with custom capabilities. The goal was ambitious: give developers real power to write custom code that agents could execute, while keeping the Notion platform safe and the data secure. That means building a sandboxed execution environment — a place where custom code can run but only within carefully defined boundaries.

The architecture decisions involved in shipping this are instructive because they're not just technical; they're about tradeoffs.

First, there's the question of what a sandboxed environment actually means in this context. You can't just run code in a subprocess and hope it's safe. A determined developer could escape most basic sandboxes. You need real isolation: a boundary between the custom code and everything it's not supposed to access. Notion's approach uses containerization and orchestration that keeps code genuinely separated from the broader system.

Second, there's the question of what power to grant. Too restrictive and the sandbox becomes useless — developers can't actually do anything interesting. Too permissive and you might as well not have a sandbox. The answer is fine-grained capability control: custom code can read certain data, write to certain places, call certain APIs, but nothing more. It's like giving someone a keycard that opens specific doors but not others.

Third comes the operational challenge: how do you deploy, monitor, debug, and update code that's running in a sandbox you control? Your typical deployment pipeline doesn't work. You need a whole new set of tools for safely running untrusted code at scale. That means observability (you need to know what's happening in those sandboxes), error handling (when code fails, what's the user experience?), and performance (each sandbox has resource limits, so code that works on a developer's laptop might time out in production).

Fourth, there's the security question that keeps engineers awake: what happens when the sandbox is breached? It will be, eventually. Someone will find an exploit. The question isn't if, but when and how you respond. Notion's architecture assumes the sandbox can be broken and builds defense-in-depth: multiple layers, so a breach in one layer doesn't give full access.

Fifth is the data sovereignty question. Custom code needs to access data to be useful, but which data? What level of isolation is needed between different developers' custom code? If you're running agents from different organizations (or different users within the same organization), they can't see each other's data. That's architecture, not just policy.

These decisions aren't made in a vacuum. They reflect Notion's understanding that developers want power but users want safety. The platform has to serve both. The sandbox is where that tension gets resolved architecturally.

The broader implication is that as agents become more capable and more autonomous, the question of "what can this agent do?" becomes infrastructure-critical. It's not just a security issue; it's an architectural one that shapes how the entire platform operates.

For teams building platforms that allow custom code or custom agents, the lesson is clear: build the sandbox first, not as an afterthought. Design the boundaries before you ship the capabilities. Know your threat model. Plan for the breach.

Adam Hudson, a software engineer with over 20 years of experience and a PhD in engineering, will dive deep into these architectural decisions and the security considerations involved at AI Engineer Melbourne 2026 on June 3-4, drawing from his work on Notion's data platform.