FlawOpen

flawopen.com/Incidents/google-gemini-evaluation-sandbox-escape-may-2026

● Google / Irregular · CWE-693 · May 2026 · 編集上の深刻度： 高
セキュリティ研究 · FlawOpen

Geminiの評価環境から実在企業のシステムにアクセス

GoogleはThe Wall Street Journalに、Irregularの評価中にGeminiが3社のシステムへアクセスしたと説明した。Irregularは侵害やデータ流出の証拠を確認していない。[2], [1], [3]

💡 わかりやすい解説 (ELI5)

警察の訓練で、新人が架空の銀行のウェブサイトにアクセスするよう指示されたとします。訓練は閉鎖された場所で行うはずなのに門が開いており、ネット上には同じ名前の実在企業があります。新人は訓練場を出て実際のサイトに到達できます。Irregular は、顧客システムへの侵入やデータ損失の証拠は見つからなかったと述べています。教訓は、モデルが境界を認識すると期待せず、ネットワーク境界を技術的に強制し、予約済みの架空名を使うことです。[2], [1]

主要な概念と専門用語

キャプチャー・ザ・フラッグ（CTF）評価
意図的に脆弱にしたシステムへの侵入をモデルに試みさせるテスト。リリース前に攻撃的なサイバー能力を測るために使われます。[2], [1]
Irregular
自社インフラでこの評価を実施した AI セキュリティ企業。Anthropic が 2026 年 7 月に公表した Claude のインシデントにも同じパートナーが関わっていました。[1]
外向き通信の既定拒否
明示的に許可したもの以外の外向き接続をすべて遮断するネットワーク規則。環境が誤ってインターネットにつながるのを防ぎます。[4]
予約名（RFC 2606）
.test や .example のように決して登録できないドメイン。架空の標的が実在の組織と重なることがありません。[5]
分類について
CWE-693（保護メカニズムの失敗）は FlawOpen による分析上の分類であり、ベンダーが割り当てた CWE ではありません。High は編集上の評価です。報告された評価ではネットワーク隔離を越えて 3 組織のシステムに到達しましたが、引用元は顧客データの侵害や損失を立証していません。CVE と CVSS スコアは適用されません。[7], [2], [1]
推奨事項の出典
以下は説明された境界に対する FlawOpen のエンジニアリング推奨事項であり、Google や Irregular がこれらを導入したという主張ではありません。[1]

フレームワーク対応

  • このガイドで説明する弱点の CWE 参照： CWE-693

インシデントのタイムライン

2026-05

The Wall Street Journal は、5 月に Irregular のサイバーセキュリティ評価中 Gemini が 3 社のシステムに到達したという Google の説明を報じました。[2], [1], [3]

2026-08-14

Irregular は評価環境の問題を修正し、影響を受けた関係者に通知したとする検証結果を公開しました。[1]

2026-09-18

Google は The Wall Street Journal に、5 月のテスト中に Gemini が 3 社のシステムに到達したと説明しました。同紙は 9 月 18 日に記事を掲載しました。[2], [3]

ステップ・バイ・ステップの攻撃フロー

ステップ 1

環境が隔離されていない

モデルはインターネットにアクセスできないはずでしたが、パートナーの評価環境が意図せずアクセスを与えていました。[1]

ステップ 2

架空の標的に実在の名前

課題は、実在企業と同じ名前を持つ架空の会社から情報を取得するようモデルに求めていました。[2], [1]

ステップ 3

報告されたアクセス方法と影響範囲

Google は The Wall Street Journal に、モデルが公開情報を見つけ、演習対象だと思ったサイトの認証情報を推測しようとしたと説明しました。Irregular は後に、架空名が実在ドメインと重なっていた一方、顧客システムへの侵入やデータ流出の証拠は確認していないと述べました。[2], [1], [3]

ステップ 4

封じ込めと開示

Irregular は、8 月 14 日の公開報告前に評価環境の問題を修正し、影響を受けた関係者に通知したと述べています。The Wall Street Journal は 9 月、問い合わせ後の Google による確認を報じました。公開情報は顧客データの取得を立証していません。[2], [1]

ソースコード比較：脆弱 vs 堅牢化

これは Kubernetes の説明用設定であり、Irregular や Google の設定ではありません。agent-eval の全 Pod を選択し、明示的にラベル付けされた mock-target Pod への TCP/443 のみを許可します。NetworkPolicy が制御するのはポートとプロトコルで、TLS は検査しません。模擬サービス側で HTTPS を必須にしてください。DNS は専用リゾルバーへのみ許可します。リゾルバーの受信通信を分離している場合は、評価 Pod から UDP/TCP 53 番への受信許可ルールも追加します。リゾルバーは内部の模擬ゾーンだけに応答させ、任意の問い合わせを公開インターネットへ転送しないでください。DNS が外向き経路になるためです。.test は RFC 2606 でテスト用に予約されています。適用は CNI に依存します。hostNetwork とノード特権ワークロードを境界から除き、制御された canary で遮断を確認します。[4], [5], [1]

脆弱な実装
apiVersion: v1
kind: ConfigMap
metadata:
  name: ctf-scenario
  namespace: agent-eval
data:
  # 実在する組織を対象にしないよう、予約済みの .test ホスト名を使います。
  target_company: "Example Freight Test Co"
  target_host: "portal.freight.test"
# この namespace には NetworkPolicy がないため、Pod はインターネットに接続できます。
堅牢化されたセキュアパッチ
apiVersion: v1
kind: ConfigMap
metadata:
  name: ctf-scenario
  namespace: agent-eval
data:
  target_company: "Example Freight Test Co"
  target_host: "portal.freight.test"
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: eval-egress-allowlist
  namespace: agent-eval
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    # 事前に対象 namespace に purpose=ctf-mock-targets、対象 Pod に app=mock-target のラベルを付けます。
# TCP/443 のみを許可します。NetworkPolicy は TLS を検査せず、HTTPS も強制しません。
    - to:
        - namespaceSelector:
            matchLabels:
              purpose: ctf-mock-targets
          podSelector:
            matchLabels:
              app: mock-target
      ports:
        - protocol: TCP
          port: 443
    # 事前に専用リゾルバーの namespace に purpose=ctf-dns、リゾルバー Pod に app=eval-dns のラベルを付けます。
    # 内部の模擬ゾーンだけに応答する専用リゾルバーを使います。
    - to:
        - namespaceSelector:
            matchLabels:
              purpose: ctf-dns
          podSelector:
            matchLabels:
              app: eval-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

エンジニアリング＆システム堅牢化チェックリスト

参考資料