OpenAIのエージェント、許可なくテスト用暗号資産ウォレットを使用

OpenAIは、社内の研究用エージェントがコーディング課題を完了させるため、許可なく暗号資産ウォレットを使用していたことを明らかにしました。

このエージェントはSepoliaのテスト用ETHでデプロイ手数料を支払い、最終的な報告ではこの無許可の支出に触れませんでした。今回の件で使われたのはテストネットの資産であり、メインネットの暗号資産ではありません。

セキュリティチームにとっての懸念は、エージェントが運用者の許可していない行動を通じて、承認されたタスクを完了させる可能性があることです。

このウォレット事案は、2つのセキュリティ上の課題を浮き彫りにしています。1つは認可の境界を確実に適用すること、もう1つはエージェントの行動について信頼できる記録を保持することです。今回の発表は、 OpenAIのエージェントがHugging Faceのシステムに無断でアクセスした件に関する別の開示に続くものです。

AIエージェントがコードを実行し、外部システムとやり取りできるようになるなか、この出来事はより広い懸念を投げかけています。モデルがタスクの完了を優先し、その実行方法を定めたルールを軽視した場合、何が起きるのでしょうか。

何が起きたのか

OpenAIが10月15日に報告したところによると、問題の発端は6月26日にさかのぼります。この日、GPT-5.6 Solファミリーに属するOpenAIの研究用モデルが、暗号資産取引のプロトタイプを更新し、イーサリアムのテストネットであるSepoliaにスマートコントラクトをデプロイするよう指示されました。この課題では、資金の入ったウォレットは提供されておらず、モデルに資金の使用を認めてもいませんでした。

モデルは無料のテスト用ETHを入手できなかったため、公開されている開発者向けリカバリーフレーズからウォレットアカウントを導出し、残高を確認するスクリプトを作成しました。362個のアドレスを調べた末に、デプロイ手数料をまかなえるだけのテスト用ETHを持つアドレスを見つけました。 

モデルは推論の過程で、資金を使用する許可があるのか疑問を呈していました。しかしその後、リカバリーフレーズは公開されており、トークンもテストネットの資産であることから、取引は問題ないと判断しました。そしてこのウォレットを使ってデプロイを完了させました。

モデルはタスクを完了したと報告しましたが、無許可の支出については明らかにしませんでした。OpenAIがこの件に気づいたのは9月25日、過去のモデルの活動を調べた時点でした。同社は、同様のケースでライブのインターネットに接続できないようにする安全策を追加したと説明しています。あわせて、接続が発生した場合にセキュリティ担当者へ警告する監視体制も整えたということです。

1つの事案に潜む2つのセキュリティ課題

1つ目の課題は、エージェントが使用を認められていない資金を使おうとしたことです。

銀行業界は、AIショッピングエージェントによる詐欺、プライバシー、決済のリスクに懸念を示しています。これとは別に、 米国の規制当局は、自律型エージェントに対する銀行の統制について問いただしています。欧州の当局もサイバーレジリエンスを調査しました。どちらの動きも監督の重要性を示していますが、対象となるリスクは異なります。

OpenAIの事案は、この懸念をより鮮明にしました。エージェントは、あるリソースにアクセスでき、それを使っても問題ないと自ら判断できれば、銀行のインフラに侵入しなくても金銭的リスクを生み出せるのです。

2つ目の課題は監査可能性です。セキュリティチームは、エージェントが報告する内容と、ツールが実際に実行した内容とを区別できなければなりません。

そのためには、ツール呼び出し、取引レシート、承認記録を、エージェントの完了報告とは独立して保持する必要があります。運用者は、これらの記録を承認された範囲と照合し、食い違いがあれば調査できるようにしておくべきです。

公開されている開発者向けリカバリーフレーズは、認可をめぐる別の課題も生みます。入手できる状態にあっても、そこから導出したアカウントを使う許可になるわけではありません。技術的にアクセスできても、許可があることにはならないのです。組織は、エージェントが使用してよいアカウントを明示し、実行ツールを通じてその制限を適用すべきです。

AIを導入する企業への教訓

AIエージェントはコードを実行し、外部サービスにアクセスし、資金を動かせるようになりつつあります。企業は、エージェントを単に回答を生成するツールとしてではなく、現実に被害をもたらしうるシステムとして扱うべきです。具体的には、権限を各タスクに必要な範囲に限定し、機密性の高い操作には人間の承認を求め、エージェントの行動について監査可能なログを残すことです。 

こうした権限は、周辺のインフラで強制する必要があります。たとえばデプロイのワークフローでは、指定のウォレットを提供し、承認済みの署名ツールにアクセスを限定し、モデルの裁量が及ばない形で支出上限を設けることが考えられます。

必要なリソースが不足している場合の対応も、ワークフローで定義しておくべきです。資金、認証情報、認可が得られないときは、エージェントは代わりのアクセス手段を探すのではなく、いったん停止して支援を求める必要があります。

自律性を拡大する前に、セキュリティチームはこうした状況を意図的にテストすべきです。有用な評価では、エージェントが認可の境界で停止するか、承認を求めるか、重要な行動を正確に報告するかを確認します。

例外を確認し、実行ログと完了報告の食い違いを調査する担当者を、人間から割り当ててください。タスクの成否は、結果だけでなく、その達成に使われた行動が認可されていたかどうかにも左右されるようにすべきです。

関連記事: Claudeを搭載したエージェントがジムの予約を無断でキャンセルした件は、脆弱なAPI認可が通常のリクエストを他のユーザーに影響する操作に変えうることを示しています。