[レポート]AI エージェント SaaS を安全に提供するための自社サンドボックス基盤 - CODE BLUE 2025 #codeblue_jp #codeblue2025

あしざわです。

本記事はCODE BLUE 2025で行われた以下のセッションのレポートです。

セッション情報

AI agents represent a paradigm shift, capable of performing autonomous, complex tasks. But from a security perspective, this autonomy is a double-edged sword, especially when the AI agent can read or write files and execute code. By running these untrusted actions in a sandbox, we can prevent catastrophes without sacrificing their autonomy.

However, for multi-tenant AI agent services, sandboxing the agents presents unique technical challenges. How can we instantly provision an on-demand sandbox, whenever a user invokes an agent?

We faced this exact challenge when building "Takumi byGMO," our AI pentester for application security. To discover vulnerabilities, Takumi needs to inspect the code base, explore the live application, and execute proof-of-concept code. We had to build a platform to let Takumi "go offensive" in a completely isolated, on-demand, and secure environment.

This session dives deep into the architecture of our production sandbox platform. We built our system on Firecracker microVMs, to achieve kernel-level isolation with minimal overhead.

This talk will provide concrete technical approaches from our product for containing the risks of AI agents, all while preserving the capabilities that make them powerful.

Speakers: pizzacat83（ぴざきゃっと）, GMO Flatt Security Inc.

レポート

Overview

• AIエージェントにおいて重要なキーワードが「隔離」
• チャレンジ：サンドボックスを即座にプロビジョニングする手法
• AIエージェントを構築するための技術的な選択の指針としたい

AIエージェント

• 自律的に動くため人間が望まないことをやってしまう
• AIが人間に許可を求めるUI（人間承認方式）の課題
  • 人間がボトルネックになってしまう
  • 何度もOKを押しまくっていると、疲れて確認せずにOKしてしまうようになる。セキュリティ的に甘くなる
  • 人間への承認は銀の弾丸ではない
• AIエージェントを最大限に活用するための検討事項
  • AIエージェントの外部への作用を最小限にする、アクセスを制限する
  • AIエージェントがどのファイルを読めるのか、操作できるのか、外部とどのように接続できるか
    • やらせたくないシナリオ
      • 機密情報を勝手に読んで、外部にアップロードしてしまう
    • 対策例
      • 機密文書は読めるが、外部接続をすべて遮断する
      • 機密文書は読めないが、外部接続はすべてOK
    • これらによって人間の承認をなしにして、リスクを最小化できる

コマンド操作できるAIエージェント

• ローカルとクラウドでは対策が異なる
  • ローカルで動くAIエージェント = Claude Code
  • クラウドで動くAIエージェント = Devin
• ローカル型の懸念事項
  • 人間が触れるものはすべてアクセスできる
• クラウド、マルチテナント型の懸念事項
  • 他のテナントで動く情報にアクセスできる
  • 内部サービスにアクセスできる

隔離(Isolation)

• 何を単位に隔離すべきなのかは、権限の境界で考える
• 横の権限境界：Tenant AはTenant Bのデータにアクセスさせたくない
• 縦の権限境界：ユーザーXはユーザーYのデータにアクセスさせたくない

隔離はセキュリティのためだけではない

• 隔離は、AIエージェントを正常に動作させるためにも重要
  • 同じユーザーが2つのAIエージェントを起動し、それぞれ異なるPRをレビューさせる例
  • 双方のAIエージェントがgit checkoutしてレビューするとコンフリクトしてしまう
  • AIエージェントを正常に動かすために環境を隔離する必要がある
  • 理想的には、たとえ権限レベルが同じでも、AIエージェントごとに作業場所を隔離すべき

AIエージェントのためのサンドボックスで直面する課題

• エージェント単位の隔離
• 素早く立ち上がる
• リソース共有とスケーラビリティ
• （要件次第で）VMレベルの隔離

Takumiができること

• 開発したAIエージェント「Takumi」の実装において、サンドボックスに関する技術的課題に直面した
• White box（ホワイトボックス診断）
  • Gitリポジトリをクローンして、ソースコードをレビュー
  • 脆弱性（例：XSS、エスケープ漏れ）を発見
• Black box（ブラックボックス診断）
  • Webアプリケーションに対して擬似的な攻撃を実行
  • スクリプトを書いて実行
• 両方ともファイル操作・コマンド実行が必要なため、サンドボックスが必須

隔離技術

• VM
  • 隔離レベル：高、オーバーヘッド：高
  • AIにDockerを触らせる場合はVM型の方が適している（Docker in Dockerを避けられる）
• コンテナ
  • 隔離レベル：小、オーバーヘッド：小
• その他（ローカルAIエージェント向け）
  • Seatbelt、Bubblewrap等のユーザーランド/OSセキュリティ機構
• Takumiでは、AIが書いたコードを実行するリスクが大きいため、VMレベルの隔離を採用

アーキテクチャ

• APIサーバーのバックエンドにVMによってプールされたサンドボックスを配置
  • ユーザーのリクエストで利用できるようになる
• VMイメージ：Firecrackerを採用
  • AWSがメインで開発（Lambda、Fargateの基盤技術）
  • 実装言語：Rust
  • ミニマリストなデザイン：Lambdaに必要な機能だけを実装（QEMUとの決定的な違い）
  • Firecrackerのメリット
    • オーバーヘッドが少ない
    • アタックサーフェスが小さい（機能が少ない＝セキュリティ向上）
  • パフォーマンスとセキュリティを両立

設計の選択肢

• Agent in box（エージェント丸ごと隔離）
  • AIエージェント全体をサンドボックスに閉じ込める
  • 例：Codium等をコンテナの中で実行
• Action in box（操作だけ隔離）
  • ファイル操作・コマンド実行など、AIの操作だけをサンドボックス内で実行
  • 例：Devin、Takumi

Action in boxの仕組み

• ユーザーがリクエストを送った場合の処理フロー
  • 例：ユーザー「./logsをサマリしたい」
  • LLM APIが実行 → Tool Useリクエストが返る
    • 例：bash tool、引数「ls ./logs」
    • 重要：この時点ではただのデータ（文字列）であり、コマンド実行はまだしていない
  • AIエージェントの実装が、このデータを実際にbashコマンドに渡して実行する
  • この部分を差し替えることで、実行環境を変更できる
    • そのままbashに渡す → ネイティブ実行
    • VMサンドボックス経由で実行 → 安全な実行
  • AIエージェントから見ると「bashコマンドを使っている」が、実際はサンドボックス内で実行されている

Agent in box vs Action in box の比較

• Agent in box の課題
  • クレデンシャルの漏洩リスク
  • AIエージェント全体をサンドボックスに入れるため、LLM API Keyもサンドボックス内に必要
  • サンドボックス内でAIが任意コマンド実行できる場合、APIキーを読んで外部に送信可能
  • SaaS型では、他のクレデンシャル（Slack、DB接続情報等）も漏洩リスクがある
• Action in box のメリット
  • クレデンシャルをサンドボックス外で管理できる
  • LLMとの通信はサンドボックス外で行う
  • コマンド実行・ファイル操作だけをサンドボックス内で実行
  • LLM API KeyやDB接続情報等をサンドボックス内に入れる必要がない
  • サンドボックス内の情報を最小限に抑えることができる
• それぞれが適しているユースケース
  • Agent in box：プロプライエタリ（クローズドソース）なAIエージェントを実行する場合
    • 操作だけを切り出すことが不可能なため
  • Action in box：自社開発のAIエージェントや、操作を切り出せる場合

まとめ

• AIエージェントをセキュリティ犠牲なしで実行させるためには隔離が大切
• サンドボックス基盤のための技術的なチャレンジをしてきた

感想

「AIエージェントの内製化」は、今もこれからも様々な企業の関心事項だと思います。

今回紹介されたAIエージェントの環境分離(Isolation)がAIエージェントのSaaS製品化のための必須の検討事項であると、セッションを通じて理解できました。

このレポートが、これからAIエージェントの内製化に取り組む方にとって参考になれば幸いです！