AIエージェントのサンドボックス化とは、信頼できないコードやモデル生成コードを、ファイルシステム、process、network、認証情報、resource、lifetime、artifact、cleanupについて明示的に制限された環境で実行することです。containerという名前だけでは、これらの性質を証明できません。
コードに必要なアクセスから始め、その他はすべて拒否します。タスクに型付きAPI呼び出ししか必要ないなら、sandbox化するのではなくコード実行自体をなくします。
最初にthreat modelを書く
生成コードが次を試みるものと仮定します。
- mountされたすべてのファイルと環境変数を読む。
- 内部およびpublic networkをscanする。
- command serverへ接続し、出力を外部へ送信する。
- processをforkし、diskを埋め、memoryを割り当て、無制限のデータを出力する。
- 変更したファイル、package、cache、scheduled workから永続化する。
- cloud metadataまたはlocal runtime socketを調べる。
- 別テナントのartifactまたは認証情報を狙う。
プロンプトの指示ではこの脅威を減らせません。コードが意図的にescapeを試みても、runtimeが境界を強制する必要があります。
ファイルシステムとprocess treeを隔離する
実行ごとに一時workspaceを作成します。必要な入力だけを、できればread-onlyでmountします。host repository、container socket、home directory、cloud configuration、SSH key、共有package cacheをmountしてはいけません。
非特権userで実行し、capabilityを落とし、対応していればsystem callを制限し、process数に上限を設けます。最上位commandを終了すると、child processも終了しなければなりません。background processを残すwall-clock timeoutではcleanupが不完全です。
承認済みartifactは狭いserviceからexportします。pathとfile typeを検証し、size limitを設け、workspaceを破棄する前に出力を外へcopyします。
network accessをデフォルトで拒否する
多くのコードタスクはnetworkを必要としません。必要な場合はallowlistまたは認証付きproxyを通じてegressをroutingします。private range、loopback、link-local address、cloud metadata endpointを含め、DNSとIP accessを制御します。
allowlistにあるdomainでも予期しないaddressへredirectまたはresolveする可能性があるため、接続時に検証します。生成コードへ内部service discoveryへの直接アクセスを与えないでください。
Webアクセスがタスクなら、無制限のsocketより、policyとsession isolationを備えたbrowser toolの方が安全な場合があります。download fileとページ内指示は信頼できないものとして扱います。
範囲が狭く短期の認証情報を注入する
application serverの環境を継承してはいけません。正確なリソースと操作に限定したtask-scoped credentialを発行し、実行後に失効または取り消します。管理、請求、provisioningの認証情報をsandboxから外します。
内部に置いた認証情報はコードから読めるものと仮定します。「隠した」環境変数もprocessから利用できます。セキュリティ上の問いは、そのscopeとlifetime内で認証情報が漏れても許容できるかです。
エージェントセキュリティガイドでは、下流の認可と監査要件を扱っています。
すべてのresourceと出力channelを制限する
CPU、memory、disk、process、file、network、stdout、stderr、wall-clockに上限を設けます。package installとdependency sourceも制限します。policy violationが繰り返されたら停止または隔離します。
モデルへは構造化された要約または上限付きログを返します。無制限のterminal outputは、runtimeが隔離されていてもmemory、token、observability storageを消費します。
workloadから分離の深さを選ぶ
信頼済みapplication codeにはin-process functionまたはbackground workerが適する場合があります。package分離が必要なコードには制限付きcontainer、信頼できない生成コードには強化sandbox、強いkernel境界や特権的system accessを必要とするworkloadには専用VMが必要な場合があります。
コンピュート・エスカレーション段階では、これらのtierをコードの信頼性、network、lifetime、state、latencyへ対応付けています。CloudflareのProject Thinkも関連する段階的アプローチを紹介しています。プロダクトのtierは一例であり、普遍的な境界ではありません。
cleanupを観測可能かつ冪等にする
実行ID、テナント、imageまたはruntime version、policy、credential reference、timestamp、resource usage、artifact reference、exit class、cleanup resultを記録します。cleanupは成功、失敗、timeout、cancel、worker crashの後に実行します。
process障害を越えて残った失効済み環境をreconcilerで見つけます。認証情報の取り消しと環境の削除は、安全に繰り返せる必要があります。
本番環境を危険にさらさず境界をテストする
専用テスト環境で、禁止mountの読み取り、環境変数一覧、private・public接続先、metadataへのアクセス、過剰なprocess生成、出力の枯渇、終了後の存続、別テナントのartifact取得を試します。各試行が拒否され、機密値を露出せず記録されることを確認します。
許可された経路もテストしてください。制限が厳しすぎて実際のタスクをすべて壊すと、チームは広い例外を追加しがちです。各例外を具体的にしてレビューし、必要とするworkloadへ紐づけます。
以下のプロンプトは攻撃コードを実行せず、設定済みの境界を監査します。プロバイダーの保証とリポジトリ内の設定を区別し、sandboxレビューで見つかりやすい欠落を明らかにします。