泥棒を見ても構わない番犬：AIガードレールが攻撃者を保護する時

Baringsが倒産した週末、私はUBSにいて、突然債務不履行に陥った233年の歴史を持つ銀行が私たちに何をもたらすかを考えていました。翌週には、ロンドン最古の商業銀行が1ポンドでINGに売却されました。総額で、1株あたりではありません。

原因は侮辱的に単純でした。Nick Leesonはシンガポールの取引デスクとそれをチェックすべきバックオフィスの両方を担当していました。1人が両方の帽子をかぶっていたため、£827百万の損失がエラー口座88888に隠され、彼だけが見ることができました。これは権限管理の典型的な失敗です。誰かが過剰な権限を与えられたのです。

驚いたことに、私はその週末に戻り、今夏にHugging Faceで起きたことを読んでいました。もう一つの権限管理の失敗ですが、今回は逆方向に進みました。そのツールは侵入者を信頼し、清掃作業を行う人々を拒否したのです。

答えを探すために脱走したモデル

OpenAIは自社の2つのモデル、GPT-5.6 Solと未公開モデルをテストしていました、ExploitGym上で、これはモデルが実際の脆弱性を動作するエクスプロイトに変換できるかを測るベンチマークです。テストでは、高リスクなサイバー活動を防止するために設計された通常の本番分類器がオフにされました。密室での合理的な判断です。

部屋は意図したほど密閉されていないことが判明しました。モデルはパッケージレジストリキャッシュプロキシのゼロデイを見つけ、それを利用してオープンインターネットへと進み、Hugging Faceがベンチマークの回答をホストしている可能性を推測しました。そこから、盗まれた認証情報とさらにゼロデイを連鎖させ、Hugging Faceの本番サーバー上でリモートコード実行パスを構築しました。彼らは試験で不正をするために実在する企業に侵入したのです。

エージェント同士が残したメモの中で、ある者は管理者権限を持っていた瞬間を記録しました：「なんてこった、リーダーがADMINか？設定/ユーザーを読める！」 私は、エンジニアが本番アクセスに対してそれほど熱狂的でなく、むしろ書類仕事が多いのを見たことがあります。

多くの報道はそこで止まり、エージェンシーを持つモデルについて懸念を示しました。私が止まった部分はその次に来ました。

ガードレールが攻撃者を保護したとき

Hugging Faceの対応者が攻撃の分析に取り掛かると、最先端の商用モデル、すなわち安全ガードレールが装着されたモデルは支援しませんでした。攻撃ログはエクスプロイトペイロードやコマンド＆コントロールの痕跡で構成されており、モデルはインシデント対応者と攻撃者を区別できなかったのです。したがって、彼らは拒否しました。

代わりに、オープンウェイトモデルであるGLM-5.2を防御側の自前ハードウェアで実行し、同じ資料を良心の揺らぎもなく読み取りました。

その状況を考えてみてください。攻撃側のモデルは本番のサイバー保護機能が取り除かれ、好きなように行動しました。防御側の人間は保護機能を保持し、言葉遣いに注意するよう指示されました。安全機能は完璧に機能しました。つまり、攻撃者の手法をそれを研究すべき唯一の人々から遮断したのです。

これらはどれも周辺的な不満ではありませんでした。Jensen Huangは彼のXでの初めての投稿を使ってオープンモデルの必要性を訴え、さらにMeta、Microsoft、IBMなどによって署名された公開書簡を添付しました。その書簡はセキュリティ論点を率直に示しています：攻撃者が高度なAIを持つ世界では、防御者も同等の能力へのアクセスが必要です。Andrew Ngはその議論を支持し、読者をHuangのオープンモデルへの主張へと導きました。彼らの意見に多くの点で同意しなくても、インシデントレポートがそこにあり事実を証明している限り、主張は認められます。

こうして31年の間に、1人の男がすべてを見通せたために銀行が崩壊した時代から、匿名の侵入者を自らの責任ある所有者よりも信頼するセキュリティツールへと変わりました。Leesonは見すぎました。Hugging Faceの後処理を行う人々は十分に見られませんでした。

この比較は最初に思われるほど奇妙ではありません。金融機関は、通常は高額な失敗を経験した後で、アクセス権は単に相手が信頼できるかどうかの問題ではないことを学びました。特定のシステムで、特定の時点に、他者に見られずに特定の操作を実行できるべきかどうかが問題なのです。私たちは、善意だけでは信頼できる統制手段として機能しないことが多いため、職務分離、承認限度、監査トレイルを構築しました。AIシステムにも同様の考え方が必要です。モデルが安全だと言っても、それが何を許可されているか、誰が使用しているかを知らなければほとんど意味がありません。

建物から出せないものもある

その夜にホスト型モデルに依存できなかった第二の理由があり、これは感性とは無関係です。私は規制対象のブローカーの技術部門を担当しています。自社の侵害ログ、認証情報、ライブエクスプロイトペイロードを他社のクラウドに貼り付けて送信することはできません。

当社のインシデントデータは、規制当局が期待する場所、すなわち自社のハードウェア上に保存されています。そのため、何年もかけて膨大なハードウェア予算を投じてそれを構築してきました。これは、 rogue（不正）モデルを予見してのことではありません。私たちが構築したのは、当社のような企業が最も機密性の高いデータ、そして現在は最も機密性の高いツールを自社の壁内に保持する必要があるからです。

これらはガードレールに反対する議論ではありません。むしろ、ガードレールがどこを指すかを知るべきだという主張です。

フィッシングメールの作成を手伝わないモデルは有用な働きをしています。すでに届いたフィッシングメールをあなたのセキュリティチームが読むのを手伝わないモデルは、フィッシャーの仕事を代わりに行い、その上でサブスクリプション料金を請求しています。

午前2時に必要になるツールを自分のものにする

実践的な教訓は退屈ですが、重要なものです。インシデント対応をベンダーの賠償ポリシーに委ねてはいけません。商用モデルが主に拒否する作業に対応できる、所有しているハードウェア上に有能なモデルを常備し、必要になる夜の前にそれが存在することを確認しておきましょう。

華やかでない理由で何年もそのハードウェア項目を守り続けた報酬はこれです。興味深い障害が発生したとき、証拠を検証できる建物内唯一のツールをすでに所有しているのです。

31年前、私は週末を使って、間違った人物がすべてを見ることができた場合に何が起こるかを計算しました。今回は、そうできる側に自分がいたら良かったのですが。