Notion WorkersがVercel Sandboxで信頼できないコードを大規模に実行する方法
VercelはNotionの「Workers」が実行する第三者由来の信頼できないコードを、FirecrackerマイクロVMとネットワークレベルでの認証情報注入により安全かつ大規模に実行する技術基盤を公開した。
キーポイント
信頼できないコードの実行リスクと分離要件
エージェントや開発者が生成する任意のコードをユーザーに代わって実行する場合、適切な分離がないと認証情報や他ユーザーデータへの不正アクセスリスクが生じる。
FirecrackerマイクロVMによる堅牢な実行環境
各WorkerをエフェメラルなFirecrackerマイクロVMで実行し、コンテナより強力な分離を提供することで、独立したファイルシステムとネットワークスタックを確保する。
ネットワークレベルでの認証情報注入と対策
ファイアウォールプロキシが送信リクエストにAPIキーを注入する仕組みにより、認証情報が実行環境内に展開されず、プロンプトインジェクションによる機密漏洩を防止する。
スナップショットと動的ネットワークポリシーによるスケーラビリティ
依存関係のインストール後にファイルシステムをスナップショット化し、コールドスタートを高速化。また実行中にネットワークアクセスを動的にロックダウンするポリシーでセキュリティとパフォーマンスを両立する。
コスト予測可能性と効率化
ファイルシステムのスナップショット保存と実行中のCPUのみ課金されるアクティブCPU課金を組み合わせることで、スケーリングしてもコストを予測可能に保つ。
プラットフォーム化とインフラの委譲
Notionは単なる機能から開発者プラットフォームへ移行しており、セキュリティやネットワーク分離などの複雑なインフラ課題をVercel Sandboxに委譲して開発体験の向上に注力している。
主要な3つの利用パターン
外部データの定期同期、ボタンクリックでのカスタム自動化実行、AIエージェントのツール呼び出しという3つの主要なユースケースをサポートしている。
影響分析・編集コメントを表示
影響分析
AIエージェントの普及に伴い、サードパーティ製コードの実行リスクが顕在化する中、Vercel Sandboxのアーキテクチャは「信頼できないコードを安全に実行する」ための実用的なインフラモデルを示した。これにより、プラットフォーム構築者はエージェント駆動型ワークロードのセキュリティとスケーラビリティを両立しやすくなり、次世代AIプラットフォームの設計基準に影響を与える可能性がある。
編集コメント
エージェント実行環境のセキュリティ設計において、認証情報のネットワークレベル注入という発想は実用的で注目すべきだ。ただしFirecracker自体の採用は既存技術のため、革新性よりも「エージェント特有のプロンプトインジェクション対策」としての応用価値が大きいと評価できる。
タイトル: Vercel SandboxがNotion Workersによる信頼できないコードの大規模実行を実現する方法
Notion Workersを使用すると、コードを記述してデプロイし、Custom Agentsに新たな機能を付与できます。例えば、外部データの同期、自動化のトリガー、あらゆるAPIの呼び出しなどです。Workersを活用することで、開発者は、スケジュールに基づいてCRMデータを同期するエージェント、エラー率が急上昇した際に課題を作成するエージェント、Slackスレッドをフォーマットされたコンテンツに変換するエージェントなどを構築できます。
内部的には、すべてのWorkerがVercel Sandbox上で実行されます。
課題: あらゆる開発者やエージェントからのコードを安全に実行すること
Notionは、カスタムコードによって誰でもプラットフォームを拡張できるようにしたいと考えていました。これは難しいインフラストラクチャの問題であると同時に、さらに大きなセキュリティ上の問題でもあります。各Notion Workerは、サードパーティの開発者やエージェントによって生成された任意のコードを、Notionユーザーに代わって、場合によっては企業のワークスペース内で実行するからです。
適切な分離がなければ、WorkerはCustom Agentと同じ環境で実行され、そのシークレット、権限、およびその実行コンテキスト内の他のすべてにアクセスできてしまいます。たった一つのプロンプトインジェクションで認証情報が流出したり、他のユーザーのデータにアクセスしたりする可能性があります。
要件は明確でした:
- 強固な分離: あるNotion Workerが別のWorkerのデータや状態にアクセスすることは決してない
- 認証情報のセキュリティ: Notion Workersは外部サービスと通信するためにAPIキーを必要としますが、それらのシークレットがコード自体に露出することは決してない
- ネットワーク制御: 企業顧客は、Workerがアクセスを許可される外部サービスについての保証を必要とする
- スケール: Workersは、性能劣化なく、何百万人ものユーザーの同時実行をサポートする必要がある
- 状態の保持: Workersは高速なコールドスタートを必要とし、そのためにはファイルシステムの状態をスナップショットして復元する機能が必要
- 経済性: CPU使用率が低いエージェント向けに構築された課金モデル
なぜVercel Sandboxなのか
Vercel Sandboxは、各Notion Workerを一時的なFirecrackerマイクロVM内で実行します。各VMは独自のカーネルを起動するため、コンテナよりも強力な分離を提供します。各実行は独自のファイルシステム、独自のネットワークスタック、独自のセキュリティ境界を持ちます。Notion Workerの実行が終了すると、マイクロVMは破棄されるか、後で取得するためにスナップショットされます。
Notion Workersのようなワークロードを大規模にサポートするために、Vercel Sandboxはいくつかの重要な機能を提供します:
- 認証情報インジェクション: Sandboxのファイアウォールプロキシは、ネットワークレベルで送信リクエストを傍受してAPIキーを注入できるため、認証情報が実行環境に入ることはありません。エージェント駆動のワークロードでは、これにより最も危険なプロンプトインジェクションの経路、つまりエージェントが騙されてシークレットを流出させることを排除できます(このアーキテクチャについては、『エージェント型アーキテクチャにおけるセキュリティ境界』で詳しく解説しています)。
- ネットワークポリシー: Sandboxは、プロセスを再起動せずにランタイム中に更新できる動的ネットワークポリシーをサポートしています。例えば、依存関係をインストールするためにインターネットアクセスを許可した後、信頼できないコードを実行する前にエグレスをロックダウンすることができます。プラットフォームビルダーは、これらの制御を自社の顧客に提供できます。
- スナップショット: 依存関係を一度インストールし、ファイルシステムの状態をスナップショットすれば、後続の呼び出しではそのスナップショットから再開できます。これに、CPUコストがコードが実際に実行されているときのみ発生し、I/O待機中は発生しないアクティブCPU課金を組み合わせることで、使用量が拡大してもコストを予測可能に保ちます。
大局的な視点: 開発者プラットフォームとしてのNotion
Notion Workersは単発の機能ではありません。Notionが開発者プラットフォームへと変わる始まりです。
この転換には、Notionが自ら構築する必要のないインフラストラクチャが必要です。安全なコード実行、認証情報管理、ネットワーク分離、ファイルシステムベースのスナップショット——これらは、プラットフォームが拡大するにつれて複雑化する難しい問題です。
Vercel Sandboxがインフラストラクチャの複雑さを処理するので、Notionは開発者エクスペリエンスに集中できます。
開発者がNotion Workersで構築しているもの
Notion Workersは、主に3つのパターンをサポートしています。サードパーティデータの同期、カスタム自動化、AIエージェントツールです。
開発者はこれらを使用して、CRMレコード、アナリティクス、サポートチケットなどの外部データを、スケジュールに基づいてNotionに同期します。また、Workerをボタンに接続し、ワンクリックで任意のコードをトリガーすることもできます。さらに、NotionのカスタムエージェントがWorkerをツール呼び出しとして起動する場合、事前構築済みの統合に限定されたエージェントよりもはるかに強力な機能を発揮します。
Vercel Sandboxでプラットフォームを拡張する
Notion Workersが必要とする機能は、他のエージェントプラットフォームと同じです。ユーザーやエージェントにカスタムコードを実行させたいあらゆるプラットフォームは、分離、認証情報のセキュリティ、ネットワーク制御、スケールという同じ一連の問題に直面します。
Vercel Sandboxはこれらをすぐに使える機能として提供します。AIエージェント、開発者プラグイン、ワークフロー自動化のいずれであれ、信頼できないコードを実行する必要があるプラットフォームを構築しているなら、これがその方法です。
続きを読む
原文を表示
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.
The problem: safely running code from any developer or agent
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:
Hard isolation: One Notion Worker can never access another's data or state
Credential security: Notion Workers need API keys to talk to external services, but those secrets can never be exposed to the code itself
Network controls: Enterprise customers need guarantees about the external services a Worker is allowed to reach
Scale: Workers need to support millions of users running concurrent executions without performance degradation
State preservation: Workers need fast cold starts, which require the ability to snapshot and restore filesystem state
Economics: A billing model that is built for agents with low CPU utilization rates
Why Vercel Sandbox
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:
Credential injection. 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 security boundaries in agentic architectures).
Network policies. 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.
Snapshots. 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.
The bigger picture: Notion as a developer platform
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.
What developers are building with Notion Workers
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.
Extend your platform with Vercel Sandbox
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.
Vercel Sandbox 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.
Read more
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み