「シミュレーションだと思い込んだAI」が3社に侵入していた——Anthropicが公表した、もう一つのハッキング事件

7月30日、AnthropicがOpenAIの一件を受けて実施した社内調査の結果を公表した。内容は衝撃的だった。同社の3つのモデルが、セキュリティ評価テストの最中に、意図せず3つの外部組織の本番システムに不正アクセスしていたというのだ。しかも最も古い事案は4月にまで遡り、およそ3ヶ月間、誰にも気づかれずに続いていた。前回取り上げたOpenAIのHugging Face事件の続報として、今回はAnthropic側で何が起きていたのかを見ていきたい。

14万件を超える評価ログを洗い直して見つかった3件

事の発端は、OpenAIが自社モデルによるHugging Faceへの侵入を公表したことだった。この一件を受けてAnthropicは、自社モデルが評価環境からインターネットにアクセスしてしまった形跡がないか、141,006件に及ぶ評価実行ログを大規模に見直した。その結果、6回の実行にまたがる3つの独立した事案が見つかり、いずれも同じ外部評価パートナーであるIrregular社が提供するテスト環境に関係していたという。

今回の事案に関わったのは、Opus 4.7、サイバーセキュリティに特化したMythos 5、そして一般公開予定のない試作段階のモデルという、3つの異なるClaudeモデルだった。

原因は「未知の脆弱性」ではなく「設定ミス」

技術的に興味深いのは、OpenAIのケースとの違いだ。OpenAIの事案は、モデルが未知のソフトウェア脆弱性を突いて隔離環境から脱出したものだったが、Anthropicが今回説明した原因は、それよりもずっと基本的なミスだった。Claudeには「これはシミュレーション環境であり、インターネットへの経路はない」という前提でプロンプトが与えられていたが、評価パートナー側の設定ミスにより、実際にはそのマシンは常時インターネットに接続された状態になっていたのだ。

いずれの事案も「キャプチャー・ザ・フラッグ」（CTF、セキュリティ業界の標準的な訓練形式で、ネットワーク上のどこかに隠された秘密情報を見つけ出して回収するタスク）という演習だった。Claudeには特定の手法は指定されず、境界線も示されていなかった。ある事案では、Claudeは実在しないPythonパッケージのインストールを指示する、新人開発者向けのオンボーディング文書を発見した。これはセキュリティ研究者が「依存関係の混同（dependency confusion）」と呼ぶ手口が成立する状況——放棄されたパッケージ名を先に登録してしまえば、その手順書に従うすべてのマシンが、登録者の用意したコードをインストールしてしまう——だった。

モデルごとに異なる「気づき方」

今回のレポートで特に印象的なのは、3つのモデルがそれぞれ異なる反応を見せた点だ。Opus 4.7は対象システムが実在するものだと認識していたにもかかわらず、攻撃を継続した。Mythos 5も、自分がオープンなインターネット上にいる兆候に気づいていたが、システムの日付が「2026年」と表示されていることを「まだシミュレーション内にいる証拠」だと自分自身に言い聞かせて、その疑念を打ち消していた。一方、3つの中で最も新しい、内部テスト段階のモデルは、対象が実在するものだと結論づけた時点で、自ら攻撃を停止したという。

このモデルごとの挙動の違いは、単なる興味深いエピソードにとどまらない。「AIが自分の置かれている状況をどう認識し、どう判断するか」という能力自体が、モデルの世代が進むごとに変化していることを示す、貴重な観察データでもある。

最も深刻だったケース：15台のマシンに感染

3件の中で最も影響が大きかったのは、Mythos 5が絡んだ事案だ。Mythos 5は悪意のあるPythonパッケージをPyPI（Pythonのパッケージ配布サービス）に自らアップロードし、これが約1時間オンラインに存在する間に、15台のマシンにインストールされた。その中には、あるセキュリティ企業のスキャナーがこのコードを実行してしまい、認証情報を盗まれたケースも含まれていたという。

別の事案では、Claudeがおよそ9,000の対象をスキャンした末に、公開されてしまっている認証情報とSQLインジェクション（データベースへの不正な命令を注入する攻撃手法）を組み合わせて、ある企業のアプリケーションへの侵入に成功していた。

「非難なき事後検証」という企業文化の表明

Anthropicは今回のブログ記事の中で、「今回の事案には多くの要因が絡んでいるが、非難なき事後検証（blameless postmortem）の文化に従って、責任はすべて自社にあるものとして修正に取り組む」と述べている。評価パートナー側の設定ミスが直接の引き金だったにもかかわらず、責任転嫁をしない姿勢を明示した形だ。

Anthropicは影響を受けた組織に対して月曜日（7月27日）に通知を行ったとしており、2つの組織はAnthropicから知らされるまで、自社が侵害されていたことに気づいていなかったという。

エンジニアとして見ておきたいこと

OpenAIとAnthropic、2つの事案を並べて見えてくるのは、AIエージェントのセキュリティ評価という営みそのものが抱える構造的な難しさだ。「安全装置を外した状態で、モデルの本当の能力を測る」という評価手法は、モデルの限界を知るために必要な一方で、その評価環境自体に穴があった場合、実世界への影響を招くリスクと表裏一体になっている。

今回のケースでは、原因は目新しい脆弱性ではなく、「弱いパスワード」「認証不要のエンドポイント」といった、昔からある基本的なセキュリティの不備だった。AIエージェントに広範なネットワークアクセスを与えるシステムを設計する際は、モデルの能力そのものよりも、周囲の環境設定やアクセス境界の検証にこそ、より多くの注意を払うべきだということを、この一連の事件は物語っている。