評価用のAIがサンドボックスを抜けて他社に侵入した — 権限を渡す前に決めること

「請求書の処理や在庫の突合をAIエージェントに任せたい。人がやると月末に必ず残業が出るので」——こういう相談が増えています。任せられる作業は実際にありますし、効果も出ます。ただ、任せる範囲を決めるときの判断材料が、これまでは「なんとなく怖い」という感覚しかありませんでした。

2026年7月に公表された事件は、その感覚に具体的な形を与えました。AIモデルが、与えられた目標を達成するために、複数の会社をまたぐ侵入を自律的に実行したという事例です。

何が起きたか

経緯は、Hugging Face が公開した技術タイムラインと、OpenAI の発表からたどれます。

7月9日ごろ、OpenAI が社内の安全性評価に使っていたモデルが、隔離された評価環境からの脱出を試みました。7月11日から13日にかけて、そこから Hugging Face のデータ処理基盤への侵入が行われます。Hugging Face 側がこれを検知して封じ込めたのが7月16日。この時点で Hugging Face は攻撃元を「自律型AIエージェントシステム」と記載しており、どのモデルによるものかは不明としていました。

OpenAI が自社の評価と結びつけたのは、その後です。内部ログから手がかりが見つかったのが7月18〜19日の週末、対外的に公表したのが7月21日でした。侵入された側が先に検知し、侵入させた側が気づくまでに数日かかったという順序になります。

復元された行動はおよそ17,600件。攻撃の連鎖は、評価用サンドボックスからの脱出、第三者のコード実行環境の踏み台化、公開サービスの指令・中継への利用、Hugging Face の基盤への侵入、Pod内の認証情報とソースコードの取得、Kubernetes 環境での横展開——と続きます。ソースコードへのアクセスなしに、少なくとも1つは新規の脆弱性を自ら見つけて連鎖させたとされており、OpenAI はこれを「前例のない（unprecedented）」と表現しました。

なお、公開されているモデルやデータセット、ソフトウェアサプライチェーンが改ざんされた証拠はないとされています。顧客のコンテンツで到達されたのは、評価用ベンチマークに関係するとみられる5つのデータセットでした。

目的は「テストで高得点を取ること」だった

この事件で技術的に重要なのは侵入の巧妙さですが、業務にAIを入れる側にとって重要なのは動機のほうです。

モデルの目的は、機密情報を盗むことでも、システムを壊すことでもありませんでした。ExploitGym というベンチマークの「解答」を手に入れることです。「ハッキング能力のテストで高い点を取れ」という目標が与えられ、その目標に対して過剰に最適化した結果、テストの外側にある実システムへ手が伸びました。

ここには悪意がありません。あるのは、目標に対する忠実さと、越えてはいけない線が目標の中に書かれていなかったことです。

この構図は、規模を落とすとそのまま社内の話になります。「月末の請求突合を完了させろ」という目標を与えたエージェントが、データが足りないので別のシステムを見に行く。権限が足りないので別の経路を探す。人間の担当者なら「そこまでは自分の仕事ではない」と止まる場所で、目標だけを渡されたエージェントは止まりません。 止まる理由が与えられていないからです。

中小企業の導入に置き換えると何が対応するか

「フロンティアモデルの評価環境の話で、うちには関係ない」と読める事件ですが、対応関係を並べると距離は近くなります。

いちばん現実的なのは2つめと4つめです。エージェントに何かをさせるには認証情報を渡す必要があり、渡した先の環境は多くの場合、人が使う環境より監視が薄い。そして「エージェントが何をしたか」を後から追える形でログを残している会社は、まだ多くありません。

本番データベースの削除という形で顕在化した事例はAIエージェントが本番DBを削除した事件で扱いました。今回の事件は、それが社外にまで及ぶことを示した点で範囲が広がっています。

権限を渡す前に決めておくこと

導入を止める話ではありません。決めておけば渡せます。順番としては次のとおりです。

1つめ。目標ではなく、完了条件を渡す。 「請求の突合を完了させろ」ではなく、「このシートの範囲で突合し、一致しない行があれば一覧にして止まれ」。達成できなかったときにどうするかまで書いてある指示は、越境の入口を塞ぎます。今回の事件は、達成できなかったときの振る舞いが定義されていなかったことに起因しています。

2つめ。エージェント専用の権限を作り、人のアカウントを流用しない。 担当者のアカウントをそのまま使わせると、その人ができることは全部できてしまいます。専用のアカウントを作り、必要な範囲だけ与える。手間はかかりますが、後から「何をしたか」を切り分けられるのは、この分離があるときだけです。

3つめ。取り消せる作業から始める。 下書きの作成、一覧の生成、社内向け通知。これらは間違っても後から直せます。逆に、外部への送信、データの確定、決済の実行は、最初の対象にしない。慣れてから広げるほうが、結果的に早く広げられます。

4つめ。行動のログを、始める前に取れる形にしておく。 動かしてから「何をしたか調べたい」となっても、記録がなければ調べられません。今回、Hugging Face 側が17,600件の行動を復元できたのは、記録があったからです。事後に作れないのはログだけなので、ここは着手前に用意します。

隔離された実行環境をどう用意するかという実装側の話はCloud Run sandboxesでAI生成コードを安全に実行するに、Google Workspace の中でエージェントに権限を渡す場合の統制はAIが勝手にメールを送る時代にまとめています。

最初に任せる作業の選び方

導入の相談を受けたとき、最初の1本を選ぶ基準として使っているのは次の問いです。

「この作業をエージェントが1,000回実行したとして、困るか」

社内向けの日次サマリー作成なら、1,000回動いても迷惑なだけで、実害は出ません。一方、顧客へのメール送信は1回目から取り返しがつきません。この問いは、作業の重要度ではなく取り消し可能性で並べ替えるためのものです。効果の大きさで選ぶと、たいてい取り消せない作業から始めることになります。

もう1つ。エージェントが「できませんでした」と返してきたときに、人が引き取れる状態かも確認してください。引き取れないなら、それはエージェントに任せる前に、業務として属人化しているということです。自動化の前に整理する対象になります。

社内のどの業務からAIエージェントを入れるべきか整理したい、既に動かしているエージェントの権限とログが妥当な形になっているか見てほしい——そうしたご相談は、グリームハブの開発・AI・自動化のご相談で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。

Sources

• Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident — Hugging Face
• OpenAI and Hugging Face partner to address security incident during model evaluation — OpenAI（2026年7月21日）
• OpenAIのAIモデルが自律的に行ったとされるサイバー攻撃についてまとめてみた — piyolog
• OpenAI・Hugging Faceインシデントの内幕：背後に人間の攻撃者がいないAI侵害 — トレンドマイクロ
• OpenAI called the Hugging Face attack unprecedented. But we’ve been here before. — MIT Technology Review