エージェントのコンピュートは、workloadのコードに対する信頼、ネットワークアクセス、認証情報、存続期間、ファイルシステム、状態、リソース上限に応じて選びます。スコープ付きAPI呼び出しにsandboxは不要です。信頼できない生成コードには、通常のアプリケーションprocessやcontainer設定では得られない分離が必要です。
エスカレーション段階を使うと、単純なデータベース読み取りにファイルシステムとshellを渡さず、危険なコードを長期利用のアプリケーション認証情報から遠ざけられます。
タスクを満たす最も低いtierを使う
flowchart TD
A[Scoped API call] -->|needs application logic| B[In-process function]
B -->|needs async or longer work| C[Background job]
C -->|needs package or process isolation| D[Isolated process or container]
D -->|runs untrusted code| E[Hardened sandbox]
E -->|needs full machine control or long-lived isolation| F[Dedicated VM]
エスカレーションすると機能と運用作業が増えますが、安全性が自動的に高まるわけではありません。無制限のネットワークアクセスと本番認証情報を持つsandboxは、範囲の狭いサーバー側APIより危険になり得ます。
Tier 0：スコープ付きAPI呼び出し
タスクをデータベースquery、object read、email send、deployment requestとしてすでに表現できる場合は、型付きバックエンド操作を使います。エージェントは制限付き引数を渡し、サーバーが認証情報、認可、検証、監査を担います。
このtierには汎用コード実行がありません。通常のプロダクトアクションの標準とすべきで、セマンティックなツール設計に沿っています。
Tier 1：process内function
リクエストのライフサイクル内に収まる、短く信頼できる変換とオーケストレーションにはアプリケーションコードを使います。利用可能なmoduleを制限し、プロバイダーのシークレットをモデルから見える入力の外に置きます。
このtierで生成コードをeval、shell、dynamic importから実行してはいけません。タイムアウトでリクエストの待機は止まりますが、すべてのchild processや外部への効果が確実に止まるとは限りません。
Tier 2：background job
リクエストのタイムアウトを超える作業、予定された再試行が必要な作業、個別にrate controlすべき作業はqueueへ移します。queueは複数回配信する場合があるため、操作記録を永続化しjobを冪等にします。
job workerは永続的scheduleであり、セキュリティ境界ではありません。通常はサービスと同様のアクセスを持つ信頼済みアプリケーションコードを実行します。永続実行ガイドでは、checkpointと結果不明状態を扱っています。
Tier 3：隔離processまたはcontainer
package、ファイルシステム、異なるCPU・メモリ上限を必要とする信頼済みコードには、別のprocessまたはcontainerを使います。権限を落とし、可能ならread-onlyのbase filesystemを使い、必要なファイルだけをmountし、外向きネットワークアクセスを制限します。
プラットフォームが強い境界を追加しない限り、containerはhost kernelを共有します。workloadのpackagingとprocess分離として扱い、runtime設定がthreat modelに合うか評価してください。
Tier 4：強化sandbox
信頼できないコードやモデル生成コードにはsandboxを使います。実行ごとに一時ファイルシステム、厳格なCPU、メモリ、process、経過時間の上限、外向きネットワークの許可リストを与えます。タスクscopeの認証情報だけを注入し、実行後に取り消して環境を破棄します。
クリーンアップ前に承認済み出力をobject storageへ永続化します。成果物をscanし、無制限のstdoutやbinary contentをモデルへ返さないようにします。sandboxガイドでは、escape経路とテストケースを扱っています。
Tier 5：専用VM
独自のkernel境界、特権的なシステム動作、特殊な依存関係、長期利用のdesktop、顧客固有の分離が必要なタスクには専用virtual machineを使います。imageを強化し、metadata serviceへのアクセスを制御し、patchを適用し、teardownを定義します。
エージェントが一度使ったというだけで、VMを永続化してはいけません。長期稼働するmachineには、認証情報、ファイル、package、ネットワーク上の信頼が蓄積します。永続化が不要なら、既知のimageから再構築します。
tierを選ぶ前に6つの要件を分類する
- コードの信頼性： すべての指示と依存関係をチームが管理するか、ユーザーやモデルがコードを提供できるか？
- 権限： workloadはどの認証情報とリソースへ到達する必要があるか？
- ネットワーク： ネットワーク不要、固定allowlist、public web、private serviceのどれが必要か？
- 存続期間と状態： 数秒で終了するか、数時間待つか、永続machineが必要か？
- runtime surface： shell、browser、package install、writable filesystem、kernel機能、GPUが必要か？
- リソース上限： 暴走を止めるCPU、メモリ、process、出力、支出の上限は？
CloudflareのProject Thinkでは、エージェントworkload向けの関連するtier設計を説明しています。正確なプロダクトの対応はプロバイダー固有ですが、要件に応じて狭い操作から隔離コンピュートへ段階的に上げる考え方は共通です。
名前ではなく境界をテストする
ファイルシステムのmount、network egress、シークレットの可視性、process limit、termination、artifact export、cleanupを検証します。隔離環境で禁止hostと別テナントのリソースへの到達を試します。どのimage、ポリシー、ID、操作が実行を作成したか、プラットフォームに記録されることを確認します。
以下のプロンプトは、インフラを提案する前に現在のworkloadを分類します。shellを完全に外せるタスクが見つかることも多く、それはcontainerをsandboxと言い換えるより明確なセキュリティ改善です。