本文
AIエージェントへ「危険な操作をしないで」と指示するだけでは、被害範囲は閉じません。誤った推論、prompt injection、悪意のある入力が起きても、書ける場所、通信先、使える認証情報、承認なしに実行できる操作を技術的に狭める必要があります。
サンドボックスの目的は、モデルを善良にすることではありません。失敗しても到達できる資源を限定し、外へ出る例外を記録可能にすることです。
四つの能力を分ける
実行環境は次の四能力で設計します。
| 能力 | 既定 | 例外の与え方 |
|---|---|---|
| filesystem | 専用workspaceのみ書込み可 | task単位の明示path |
| network | denyまたは最小allowlist | method・host・path・用途を限定 |
| credentials | agentへ常設しない | proxy経由の短命token |
| approval | 破壊・対外作用前に要求 | 対象と差分を表示 |
OpenAIはCodexの安全な実行について、sandboxとapprovalを組み合わせ、network accessを制限する構成を説明しています[1]。承認は重要ですが、全てを人の注意力へ寄せると形骸化します。通常操作は狭いsandbox内で自動化し、境界を越える時だけ確認する設計が必要です。
workspaceは「作業できる範囲」を示す
通常は専用workspaceだけをread/write可能にし、ホームディレクトリ、SSH key、cloud CLI設定、他project、秘密ファイルをmountしません。Anthropicはagent containmentの実装で、filesystem、VM、egress controlを組み合わせ、誤動作やprompt injection等の被害半径を制限する考え方を示しています[2]。OWASPもcoding agentについて、devcontainer、restricted shell、VM、ephemeral workspaceとcredential storeの分離を推奨します[3]。
低リスクのread-only検索まで常に完全VMを必須にするのは過剰です。扱う資源と外部作用に応じて、process隔離、container、microVMを選びます。ただし同じhost上の隔離は、kernelやmount設定など実装条件を確認します。NIST SP 800-190もcontainer image、runtime、host、orchestratorを別のリスク面として扱います[4]。
egress allowlistを「安全なdomain一覧」にしない
許可domainであっても、upload endpoint、issue作成、webhook、server-side fetchがあれば漏えい経路になります。Anthropicは、承認済みdomainを経由したexfiltrationを見落とした事例を公開し、宛先名だけでは不十分だと説明しています[2]。
egress policyにはhostだけでなく、HTTP method、path、body size、content type、転送可能な識別子、taskとの関係を含めます。可能ならagentが直接internetへ出ず、policy enforcement proxyを通して、許可理由とresponseを記録します。
credentialをworkspaceへ置かない
固定API keyやSSH keyを環境変数やfileとしてsandboxへ渡すと、agentが読める時点で外部送信や誤利用が可能です。認証情報はhost側またはbroker側に置き、task、resource、操作、期限を限定したtokenへ交換します。Anthropicはcredentialをhost keychain側へ置く構成を説明します[2]。
AWS AgentCoreはsession isolationを提供する一方、agent code、IAM、input validation、network設定は利用者側の責任として残ると明記します[5]。managed runtimeを使っても権限設計を外部委託できません。Code Interpreterでもnetwork modeを選べるため、Sandbox、VPC、Publicを用途で分けます[6]。
監査ログはsandboxの外へ出す
agentが自分で削除できるworkspace内だけにログを置かず、実行環境の外へ、task ID、inputの分類、tool、target、承認、結果、token発行、egressを送ります。ただしprompt全文や秘密を無制限に記録しないよう、本文とmetadataを分けます。
サンドボックスは、虚偽出力、誤認可、業務規程違反を単独で防ぎません。server側認可、input検査、tool schema、red team、監査と組み合わせます。それでもsandboxが必要なのは、他の防御が一つ失敗した時の被害範囲を閉じるためです。
一次情報と確認範囲
確認日：2026年9月16日。製品仕様・制度は更新されるため、導入時はリンク先の最新版を再確認してください。海外の制度・職業規範は日本へ直接適用せず、相違点と限界を本文に明記しています。