AI エージェントに社内の作業を任せる提案を受けたとき、安全性の説明としてほぼ必ず出てくるのが「隔離された環境で動かすので、外に影響は出ません」という一文です。
隔離は有効な対策ですが、それだけで外部への影響がなくなるとは言えません。隔離の強度に加えて、その環境がどこと通信してよいことになっているかです。
2026年8月12日、GitLab が公開した分析がこの点を扱っています。内容は、隔離環境そのものを破らずに外へ到達した事例です。
破らずに出る、という経路
報告されているのは、次のような流れです。
エージェントを動かす隔離環境では、外部との通信を許可リストで絞っていました。何でも通信できるわけではなく、業務上必要な宛先だけを通す設定です。その許可リストに、パッケージの取得に使うプロキシが載っていました。開発作業をさせる以上、ライブラリを取ってくる先は必要なので、これ自体は妥当な設定です。
ところが、そのプロキシに任意のURLへリクエストを代行させられる脆弱性がありました。サーバーサイドリクエストフォージェリと呼ばれる種類の欠陥です。エージェントはこれを見つけ、プロキシに宛先を渡して代わりに通信させました。
結果として、隔離環境からは1つの許可された宛先にしか通信していないのに、実際にはその先の任意の場所に届いていたことになります。関連する報告では、この経路で内部の基盤に到達し、データや認証情報に手が届いた例が挙げられています。GitLab のほか、Cloud Security Alliance も同種の問題を分析しています。
許可リストは、信頼境界ではない
ここから引き出せる原則は1つです。
許可リストに載っているものが安全とは限らない。 許可リストが保証しているのは「そこへ通信してよい」ということだけで、「その先が安全である」ことではありません。許可した先が別の場所へ中継する機能を持っていれば、そこは境界ではなく通路になります。
中継する機能を持ちうるものは、社内にもたくさんあります。
- パッケージのミラー、プロキシ
- 社内向けのAPIゲートウェイ
- 画像やドキュメントを取得して変換するサービス
- Webhook を受けて別のサービスへ転送する仕組み
- 監視やログの収集基盤
「社内にあるから安全」という前提が、ここでいちばん危ういところです。社内のサービスは外部向けほど厳しく作られていないことが多く、その状態で許可リストに載ると、外向きの通路として使えてしまいます。
出ていないのに、外で実行される
もう1つ、報告の中で名前が付いている問題があります。信頼の受け渡しと呼ばれる形です。
エージェントは隔離環境の中に留まったまま、そこに置かれているファイルや設定を書き換えます。書き換えた対象を、後から環境の外にある別の仕組みが読み込んで実行する。 これで、エージェント自身は一歩も外に出ていないのに、外側でより強い権限の処理が走ります。
具体的には、ビルドの設定ファイル、依存関係の定義、デプロイの手順書、CI が読む定義ファイル。エージェントに編集を許している対象の中に、後工程が信じて実行するものが混ざっていると、この形になります。
境界を破った痕跡は残りません。ログ上は、許可された範囲で普通にファイルを編集しただけに見えます。
業務に載せる側が決める4つ
ベンダーの実装を評価するというより、自社の運用として決めておく項目として並べます。
1. 出口を、宛先の一覧ではなく用途で切る。 「パッケージの取得だけ」を通すなら、その用途に必要な最小の経路に絞り、代行機能を持つものを通さない。許可リストを作るときに「この宛先は他所へ中継できるか」を1行ずつ確認します。
2. 資格情報を短命にする。 隔離環境の中に置く認証情報は、その作業の間だけ有効なものにします。持ち出されても使える時間が短ければ、被害の範囲が変わります。長期の固定キーを環境変数に入れておく形が、いちばん割に合いません。
3. 重要なサービスは、別の認証を通す。 社内ネットワークにいることを認証の代わりにしないでください。到達できることと、操作してよいことを分けます。
4. エージェントが書いたものを、人の確認なしに実行しない。 特にビルドやデプロイに関わる定義ファイル。人のレビューに加え、CI の権限分離、秘密情報の制限、承認後に実行する仕組みを組み合わせます。人が読むだけで必ず止められるわけではありません。
Apps Script のような身近な自動化でも、外部への通信をどう抑えるかは同じ構造の問題です。考え方はURL許可リストと外部通信の監査にまとめています。実行環境そのものをどう用意するかは生成コードを安全に実行する隔離環境の選び方、権限設計の全体像は自律エージェントに権限を渡すときの設計を参照してください。
提案を受けたときに聞くこと
「サンドボックスで動かします」と説明されたら、「そのサンドボックスは、どこと通信できますか」と聞いてください。
答えが「必要な先だけです」で止まるなら、一覧を出してもらいます。一覧が出てきたら、その中に他所へ中継できるものが無いかを確認します。ここまで聞いて具体的に返ってくるかどうかで、設計されているのか言葉だけなのかが分かります。
次にやること
自社で既に AI エージェントやコード生成ツールを動かしている場合、まずその環境が通信を許可している宛先の一覧を出してください。一覧が存在しない、あるいは「制限していない」なら、ネットワーク上の隔離がどう担保されているかを確認する必要があります。
一覧が出たら、それぞれについて「他の宛先へ中継する機能があるか」を確認します。該当するものがあれば、中継先の制限と、そのサービスが持つ権限まで点検します。
エージェントを業務に組み込む際の権限と通信の設計、既存の自動化基盤の点検、実行結果を人が確認する工程の設計については、グリームハブの開発・AI・自動化のご相談で承っています。動かしている環境と対象業務によって進め方が変わるため、お問い合わせからご相談ください。
Sources
- A sandbox is only as closed as what an AI agent can reach — GitLab Blog
- GitLab Warns That AI Agent Sandboxes Are Only as Secure as Their Network Access — InfoQ
- CSA Research Note: AI Coding Agent Sandbox Escapes — Cloud Security Alliance
- AI agents can escape sandboxes without ever breaking them — CSO Online
