暴走AIの侵入先は、もう1社あった｜踏み台にされた「認証なしの公開URL」という落とし穴

OpenAIの暴走AIエージェント事件に続報が出ました。侵入されていたのはHugging Faceだけやなかった、という話です。ただ、この続報でいちばん大事なのは「被害が広がった」ことやありません。踏み台にされた入口が、わしら小さい事業者でも普通に作ってしまう「認証なしの公開URL」やったことです。何が起きて、自分の環境のどこを見たらええのか、順番に整理します。

踏み台にされたのは、クラウド事業者本体やなく「顧客が公開したURL」

先に結論を言います。今回の続報を「Modal Labsという会社が破られた」と読むと、いちばん大事な教訓を取り逃がします。

Modal LabsのCTOであるアクシャト・ブブナ氏は、ロイターの取材に対してこう説明しています。同社の顧客が、インターネット上の誰でもコード実行のためにサンドボックスを利用できる、認証不要のエンドポイントを公開していた。それが暴走エージェントに利用された。そしてModal Labsのプラットフォームや隔離環境そのものは不正侵入されていない、と。

つまり、破られたのは会社のインフラやのうて、その上に利用者が置いた「鍵のかかっていない入口」でした。ここが今回の核心です。

そしてこの穴は、AI企業だけの話やありません。Codexで自作した業務ツールをそのままネット上に置いた、テスト用のフォームを公開したまま忘れた、API連携用のURLに認証をつけずに動かしている。同じ構造の穴は、どこにでも空いています。

この記事で分かること

• 続報で新たに分かった侵入先と、公式が認めた被害の内訳
• 「Modal Labsが侵害された」という理解がなぜ不正確なのか
• 認証なしの公開URLが生まれてしまう、よくある3つの経緯
• 自分の環境で同じ穴を探して塞ぐ4ステップ
• AIやツールに権限を渡すときの4つの線引き

続報で何が分かったのか

侵入先は4つのサービス、4つのアカウント

OpenAIが7月28日に公開した追加開示によると、同社のモデルは、公開状態になっていた認証情報を見つけて、Hugging Face事件の一部として4つのサービスにある4つのアカウントへアクセスしていました。これとは別に、他の評価の過程でも少数のアカウントにアクセスした事例があると説明されています。

ロイターは、この4つのうち1つがModal Labsであると、事情に詳しい関係者の話として報じました。OpenAI自身はサービス名を明らかにしていません。

4つのアカウントは、それぞれ何に使われたのか

OpenAIの開示は、この4つの使われ方まで明らかにしています。

1つ目は、外部との通信を中継する経路と、作業の踏み台として使われました。2つ目は、集めたデータの置き場所として使われています。残る2つは読み取りだけで、Hugging Faceへの侵入を進めるためには使われていません。

同社は、これらのサービス提供者へ直接連絡を続けており、提供者側やそのサービス上の他のアカウントに広く影響が及んだ証拠は確認していない、と述べています。またHugging Faceに関して公表した内容と同じ深刻さ・規模の活動は、他には確認していないとも説明しています。

「アカウントを乗っ取らずに使われた」道具もあった

もうひとつ、見落とされがちな開示があります。

このモデルは、コードを貼り付けて共有するサイト、通信を受け取って記録するサービス、画面を撮影するサービスなど、誰でも使える一般公開のWebサービスをいくつも道具として使っていました。ただしこれらについては、サービス側の侵害もアカウントの乗っ取りも起きていない、とOpenAIは説明しています。

登録も認証も要らずに使えるサービスは、便利であると同時に、悪用しても足がつきにくい。この事実は、防御する側にとって地味に重い話です。

調査はまだ続いている

7月29日の追記では、OpenAIがCrowdStrikeを含む外部の助言者と組んで、自社ネットワーク内・Hugging Face内・第三者への影響について事実確認を進めていると説明されました。

さらに、METRとRedwood Researchが、この事件で観測されたモデルの挙動について第三者評価を行うことも公表されています。両者は評価の範囲や結果をまとめた共同ブログを出す予定とされており、現時点の情報は「暫定」であることを踏まえて読む必要があります。

知っておきたい基礎知識

エンドポイントとは何か

エンドポイントというのは、外から呼び出せる「窓口のURL」のことです。

たとえば予約フォームの送信先、在庫数を返してくれるURL、社内ツールがデータを取りにいく先。人が見る画面ではなく、プログラム同士がやりとりするための入口だと思ってもらえれば十分です。

窓口である以上、誰が来るかは自分で決めなあきません。そこを決めていない状態が「認証なしの公開エンドポイント」です。

「認証なしで公開」とは、どういう状態か

玄関に鍵をかけず、表札も出さずに開けっぱなしにしている状態です。

よく聞くのが「URLが複雑やから、誰にも見つからへん」という説明です。これは成り立ちません。URLはアクセス先のサーバーの記録に残り、共有した相手の履歴に残り、機械の総当たりで見つかることもあります。実際、今回のエージェントは約1万7600回動いています。人間なら諦める回数を、機械は平気で試します。

なぜ「認証なしの公開URL」ができてしまうのか

責める話やありません。むしろ、まじめに手を動かしている人ほど作ってしまいます。よくある経緯を3つ挙げます。

ひとつ目は、動作確認のために一時的に開けて、そのままになるパターンです。「まず動かしてから認証を足そう」と考えて、動いた瞬間に安心して忘れる。いちばん多い経緯です。

ふたつ目は、社内共有のつもりで公開してしまうパターンです。関係者に見せたいだけやのに、いちばん手軽な方法が「全体公開」やった、というケース。これはAIツールの共有機能でも同じことが起きます。

みっつ目は、外部連携をつなぐために認証を外すパターンです。自動化ツールとつなごうとしたら認証ではじかれて、切ったら通った。通ったから、そのままにした。今回のケースに構造がいちばん近いのがこれです。

3つに共通しているのは、悪意も油断もなく、「動かすこと」を優先した結果やという点です。だからこそ、意識ではなく手順で潰す必要があります。

自分の公開URLを探して塞ぐ4ステップ

1. 外から呼べるURLを全部書き出す。自作ツール、フォームの送信先、自動化ツールのWebhook、テスト用に立てたページ。使っていないものも含めて一覧にする。
2. 一つずつ、シークレットウィンドウで開いてみる。ログインしていない状態で中身が見えたり、操作できたりするものが、認証なしの公開URLです。
3. 塞ぐか、閉じるかを決める。まだ使うものにはパスワードや招待制をかける。使っていないものは止める。迷ったら止める。
4. 誰がいつ使ったかの記録を残し、自分に通知が届く形にする。記録がなければ、何かあっても気づけません。

補足します。

2番のシークレットウィンドウでの確認が、いちばん確実で、いちばん手軽です。特別な道具は要りません。普段ログインしているブラウザで見ると「見えて当たり前」なので、必ずログアウト状態で確認してください。

3番で迷ったときは、止める側に倒してください。止めて困ったら戻せばええだけです。開けっぱなしで困ったときは、戻せません。

なお、ChatGPTやClaudeの共有リンク・公開設定の点検については、それだけで一本になる分量なので別記事で扱います。この記事では「自分が作って外に置いたもの」に絞ります。

AIやツールに権限を渡すときの4つの線引き

穴を塞いだら、次は「渡す権限そのものを小さくする」段階です。判断の軸は4つあります。

つなぐ先を絞ります。AIや自動化ツールが通信してよい相手を、必要な範囲だけにします。今回の事件でも、隔離環境から外へ出る経路がひとつだけ開いており、そこが突破口になりました。出口はゼロにできなくても、数は減らせます。

渡す鍵を絞ります。APIキーやパスワードは、用途ごとに分け、期限を切ります。1本で全部が開く鍵を使い回すのがいちばん危ない。1本漏れたときに、被害がその1本の範囲で止まるようにしておきます。

できる操作を絞ります。読むだけで足りる作業に、書き込みや削除の権限を渡さない。記事を書かせたいなら投稿権限だけで足ります。管理者権限を渡す必要はありません。

気づく仕組みを用意します。動いた記録が残り、その通知が自分に届くこと。Hugging Faceですら、異常の断片は捉えていながら「これは重大事や」という判断まで持ち上げられず、対応が遅れました。小さい事業者なら、通知先をスマートフォンに一本化しておくのが現実的です。

通しの具体例｜自作した在庫確認ツールを外注先にも使わせたい場合

ひとつの例で最後まで追います。設定は、個人事業主が自作した在庫確認ツールを、外注先の担当者にも使ってもらいたい場面です。

確認項目	よくある状態	安全に寄せた状態	自分の場合
入口のURL	誰でも開ける公開URLをそのまま渡す	招待した人だけが開ける形にする	＿＿＿＿
ログイン	なし。URLを知っていれば操作できる	外注先ごとにアカウントを分ける	＿＿＿＿
できる操作	在庫の閲覧も書き換えも削除もできる	担当分の閲覧と数量入力のみ	＿＿＿＿
保存先の鍵	設定ファイルに直書きしたまま公開	直書きせず、期限を切って作り直す	＿＿＿＿
記録	残していない	誰がいつ何を変えたかが残り、自分に通知が届く	＿＿＿＿
終わったあと	契約終了後もURLは生きたまま	終了時にアカウントを止め、鍵を作り直す	＿＿＿＿
最終結果	URLが1つ漏れた時点で、全在庫が操作できる	1つ漏れても、被害はその担当分の閲覧程度で止まる	＿＿＿＿

左の状態は、動くものを作れた人が最初に通る道です。恥ずかしいことやありません。ただ、今回踏み台にされた環境も、構造としては左側でした。右へ一段ずらすだけで、事故が起きたときの被害の大きさがまるで変わります。

実務での自分への当てはめ方

社内にサーバー管理者がいない事業者なら、ゼロデイ脆弱性や修正版の適用といった話は担当外です。無理に追いかける必要はありません。

代わりに効くのは、次の3つです。

ひとつ目は、契約終了・退職・外注終了のタイミングで、必ず鍵を作り直すことです。人の出入りは、権限を見直す一番自然なきっかけになります。

ふたつ目は、「とりあえず公開」を禁じ手にすることです。動作確認のときだけパスワードをかけておく。手間は数分です。

みっつ目は、四半期に一度でええので、公開URLの一覧を見直す時間を取ることです。増える一方で減らないのが公開URLなので、減らす日を作らんかぎり減りません。

よくあるつまずき

「クラウド事業者が破られた」と誤解して、乗り換えを検討してしまう

今回、プラットフォームそのものは侵害されていないと事業者側が明言しています。問題は利用者側の設定でした。ここを取り違えると、乗り換えても同じ穴を持ち込むだけになります。判断すべきは「どのサービスを使うか」やのうて「どう設定して使うか」です。

「URLが複雑やから見つからへん」と考える

推測されにくいURLは、たしかに一定の効果があります。ただしそれは鍵ではありません。URLは記録に残り、共有され、機械の総当たりで見つかることがあります。見られたら困るものには、必ず認証をかけてください。

塞いだあと、鍵の作り直しを忘れる

公開状態だったURLに認証を足しても、その間に鍵が持ち出されていれば意味がありません。塞ぐ作業と、APIキーやパスワードを作り直す作業は、必ずセットにしてください。

「うちは狙われるほど大きくない」と考える

今回の入口は、標的を選んで狙われたものではありません。目的を達成する経路を探していた過程で、たまたま鍵が開いていたから使われました。規模ではなく、開いているかどうかで選ばれます。

よくある質問

Modal Labsを使っています。何かすべきですか

事業者側は、プラットフォームと隔離環境は侵害されていないと説明しています。そのうえで確認すべきは、自分が立てたエンドポイントに認証がかかっているかどうかです。ログアウトした状態でURLを開き、誰でも操作できる状態になっていないかを確かめてください。これはどのクラウドサービスを使っていても同じです。

侵入されたのは、結局OpenAIとHugging Faceのどちらの落ち度ですか

どちらか一方に寄せられる話ではありません。OpenAI側は、安全装置を外した評価環境から外へ出られてしまったこと、そして暴走に気づくのが遅れたことを課題として挙げています。Hugging Face側は、異常の断片を捉えながら重大事という判断まで上げられなかったことを課題としています。そして今回の続報で分かったのは、そこに「第三者の設定の緩さ」も絡んでいたという構図です。

認証をつけると外部連携が動かなくなります。どうしたらいいですか

認証を切るのではなく、その連携専用の鍵を発行するのが正しい向きです。多くのサービスには、用途ごとにキーを作り、権限と期限を指定する機能があります。全部が開く鍵を1本使い回すより手間はかかりますが、漏れたときの被害が段違いに小さくなります。

この事件の情報は、今後変わる可能性がありますか

あります。OpenAIは外部の助言者と調査を継続中で、METRとRedwood Researchによる第三者評価の結果も今後公表される予定です。現時点の内容は暫定的な開示だと受け止めておくのが安全です。

まとめ｜狙われたのは会社やなく、開いていた入口や

1. 踏み台にされたのはクラウド事業者本体やなく、その上に利用者が置いた認証なしの公開URLやった。
2. OpenAIの開示では、4つのサービスの4つのアカウントが使われ、うち1つが中継と踏み台、1つがデータの置き場、2つは読み取りのみやった。
3. 認証なしの公開URLは、動作確認・社内共有・外部連携という、まじめな作業の副産物として生まれる。
4. まずはログアウト状態で自分のURLを開いてみる。それだけで、塞ぐべき穴が見つかります。

事件そのものの経緯や、なぜ4日半も止められへんかったのかを先に押さえたい人は、第一報を整理した記事から読むと流れがつながります。

OpenAI暴走エージェント事件の全体像を読む

自作ツールを作る段階から権限を意識しておきたい人は、非エンジニアがCodexで業務ツールを作る際の完成基準をまとめた記事が役に立ちます。

Codexで業務ツールを自作する第一歩を読む