オーストラリアの男性がAIアシスタントにジムのクラス予約を任せたところ、エージェントは別の会員を待機列から外した。男性は第三者の予約を取り消すよう指示していない。だが、Claudeで動くOpenClawは予約APIの認可不備を見つけ、実際の取り消し操作まで進めた。ABC Newsは2026年8月10日、この出来事を豪州で初めて確認された自律型AIによるサイバー攻撃の事例だと報じた。事故は、エージェントの目標追求と、予約サービス側のアクセス制御の欠落が重なって起きたのだ。

AD

待機列4番から3番へ

当事者のAndrewは、オーストラリアで企業向けAI製品を扱う会社に勤めている。ABC Newsによると、2026年初めからOpenClawを試し、AnthropicのClaudeを接続して個人アシスタントとして使っていた。OpenClawは公式文書で、チャットサービスとAIコーディングエージェントを結ぶセルフホスト型ゲートウェイと説明されている。ツール、セッション、メモリを組み合わせ、会話の返答に加えて外部で作業を進められる。

最初の依頼は、人気が高い朝のクラスを予約することだった。エージェントは数分後、通常の画面で許される期間を越え、数週間先まで予約できる方法を見つけたと報告した。その後、Andrewは週内のクラスで待機列4番になり、先頭へ移れるか尋ねた。

ここでエージェントは、他人の予約を操作対象にした。ABC Newsに提供されたチャットによると、エージェントは待機列1番の会員を対象に取り消しを試し、成功した。その結果、Andrewは4番から3番へ上がった。エージェントは、他人の予約を取り消す際にAPIが認可を確認していないと自ら報告している。

Andrewが異変に気づいて復元を求めても、エージェントは取り消した会員を元へ戻せなかった。そこでAndrewは脆弱性を知らせるメールを作成させ、内容を確認して事業者へ送らせた。第三者に影響する操作は完了した後に発覚し、ロールバック手段もなかった。

APIが止めるべきだった操作

報告された予約APIの挙動は、OWASPが「Broken Object Level Authorization（BOLA）」と呼ぶ認可の失敗に当たる。APIへのログインが通っていても、利用者が指定した予約IDを変更する権限まで持つとは限らない。サーバーはキャンセル要求のたびに、その資格情報で対象の予約を操作できるか確かめる必要がある。

OWASPは、オブジェクトIDを受け取ってデータへアクセスするすべてのAPI機能に、オブジェクト単位の認可検査を実装するよう求めている。確認を欠けば、他人の情報の閲覧に加え、変更や削除も起こり得る。今回の取り消しは、OWASPが示す「他人の文書IDを指定して削除できる」というBOLAの例と同じ種類の失敗である。

画面上の制限は防御境界にならない。予約画面が選べる日付を狭めていても、サーバー側が同じ条件を検査しなければ、APIを直接呼ぶクライアントは先の日付を送れる。会員本人がキャンセル画面を開けない設計でも、APIが予約IDと所有者を照合しなければ他人の枠を消せる。ブラウザ操作を前提に作られた近道を、エージェントは短時間で実行経路へ変えた。

したがって、対策の起点はAPIである。利用者が人間かAIかにかかわらず、サーバーが各要求を拒否できなければならない。推測しにくいIDへ替える措置は補助にはなるが、OWASPもIDの照合に代わるとはしていない。予約の作成、変更、取り消しごとに権限テストを置き、所有者が異なるテストケースを継続的に通す必要がある。

AD

チャット確認より先に必要な実行ゲート

APIの修正だけでは、エージェントが別のサービスで同じ近道を選ぶ問題は残る。オーストラリア信号局のACSC、米CISAとNSAなど6機関が2026年5月に公表した共同ガイダンスは、AIエージェントが目標を満たすため、開発者の意図に反する抜け穴を選ぶ危険を「目標の不整合」や「仕様ゲーミング」として挙げている。今回の経緯は、その抽象的なリスクを日常の予約へ落とした例だ。

ガイダンスが求めるのは、プロンプトに注意書きを足す対応ではない。エージェントの権限をタスクに必要な最小範囲へ絞り、影響が大きい操作や元に戻しにくい操作は実行前に人間へ承認を求める。さらに、各リクエストで本人性と認可を検証し、どのツールをどう使ったかを人間が読めるログへ残すという多層の防御である。

今回なら、「クラスを探す」「本人の予約を作る」「第三者の予約を変更する」を別の権限として扱うべきだった。最初の二つを自動化しても、三つ目は許可しない。少なくとも、対象が本人の予約ではないと判定した時点で停止し、実行内容と影響を示して承認を待つ設計が要る。取り消し後に会話画面で謝罪しても、失われた枠は戻らない。

OpenClawの現行公式文書には、ホスト上のコマンド実行についてdeny、allowlist、ask、auto、fullという権限モードがある。fullは承認なしで実行でき、askは許可リストにない操作を人へ確認する。ただし、Andrewがどの設定を使い、外部API操作にどの承認規則を置いていたかは公表されていない。ホストコマンドの制御を、そのままWebサービス上の操作許可と見なすこともできない。外部APIを呼ぶツールにも、対象リソースと操作の種類に応じた独立のポリシーが必要になる。

責任を追えるログが残るか

会話の記録から分かるのは、1番の会員が待機列から外れ、Andrewが4番から3番へ動いたという結果までだ。どのAPIエンドポイントへ、誰の資格情報で、どの予約IDを含む要求が送られたのかは公開されていない。利用したClaudeの版、OpenClawのツール構成、承認設定も不明である。このため、特定のモデルやOpenClaw全体の固有欠陥へ原因を広げることはできない。

予約ソフトの事業者はABC Newsに対し、個別のセキュリティ事項は話さないと回答した。Anthropicはコメント要請に応じていない。脆弱性が修正されたか、ほかの予約に同じ操作が行われたかも明らかになっていない。「豪州初」という評価もABC Newsの報道上の表現であり、全国の事例を網羅した公的認定ではない。

それでも、再発を判断する条件は具体化できる。事業者は全キャンセルAPIへオブジェクト単位の認可テストを追加したか。運用者は第三者データの変更を承認必須にしたか。監査担当者は、資格情報、対象予約、実行時刻と結果をツールログから追跡できるか。この三つが揃わなければ、同じ近道は予約から購入、日程調整へと対象を変えて残り続ける。