Agent_Core_Interpreter_その他のSandox環境について.pdf

Transcript

1. JAWS-UG彩の国埼玉支部 #12 AWS re:invent 2026 準備回 AgentCore Interpreter、その他の Sandbox環境について AgentCore Interpreter、Cloud Run Sandbox、ACA Sandboxをコード生成した実行基盤として試した時の知見 蛭田 聡司 (Soushi Hiruta) · @web_se AgentCore Interpreter、その他のSandbox環境について 01 / 22
2. 02 — 自己紹介 自己紹介 蛭田 聡司 Soushi Hiruta 写真 / アイコン お仕事 基盤設計構築（AWS CDK) Community AWS Community Builder 2025 (Container Category) 海外カンファレンス re:invent 2014、KubeConEU 2023〜2026 KubeDay Singapore 2023 X @web_se · GitHub clouddev-code AgentCore Interpreter、その他のSandbox環境について 02 / 22
3. 03 — 対象読者 この発表は誰向けか こんな人に こんな人に こんな人に LLM 生成コードを本番で実行す る仕組みを作っている AWS / Google Cloud / Azure のどれで組むか迷っている サンドボックスの境界が実際に 効くのか確かめたい 前提知識 話さないこと コンテナ / VM の基本、IAM・IMDS・SSRF の用語 料金の厳密な見積り、各フレームワーク統合の実装詳細 AgentCore Interpreter、その他のSandbox環境について 04 / 22
4. 03 — 背景 LLM が書いたコードは信頼できない前提で動かす 01 02 03 任意コード実行 認証情報の窃取 データの持ち出し eval / exec やシェル呼び出しを含むコー ドが生成され得る。実行環境そのものを 隔離し、ホストや他テナントから切り離す 必要がある。 メタデータサーバー (169.254.169.254) への SSRF で IAM 認証情報を取られる のが典型的な攻撃面。 外部サーバーへの HTTP 送信 (exfiltration)。既定で egress を遮断し、 許可を明示的にできるかが鍵。 選定時に見る6つの評価軸 ・ 隔離の強度と透明性 ・ 既定のネットワーク境界 ・ リソースの専有性 ・ クレデンシャル漏えい経路 ・ 実行時間・リソース上限 ・ 監査可能性 AgentCore Interpreter、その他のSandbox環境について 05 / 22
5. 04 — 比較対象 4製品の位置づけ (2026年9月時点) AWS Google Cloud Azure Azure AgentCore Code Interpreter Cloud Run sandboxes Container Apps Sandbox Container Apps dynamic sessions GA 2025年10月 パブリックプレビュー GA 2026年9月 GA 2024年11月 # 隔離技術 # 隔離技術 # 隔離技術 # 隔離技術 専用 microVM (Firecracker系 と推定、ハイパーバイザーは非 公開) 非公開 (ホストインスタンス内の プロセス実行境界、追加VM起 動なし) Hardware-lsolated mcroVMs Hyper-V ベースの軽量 VM マネージド度が最も高い。 Strands Agents / Bedrock に閉 じるなら最有力。秒課金で I/O 待ちは無課金。 既存 Cloud Run に --sandbox-launcher で追加。追 加料金なしだが専有リソース枠 がない。 一時停止機能と再開機能ｇ飽組 み込まれた安全な一時的なコン ピューティング環境。 Sandbox Groupが管理境界 運用実績が最長 (Copilot で日 40万セッション超)。フレーム ワーク統合が最も広い。 AgentCore Interpreter、その他のSandbox環境について 06 / 22
6. 05 — サマリー 一目でわかる差分 : 隔離・ネットワーク・課金 観点 AgentCore Cloud Run sandboxes Container AppsSandbox Azure dynamic sessions 隔離技術 専用 microVM (非公開) 非公開 (ホスト内プロセス境界) microVMs Hyper-V 分離単位 セッション ホストコンテナ内 Sandbox Group セッション (VM境界) ネットワーク既定 Sandbox / Public / VPC の選択制 全 egress 遮断 ポリシー未設定だと全許可 egress 無効 リソース専有 セッションごとに独立 ホストと共有 CPU、メモリ、ディスクはSandboxご とに割当 セッションプール専有 起動レイテンシ 数百ms〜 平均 500ms 1秒未満 ミリ秒〜サブ秒 秒単位アクティブ消費 セッション時間課金 課金 秒単位アクティブ消費 追加料金なし no additional cost or premium on top of standard Cloud Run service pricing 隔離・既定遮断の方向性は4製品共通。差が出るのは透明性・リソース専有性・課金モデル。 AgentCore Interpreter、その他のSandbox環境について 07 / 22
7. 06 — 隔離アーキテクチャ 隔離の強さは同方向、透明性に差がある 隔離技術の公式記載と透明性 4製品に共通する設計思想 ゼロトラスト・既定で最小権限 Azure dynamic sessions 透明性 高 Hyper-V ベースの軽量 VM。技術名は公式に明言、実装詳細は非公開 ✓ ネットワークは既定で遮断、許可は明示 AgentCore Code Interpreter ✓ ファイルシステムは読み取り専用または専有 ✓ 親環境の Secret・メタデータサーバーは非公開 透明性 中 各セッションが専用 microVM 上で実行と明記。ハイパーバイザーの実体は非公開 Container Apps Sandbox 透明性 中 microVMs ✓ セッション終了時に状態を破棄 (microVM 終了 ・tmpfs 揮発・Pod 削除) Cloud Run sandboxes 透明性 低 "highly optimized sandbox environment" のみ。sandbox 固有の隔離実装は未記 載 AgentCore Interpreter、その他のSandbox環境について 08 / 22
8. 07 — セキュリティ境界 既定で遮断、許可は明示的に 項目 AgentCore Cloud Run sandboxes Container Apps Sandbox Azure dynamic sessions ネットワーク既定 選択制 (Sandbox=S3のみ / Public / VPC) 全 outbound 遮断。--allow-egress で許可 ルールベース policy エンジン。host / path / method 単位の Allow / Deny / egress 無効。プール単位で有効化 可 ファイルシステム既定 セッション専有。S3 / EFS は VPC モード必須 read-only。--write で tmpfs オー バーレイ Volumes (Azure Blob 共有 / Data Disk 専有) セッション専有。アップロード上限 128MB 認証 / 認可 IAM 実行ロール + API 単位アクショ 親の環境変数 / Secret / メタデータ ン。confused deputy 対策あり は非到達。--env で明示渡し Azure RBAC、Azure Container Apps SandboxGroup Data Owner Entra ID + Session Executor ロー ル。マネージド ID は既定無効 監査ログ CloudTrail + CloudWatch Activity log Log Analytics 明記なし (Cloud Run 標準ログ) Azure は「マネージド ID を有効化すると信頼できないコードがトークンを取得できる」と公式に注意喚起。クレデンシャル経路は導入時に個別検証が必要。 AgentCore Interpreter、その他のSandbox環境について 09 / 22
9. 08 — 実行環境 実行時間・同時実行の上限は 項目 AgentCore Runtime Cloud Run sandboxes Container Apps Sandbox Azure dynamic sessions 対応言語 Python / JavaScript / TypeScript 言語非依存 (任意コンテナ) Python SDK / REST / CLI (aca) Python (GA) / Node.js (プレビュー) / Shell / Custom container セッション永続性 ステートフル。既定15分、最大8時間 既定エフェメラル。run --detach で名 メモリ + ディスクの完全な状態を保 前付き永続化 存。create-from-snapshot で複製 Timed (300〜3600秒 cooldown) / OnContainerExit 1回の実行時間上限 セッションタイムアウト依存 (最大8時 明記なし（※ 間) 最大同時実行数 記載なし GPU 記載なし 明記なし（※ 220秒 (Code interpreter) 明記なし (ホストの CPU / メモリに 依存) SandboxとExpress合計で2,000コ ア 600 (Code interpreter) 公式未確認 非対応 Serverless GPU (early access) 上限が明記されていない製品は、暴走コードへの安全弁がどの粒度で効くかを実機で確認してから採用する。 AgentCore Interpreter、その他のSandbox環境について 10 / 22
10. 08 — 実行環境 実行時間・同時実行の上限は AgentCore Interpreter、その他のSandbox環境について 11 / 22
11. 08 — 実行時間上限 AgentCore は8時間固定、 Azure はアイドル検知で寿命管理 AWS Azure Google Cloud Bedrock AgentCore Runtime (非同期) Container Apps Sandboxes Cloud Run Job Sandbox 8時間 上限なし※ 7日※ アクティブ実行の絶対上限 アクティブ実行の絶対上限 アクティブ実行の絶対上限 固定の絶対上限。公式ドキュメントに明記さ れ、経過で強制終了。暴走コードへの安全 弁として分かりやすい。 Auto-suspend (アイドル秒数、上限値の記 載なし) + Auto-delete (サスペンド後 n 日) の組み合わせ。アクティブ利用中の強制終 了は記載なし。 cloud Run jobのタイムアウトまで寿命があ りそう 設計思想の違い: AgentCore は「単一の絶対タイムアウト」、Azure 系は「アイドルならサスペンド、長期未使用なら削除」という間接的な寿命管理。長時間バッチを載せるなら前者の 8h が制約になり、後者は上限の不在そのものを運用で補う必要がある。 AgentCore Interpreter、その他のSandbox環境について 12 / 22
12. 09 — 料金体系 課金の性質が 3タイプに分かれる TYPE A TYPE B TYPE C 使った分だけ秒課金 既存インフラに相乗り、追加料金 なし セッションプールの専有時間課 金 AgentCore Code Interpreter Cloud Run Azure dynamic sessions CPU $0.0895/vCPU時、メモリ $0.00945/GB時。I/O 待ちで CPU を使わ なければ無課金。月1万リクエスト試算で 約 $109/月。 Cloud Run は "No additional cost or premium" と明記。GKE は Pod Snapshots + オーバーサブスクリプション で同一 VM あたり最大75%削減 (61→274 エージェント/ノード)。 Code interpreter は約 $0.03/セッション 時間。Custom container は Dedicated Plan (専用 E16 インスタンス)。正確な単 価は地域依存。 実行頻度と並列度で最適解が変わる。Cloud Run sandboxes は専有枠がないため、スケール時はホストインスタンス側のリソース見積りが別途必要。 AgentCore Interpreter、その他のSandbox環境について 13 / 22
13. 10 — 検証構成 検証構成 AgentCore Interpreter、その他のSandbox環境について 14 / 22
14. 11 — 実機検証 脆弱な Agent 生成コードを AgentCore で動かす 用意した脆弱コード (f-string / eval 注入) 検証環境 ユーザー入力でレポート文字列を組み立てるツールをLLM に作らせた典型例 Code Interpreter aws.codeinterpreter.v1 (System ARN、 Sandbox モード) Region us-west-2 ランタイム Python 3.12.13 / Amazon Linux 2023 aarch64 実行ユーザー 非 root (uid=991) 呼び出し bedrock-agentcore-mcp-server 経由 (MCP) def render_report(user_name: str, note: str) -> str: template = f"f'Report for {user_name}: {note}'" # BUG: ユーザー入力を eval 対象のソースに直接埋め込み return eval(template) # note に {...} を含む値を渡すと新たな式として評価される render_report("Alice", "{__import__('os').system('id')}") 検証の狙い: 脆弱性そのものは防げなくても、サンドボックスの境界 (ネット ワーク分離・認証情報の非露出) が攻撃の被害範囲 (blast radius) をどこま で封じ込めるかを実測する。 AgentCore Interpreter、その他のSandbox環境について 裏付け MMDS レスポンスヘッダに Server: Firecracker API を確認。ド キュメント記載どおり Firecracker microVM 上で動作している。 15 / 22
15. 12 — 検証結果 注入は成功するが、持ち出し経路は閉じていた #1 #2 #3 #4 #5 コマンド実行 (subprocess.run(['id'])) uid=991 が返り実行成功。アプリ層の脆弱性はサンドボックスでは防がない (想定通り) 防がない IMDS / MMDS (169.254.169.254) への SSRF トークン取得は可能だが iam/security-credentials/ は 404。露出するのは instance-id・placement 等の非機微情報のみ 部分ブロック 外部インターネットへの持ち出し (example.com 等) DNS 解決が gaierror、生 TCP も Network is unreachable 許可された AWS サービス (S3) への到達 (対照) s3.us-west-2.amazonaws.com への DNS / TCP 443 は成功。記載どおり 窃取した認証情報で AWS API (STS / S3) 呼び出し boto3 に認証情報が存在せず NoCredentialsError。持ち出し経路が存在し ない AgentCore Interpreter、その他のSandbox環境について 完全ブロック 許可 追加防御層 16 / 22
16. 13 — Cloud Run sandboxes 深掘り ホストコンテナ内で CLI から呼ぶ軽量サンドボックス sandbox CLI サブコマンド イメージ内の /usr/local/gcp/bin/sandbox を subprocess で呼ぶ ネットワーク 既定で全 outbound 遮断。--allow-egress で明示許可。親の環境変数・Secret・メタ データサーバーは非到達。 # 有効化 (第2世代実行環境限定) gcloud beta run deploy ... --sandbox-launcher ファイルシステム # 一時サンドボックスで実行→破棄 既定 read-only。書き込みは tmpfs オーバーレイに隔離され終了時に破棄。 --export-tar / --import-tar で差分を退避・復元。 sandbox do -- python3 script.py sandbox do --allow-egress -- curl https://... # 名前付きで永続化し再利用 sandbox run --detach --sandbox-name s1 リソース ホストインスタンスの CPU / メモリを共有。追加 VM は起動しない (1,000 サンドボック ス平均 500ms)。 sandbox exec s1 -- python3 step2.py # 状態の複製・退避・終了 公式ドキュメントに未記載 (2026-09-28 時点) sandbox fork --tar / sandbox tar / sandbox delete sandbox 固有の隔離実装、HTTP/gRPC 直接 API の有無、タイムアウト・同時実行 数の上限、専用 IAM モデル、メモリ状態の checkpoint/restore。GA 前は再評価が必 要。 AgentCore Interpreter、その他のSandbox環境について 17 / 22
17. 14 — Azure の2つの選択肢 Azure の代替候補は Dynamic Sessions より Sandboxes Dynamic Sessions GA preview Sandboxes GA · sessions / session-pool 2026-02-01-preview · Microsoft.App/SandboxGroups 起動方式 REST API 経由。identifier でセッション指定 起動方式 Python SDK / REST / CLI (aca) で execute API を直接実 行 Egress EgressEnabled / Disabled の二値のみ Egress ルールベース policy エンジン。host / path / method 単位の Allow / Deny / Transform スナップショット 非対応 (cooldown 後に破棄) スナップショット メモリ + ディスクの完全な状態を保存。 create-from-snapshot で複製 永続ストレージ 非対応 永続ストレージ Volumes (Azure Blob 共有 / Data Disk 専有) SDK REST のみ。LangChain / Semantic Kernel 等の executor 経由が主 SDK azure-containerapps-sandbox (Python)、CLI、Bicep、 REST Cloud Run sandbox 実装との近さ: 中〜低 Cloud Run sandbox 実装との近さ: 高 (fork / export-tar 相当以上) 未検証: Sandboxes 内から Azure IMDS (169.254.169.254) に到達できるかはドキュメントに明記なし。default-deny と Full inspection の両方で実機確認が必要。 AgentCore Interpreter、その他のSandbox環境について 18 / 22
18. 15 — 所見 サンドボックスは被害を封じ込めるが脆弱性は防がない 01 02 アプリ層の脆弱性は防げない ネットワーク分離は実測でも機能 eval() ベースの注入は Code Interpreter 内でも任意コード実行に至っ た。コード生成・レビュー段階での対策 (eval / exec 禁止、入力サニタイ ズ、静的解析) は別途必要。 外部への DNS 解決・接続は完全にブロック。HTTP exfiltration という典 型的な持ち出し手口は成立しなかった。 03 04 SSRF は到達するが IAM 認証情報は露出しない 既定では認証情報自体が存在しない Firecracker MMDS は IMDSv2 的なトークン方式で保護され、 iam/security-credentials/ は存在しない (404)。 System ARN・実行ロール未設定では boto3 が NoCredentialsError。 実行ロールを渡す場合は最小権限化と aws:SourceAccount / aws:SourceArn 条件を必ず設定する。 AgentCore Interpreter、その他のSandbox環境について 19 / 22
19. 16 — 選定ガイド ユースケース別の推奨 おすすめ おすすめ おすすめ おすすめ AgentCore Code Interpreter Cloud Run sandboxes Container Apps Sandbox Azure dynamic sessions # こんなとき # こんなとき # こんなとき # こんなとき すでに AWS / Bedrock でエー ジェントを構築しており、秒課金で 細かくコスト最適化したい Google Cloud で Vertex AI / ADK を使っており、既存 Cloud Run サービスに手軽にコード実行 を足したい microVMs マルチクラウド / フレームワーク横 断で最も枯れた統合を求める、ま たは Microsoft 365 / Copilot に 近い # 理由 # 理由 # 理由 # 理由 Strands Agents / Bedrock との統 合が最も自然。I/O 待ち無課金で コスト効率が良い。 ADK 公式 Executor あり。本番は GA 後に再評価を推奨。 Cloud Run Sandboxに並んで Sandbox基盤として文句ない。 統合の幅が最も広く、本番実績 (Copilot) も最長。MCP サーバー 化で実装コストも低い。 AgentCore Interpreter、その他のSandbox環境について 20 / 22
20. 17 — 留意事項 採用前に確認すべき不確実性 AgentCore Cloud Run sandboxes 隔離のハイパーバイザー技術が非公開。セキュリティ監査・コンプライア ンス要件が厳しい場合は AWS に個別確認が必要。実機では Firecracker を示すヘッダを確認済み。 パブリックプレビューのため SLA・リソース上限・GPU 対応が変わる可能 性が高い。隔離実装・直接 API・タイムアウト・専用 IAM が未記載 (2026-09-28 時点)。 8時間のような明確なタイムアウトがないので、暴走したときの課金には 気をつける Container Apps Sandbox Azure 8時間のような明確なタイムアウトがないので、暴走したときの課金には 気をつける Code interpreter の 1 回 220 秒上限は長時間処理に不向き。 GPU・JavaScript はプレビュー / early access。Sandboxes (preview) の IMDS 到達可否は未検証。 AgentCore Interpreter、その他のSandbox環境について 21 / 22
21. 18 — TAKEAWAYS 持ち帰れること 01 02 4製品とも「既定で遮断・最小権限」。差は透明性・専有 性・課金 サンドボックスは blast radius を封じ込める層であっ て、脆弱性対策の代わりではない GKE が最も透明 (gVisor / OSS)、Cloud Run はホスト共有で専有枠なし、 課金は秒 / 相乗り / セッション時間の3タイプ。 AgentCore の実機検証で注入は成功したが、外部通信は遮断され IAM 認証情報も露出しなかった。 03 04 上限の「明記」が運用の安全弁になる 実行ロールを渡すなら最小権限 + confused deputy 対策 Azure は 220 秒 / 600 同時実行、AgentCore は 8 時間を明記。明記のな い製品は実機で確認してから採用する。 既定で認証情報が無いことに頼らず、aws:SourceAccount / aws:SourceArn 条件を付けて多層防御を保つ。 AgentCore Interpreter、その他のSandbox環境について 22 / 22