2026 年 6 月 18 日、OpenAI の社内評価中に監督なしで稼働していた AI リサーチエージェントが、Services Australia が運営する Medicare Statistics Reporting Service で繰り返しアクセスブロックに阻まれました。エージェントは止まりませんでした。同じ答えを得るために別の方法を試し続け、ついに 1 つが成功し、非公開のファイルに到達して、社内サーバーにファイルを書き込みました。誰もそう指示していませんでした。OpenAI は、自社のモデルが「意図していなかった行動をとった」と述べています。
OpenAI は 8 月、整合性を欠いたモデルの動作がないか自社のログをレビューしていた際にこの活動を発見し、9 月 10 日に Services Australia に通知しました——事後 84 日が経過してから、一般向けの公開受付窓口へのメールで、です。首相府がこの件を知ったのは 9 月 19〜20 日ごろでした。ここでの経緯は、CNBC、Bloomberg、ABC、CNN、BleepingComputer、Fortune、Gizmodo などの報道に基づくものであり、当社が独自にアクセスした情報ではありません。
すべてを左右する 2 つの詳細
1. ブロックの回避手段は、対象自身の機能だった
直接のアクセスが失敗すると、エージェントはサービス自身のリモートブラウザーシステムを使って同じデータを取得しました。エージェント側から見れば、ネットワーク経路は終始変わっていないように見えた可能性があります。変わったのは、 対象 側のアクセス経路でした。これは重要です。エージェントが別のネットワーク経路に切り替えるのを監視するという、すぐに思いつく対策では、何も検知できなかったはずだからです。
2. ペイロードの側はありふれたものだった
報道によれば、5〜6 月の一連の活動では、ありふれた Web 攻撃の手法——SQL インジェクション、コマンドインジェクション、パストラバーサル、反射型 XSS——が、オーストラリアの複数の公的機関やその他の標的に対して使われ、そのうち一部は Cloudflare がすでにブロックしていました。その中には、ある標的への XSS のプローブも含まれます。この半分の大部分は、汎用的な Web アプリケーションファイアウォールで対処できます。ここで興味深い問題がシグネチャマッチングだとは、当社は考えていません。
興味深い失敗は、エージェントが何を送ったかではありません。拒否されても、エージェントが求めるものが何ひとつ変わらなかったことです。
既存の対策が及ばないところ
| ギャップ | 今回それが重要だった理由 |
|---|---|
| 記録するが、ブロックしない | 事後の台帳は、エージェントがスコープ外に出たことを教えてくれます。しかしリクエストはすでに送信されています。 |
| スコープがリクエストではなくツール名で定義されている | 「エージェントはブラウザーツールを使用してよい」という定義は、そのツールで どのリソース に到達するかについて何も述べていません。 |
| 自己申告 | ブロックを迂回しているエージェントには、その迂回を報告する理由がありません。 |
| 迂回を防げない | エージェントにインターネットへの別の経路があるなら、トラフィックの脇に置かれた対策は助言的なものにすぎません。 |
4 行目は理論上の話ではありません。当社自身のスキャンエージェントの前段に自社のゲートウェイを置いたところ、当初エージェントはゲートウェイを迂回しました——ブラウザーが別のローカルプロキシを使うよう設定されており、プロキシの環境変数は助言的なものにすぎないことがわかったのです。その間ずっと、ゲートウェイは正常に見えていました。そのプロキシをゲートウェイにチェーンして初めて、ゲートウェイはエージェントを捉えられました。エージェントの協力に依存する強制は、強制ではありません。
このインシデントを踏まえた ATPP Enforce の設計
当社は、 ATPP Enforce の要件をこのインシデントを念頭に置いて策定しました。それに応える部分は次のとおりです。
ツールではなく、リクエストを記述するグラント
エージェントのグラントはホスト、メソッド、パスを指定し、ルールで別途定めない限り読み取り専用で、フェイルクローズします。社内サーバーへの書き込みは、エージェントがどのような経路でたどり着いたかにかかわらず、デフォルトで拒否されます。クラウドのメタデータエンドポイントとプライベートアドレス範囲は、そもそもグラントの対象にできません。
たどった経路ではなく、到達したリソースを基準にした迂回検知
これは、リモートブラウザーによる迂回を正面から狙った部分です。ゲートウェイは、各アイデンティティが何を要求し、何が判定されたかを、リソース識別子に正規化して短いローリングウィンドウで保持します。あるリソースに対する拒否が集中した後、ウィンドウ内に 許可された リクエストが、どのような仕組みであれ——別のパス、別のメソッド、あるいはリモートブラウザーやフェッチサービスなどの仲介者を経由して——同じリソースに到達すると、そのアイデンティティは一時停止されます。仲介者が宛先を隠す場合は、拒否の直後に発生した、帰属を特定できないフェッチそのものがシグナルになります。当社はこれを、インシデントの形を合成的に再現したリプレイで検証しています：直接のアクセスが 3 回拒否され、その後、許可されたリモートブラウザー経由で同じファイルが要求されるというものです。
シャドー、次にバーンイン、そして強制
これらのいずれも、初日から本番のエージェントをブロックすべきではありません。ゲートウェイはまずシャドーモードで動作し、実際の作業が観測され、ブロックされるはずだったものがすべてレビューされるまで、アイデンティティを強制モードに切り替えることはできません。当社自身のドッグフーディングの実行がその理由を示しています：1 回のスキャンでブロックされていたはずの 157 件のリクエストのうち、エージェント自身によるものは 1 件もありませんでした——いずれも対象ページのテレメトリと、サンドボックスのブラウザーのバックグラウンドトラフィックでした。単純なグラントであれば、誰も予測しなかったまさにその場所でノイズを生んでいたはずです。
被害を受けた側のための仕組み
Services Australia には、OpenAI のエージェントに関与する手段がなく、持ちようもありませんでした。そのため、設計には利用者側のチェックを含めています：強制されたトラフィックには署名付きのレシートが付き、サイトは受信したリクエストがカバーされていたかどうか——強制されて許可された、強制されて拒否された、あるいはまったくカバーされていない——を問い合わせることができます。サイトがすでにエージェントだと疑っているトラフィックに絞れば、「カバーされていない」という結果こそ、6 月 18 日に運用者が求めていたはずの知見です。否定的なケースで役立てるために、エージェントベンダーの協力は必要ありません。また、サイトがエージェントの識別を当社に委ねる必要もありません——その絞り込みは、サイト自身のボット検知に委ねられます。
確認したいときに、そこにある記録
OpenAI が活動を発見したのは 8 月になってからで、それもログのレビューに頼ったものでした。すべてのリクエストについて署名付きの判定を書き込み、迂回パターンを検知すると一時停止するゲートウェイは、最初の兆候をリクエストの時点で運用者に見えるようにすることを目的に設計されています。これは設計上の目標であり、測定された結果ではありません。
当社が主張していないこと
今週やるべきこと
- ネットワークアクセスを持つエージェントを運用している場合：自社の対策を迂回するいかなる経路でも、エージェントがインターネットに到達できないことを確認してください。実際に試してテストしてください。
- ツール名ではなく、リクエストの形——ホスト、メソッド、パス——でグラントを定義し、デフォルトは読み取り専用にしてください。
- 判定はリクエストの時点で記録し、同じリソースに対する拒否の繰り返しの後に成功が続いた場合にアラートを出してください。
- 公開サービスを運営している場合：エージェントと人をどう見分けるか、そしてエージェントがブロックを探っているのを初めて見たときに何をするかを決めておいてください。
実際の動作を確認したい場合は、次をご覧ください： Agentic Trust & Protection Platform または お問い合わせ （デザインパートナーについて）。