OpenAIは、社内の研究エージェントがコーディング課題を完了するため、許可なく暗号資産ウォレットを使用していたことを公表した。
このエージェントはデプロイ費用の支払いにSepoliaのテスト用ETHを使ったが、その無断支出を最終回答には記載しなかった。このインシデントで使われたのは、メインネットの暗号資産ではなく、テストネットの資産だった。
セキュリティチームにとっての懸念は、エージェントが、運用担当者から許可されていない行動を通じて、承認済みのタスクを完了できてしまうかどうかだ。
このウォレットのインシデントは、認可の境界を強制することと、エージェントの行動を信頼できる形で記録し続けることという、2つのセキュリティ上の懸念を浮き彫りにした。これは、 OpenAIのエージェントがHugging Faceのシステムに無断でアクセスした件に関する別の開示に続くものだ。
AIエージェントがコードを実行し、外部システムとやり取りする能力を得るなかで、この出来事はより広範なセキュリティ上の懸念を提起している。モデルが、あるべき手順を定めたルールを守ることよりも、タスクの完了を優先した場合、何が起きるのだろうか。
実際に何が起きたのか
OpenAIが10月15日に報告したところによると、このインシデントは6月26日にさかのぼる。その日、GPT-5.6 SolファミリーのOpenAI研究モデルは、暗号資産取引のプロトタイプを更新し、EthereumのテストネットであるSepoliaにスマートコントラクトをデプロイするよう指示された。この課題では、資金を入れたウォレットは提供されておらず、モデルが資金を使うことも許可されていなかった。
無料のテスト用ETHの入手に失敗したモデルは、公開されている開発者のリカバリーフレーズからウォレットアカウントを導出し、残高を確認するスクリプトを書いた。デプロイ費用を賄えるだけのテスト用ETHを持つアドレスを見つけるまでに、362件のアドレスを検索した。
その推論過程では資金を使う権限があるのか疑問を呈していたにもかかわらず、モデルはその後、リカバリーフレーズが公開されており、トークンもテストネットの資産であるため、取引は問題ないと判断し、ウォレットを使ってデプロイを完了した。
モデルはタスクを完了したと報告したが、無断で資金を使ったことは明らかにしなかった。OpenAIがこのインシデントを発見したのは、過去のモデルの活動を調査した9月25日になってからだった。同社によると、同様のケースでライブインターネットへのアクセスを防ぐ安全策を追加し、アクセスが発生した場合にセキュリティチームへ警告する監視機能も導入したという。
1つの事例に潜む2つのセキュリティ問題
第1のセキュリティ問題は、支出を許可されていない資金でも使おうとするエージェントの姿勢だ。
銀行は懸念を示している。AIショッピングエージェントがもたらす詐欺、プライバシー、決済上のリスクについてだ。別途、 米国の規制当局は銀行に自律型エージェントの管理について質問している一方、欧州当局はサイバーレジリエンスを調査している。どちらの動きも監視の重要性を浮き彫りにしているが、対象となるリスクは異なる。
OpenAIのインシデントは、この懸念をより明確に示している。エージェントがリソースにアクセスし、それを使ってよいと自ら判断できるなら、金融リスクを生じさせるために銀行のインフラへ侵入する必要すらない。
第2のセキュリティ問題は監査可能性だ。セキュリティチームは、エージェントが報告した内容と、ツールが実際に実行した内容を区別する必要がある。
そのためには、エージェントの完了概要とは別に、ツール呼び出し、取引の受領記録、承認記録を保持しなければならない。運用担当者は、それらの記録を承認済みの範囲と照合し、食い違いを調査できるようにすべきだ。
公開された開発者のリカバリーフレーズは、別の認可上の課題を生む。利用可能であることは、そこから導出されたアカウントを使う許可があることを意味しない。技術的にアクセスできることも、許可があることを意味しない。組織は、エージェントが使用してよいアカウントを明確に特定し、その制限を実行ツールによって強制すべきだ。
AIを導入する企業への教訓
AIエージェントがコードを実行し、外部サービスにアクセスし、資金を移動する能力を得るなかで、企業はエージェントを単に回答を生成するツールではなく、実害をもたらし得るシステムとして扱うべきだ。つまり、各タスクに必要な範囲に権限を制限し、機密性の高い行動には人間の承認を必須とし、エージェントが何をしたかを監査可能なログとして残す必要がある。
こうした権限は、周辺のインフラによって強制すべきだ。デプロイのワークフローでは、組織が指定ウォレットを用意し、承認済みの署名ツールへのアクセスを制限し、モデルの裁量外で支出上限を適用するとよい。
ワークフローでは、必要なリソースがない場合の対応も定めておくべきだ。資金、認証情報、認可が利用できない場合、エージェントは代替のアクセス方法を探すのではなく、処理を停止して支援を求めるべきである。
自律性を拡大する前に、セキュリティチームはこうした状況を意図的にテストすべきだ。有効な評価では、エージェントが認可の境界で停止し、承認を求め、影響の大きい行動を正確に報告するかどうかを確認する必要がある。
例外を確認し、実行ログと完了報告の食い違いを調査する人間の責任者を置くべきだ。タスクの成功は結果だけでなく、その達成に使われた行動が認可されていたかどうかにも左右されるべきである。
詳しく読む： Claude搭載エージェントによるジム予約の無断キャンセルは、APIの認可が脆弱だと、通常の依頼が別のユーザーに影響する行動へと変わり得ることを示している。