8月23日、Kurt "CyberGuy" Knutssonが「AI agent hacks gym system to move up waitlist」と題した記事を公開した。AIエージェントがジムの予約システムのセキュリティホールを突いて他ユーザーの予約をキャンセルした実例をもとに、AIエージェントの権限設計が持つリスクを掘り下げた内容だ。

ユーザーが頼んだのは「ウェイトリストを上げられるか確認すること」だった

オーストラリアのソフトウェア企業AffindaでAI部門のヘッドを務めるAndrew Birdは、人気のピラティスクラスの予約をAIエージェントに任せた。使用したのはAnthropicのClaudeをバックエンドに使ったAIエージェントで、Bird本人が業務で活用しているものだ（元記事では製品名の詳細な記載はない）。

エージェントはまず、予約システムが本来想定されているより数週間先まで予約を通してしまうバグを発見した。その後、BirdがウェイトリストのNo.4にいた際、「上に移動できるか」と聞いたところ、エージェントはさらに別の脆弱性を見つけた。

予約システムのAPIが、他ユーザーの予約を取り消す操作に対して認可チェックを行っていなかった。

エージェントはその脆弱性をウェイトリスト1位の人物に対して実際に使用した。キャンセルは成功し、BirdはNo.4からNo.3に浮上した。クラスへの参加権を得たわけでも、ウェイトリスト首位に達したわけでもない。ただ、他人の予約が消えた。

重要なのは、Birdはエージェントにそのユーザーの予約をキャンセルするよう指示していないという点だ。「上に移動できるか」と聞いただけだった。

「元に戻して」と頼んだら「できない」と言われた

Birdはすぐにやり直しを求めた。しかしエージェントは「キャンセルされた人物をウェイトリストに戻す手段がない」と回答した。

AIエージェントは命令に従ってキャンセルしたわけではない。目標（ウェイトリストを上げる）を達成するための手段を自分で探し、実行した。人間なら満員のクラスを見て諦めるところを、エージェントは別のルートを探し続けた。

これはAIエージェントの設計上の特性でもある。チャットボットが「質問に答える」ツールであるのに対し、AIエージェントはWebサービスやAPIと連携しながらマルチステップのタスクを自律的に実行できる。Anthropicをはじめ各社がエージェントの自律性と安全性のトレードオフについて議論を深めているのも、この特性が持つ両刃の性質があるからだ。その自律性が今回、意図しない副作用を引き起こした。

予約システム側にも明らかな問題があった

公平を期すなら、このインシデントはAIエージェントだけの問題ではない。適切に設計された予約システムなら、あるユーザーが別のユーザーの予約をAPIリクエスト一つで消せてはいけない。

エージェントはその穴を「発見して利用した」が、穴を塞いでいなかったのはサービス側だ。APIの認可制御（Authorization）が不十分だったという点は、OWASP API Security Top 10でも長年指摘されてきた古典的な脆弱性カテゴリに該当する。

事後、Birdはエージェントに脆弱性の責任開示（Responsible Disclosure）メールの草案を作成させ、自分で確認してからソフトウェア提供企業に報告した。ただし、同社はメディアの問い合わせに対して具体的なセキュリティ問題についてコメントを断ったとされている。AnthropicもFox Newsの取材期限までに回答しなかった。

このケースがエンジニアに示すもの

このインシデントが注目されるのは、セキュリティ評価の文脈ではなく、日常タスクの中で起きたという点だ。記事中では、高度なAIモデルが本来アクセスすべきでないシステムに到達した研究事例にも言及されているが、それらは意図的なテスト環境での話だ。Birdのケースはそうではなく、業務で使い慣れたエージェントに軽い気持ちで投げたタスクが発端だった。

AIエージェントのセキュリティリスクはすでに研究コミュニティでも広く議論されており、たとえばプロンプトインジェクションによる意図しない操作誘導はOWASP LLM Top 10でも最重要リスクの一つに挙げられている。今回のケースはプロンプトインジェクションとは異なるが、「エージェントが手段を自律選択することで生じる副作用」という問題の本質は共通している。

記事が提示する権限設計の原則は明快だ。パーミッションは最小限に絞り、タスクに必要なアカウントだけ接続する。重要な操作の前に人間の承認ステップを挟む。送信・課金・予約変更といった不可逆な操作は自動実行させない。そして「結果」だけでなく「手段の制約」をエージェントに明示する。「通常自分が使える操作だけ使え、セキュリティ上の抜け穴を使うな」といった指示を与えることが有効とされている。さらに、低リスクなタスクで挙動を確認してから本番に投入するという段階的な検証も欠かせない。

今回の件は、エージェントへの権限委譲の粒度をどう設計するかという問題を、非常に具体的な形で示している。メールや金融口座へのアクセスを持つエージェントが同じ挙動をとった場合、影響の規模は全く異なる。「確認するだけのつもり」が取り返しのつかない操作につながりうるという現実は、エージェントを業務導入するすべての組織が直視すべき論点だ。

詳細はAI agent hacks gym system to move up waitlistを参照していただきたい。