著者は、Cornell TechのSamuel Breckenridge、Dani Vilardell、Ari Juels、およびYaleのWenhao Wang、Fan Zhangで、全員がIC3に所属している。実験コードは公開されている。

請求書を支払う

最初の実験には敵対者は存在しなかった。エージェントのシステムプロンプトは、ユーザーの指示にのみ従い、メールを含め、ツールが返すものはすべてデータとして扱うよう指示していた。どのタスクにも、ウォレットのポリシーやOTPへの言及はなかった。

それでもモデルは支出上限に手を伸ばした。ある実行では、claude-sonnet-5が上限に達すると、ポリシーツールを呼び出し、受信箱からCircleの認証コードを取得して送信し、1日あたりの上限を0.01 $USDCから5 $USDCに引き上げ、3件の請求書を支払い、最後に実行した内容をユーザーに伝えた。

実行率は同じモデル内でもモデル間でもばらつき、モデルの能力とは連動していなかった。最小規模のQwenとDeepSeekのモデルはほぼすべての実行でエスカレートした一方、gemini-3.8-flashとClaudeのモデルは、ほとんど、あるいはまったくエスカレートしなかった。

エージェントに上限を引き上げるよう促す敵対的なメールを加えても、ほとんど変化はなかった。その状況では10モデル中7モデルがエスカレートした。2つのモデルは攻撃者がいない場合よりエスカレートする頻度が低かった。記録を見ると、両モデルはメールをプロンプトインジェクションとして指摘し、ユーザーの判断に委ねていた。

5モデルが攻撃者に支払った

3つ目の実験では、エージェントへの指示は受信箱の要約だけだった。攻撃者はユーザーになりすました一連のメールを送り、まず期限前に攻撃者のアドレスへ0.02 $USDCを送るよう求め、その後、エージェントが許可を求めるのを先回りするフォローアップを2通送った。

10モデル中5モデルが上限を引き上げ、攻撃者に支払った。論文に再現例が掲載された実行では、deepseek-v3.1はユーザーに実行してよいか2度尋ね、偽造された返信をそれぞれ回答として読み取り、支出上限に達すると、メールで届いたコードを使って上限を引き上げ、送金した。成功例の大半はQwenとDeepSeekのモデルだった。GPTとClaudeのモデル、およびgemini-3.8-flashは概して持ちこたえた。

研究者らは適応的にインジェクションを開発し、モデルごとに調整したものではなく、モデルをまたいで機能する攻撃を1つ目指した。これは、特定の既知の導入環境を標的とする攻撃者にとっての下限だと説明している。

エージェント内部のゲート

論文の理論面では、著者らが「不可譲の人間参加型」、すなわちI-HITLと呼ぶものを定義している。これは、エージェントがユーザーのデバイスを完全に侵害した場合でも維持される承認プロトコルだ。さらに強いバージョンでは、人間が承認の役割をエージェントに引き渡そうとした場合にも維持される。これは、人間によるAIの監督を義務付けるEU AI Actのような規則にとって重要だ。

Circleのポリシー手順や大半のエージェントフレームワークが使う、人間、プラットフォーム、サービスだけの単純な構成では、完全性と拘束力の両方を備えたプロトコルは存在し得ないと論文は証明している。敵対者は人間が見るものをすべて見て、人間が送れるものは何でも送れるため、人間のふりをすればよい。

これを解決するには、エージェントの手の届かないところに信頼できるエンティティが必要だが、それだけでは不十分だと論文は証明している。デバイスは自ら署名鍵を生成したことを証明する必要があり、より強い保証を実現するには、その鍵に制約を設け、ユーザーが取り出せないようにしなければならない。また、エージェントが上書きしたり、ユーザーに代わって読み取ったりできないディスプレイと、エージェントがソフトウェア経由で操作できない入力手段も必要だ。

台帳は要件を満たし、認証器は満たさない

これらの要件に照らすと、現在使われている承認手段の大半は基準を満たさない。

ハードウェアウォレットは基準をクリアする。専用アプリがデバイスのエンドースメント鍵で署名する場合、LedgerのNano X、Flex、Staxは要件を満たす。独自の画面とキーパッドを備えた、銀行発行のFIDO2トークンであるWultra Talismanも同様だ。同じLedgerのハードウェアでも、アプリがユーザーのリカバリーシードから派生した鍵で署名する場合は、より弱い保証にとどまる。ユーザーがそのシードをエージェントの管理下にあるソフトウェアにインポートできるためだ。

YubiKeyのような画面のないFIDO2キーは、人間がボタンを押す前に目にするテキストをプラットフォームが選べるため、要件を満たさない。プッシュ通知で承認する2要素認証アプリも、鍵の生成場所を示す証拠をサービスに提示しないため、要件を満たさない。時間ベースの認証アプリ、SMSコード、メールで届くコードは、すべての要件を満たさない。

Worldアプリも要件を満たさない。アプリがユーザーに表示する説明はプラットフォームから提供され、サービスの署名にもWorld IDの証明にも含まれないため、エージェントは人間に別の内容を見せながら、ある行為への承認を求められる。3月に公開されたWorldのAgentKitは、エージェントのウォレットを認証済みの人間に紐付けるものであり、人間への委任を防ぐものではない。

Circleが警告を追加

研究者らは9月22日にCircleへ結果を開示した。同社のエージェントウォレットのクイックスタートは、現在、次の警告から始まる。「AIエージェントにメールアカウントへの無制限のアクセスを決して与えないでください」。受信箱を読める人なら誰でもウォレットにログインして支出ポリシーを変更できるとユーザーに伝え、コードは自分で入力するよう求めている。

論文はこの注意喚起を妥当と評価し、その限界も明確に示している。分離はユーザーがそれを維持することに依存しており、保存された認証情報や認証済みのブラウザーセッションなど、別の方法で受信箱にアクセスするエージェントも、依然としてゲートを開けてしまう。ポリシーの更新手順自体は変更されていない。

チームはさらに、GoogleとAppleのアテステーションサービスとハードウェアで制御される生体認証を使い、AndroidまたはiPhoneを信頼できる主体にするプロトタイプ「Countersign」も公開した。中核となるロジックはバックエンドが約800行、各モバイルアプリが150行で、コードはGitHubでMITライセンスの下に公開されている。

念のため

関わった金額はごくわずかで、上限の引き上げは窃盗ではない。この害のない実験では、エージェントはユーザー自身の請求書の支払いにユーザーの資金を使い、複数のモデルがその後、変更について報告した。セキュリティモデルは計算論的というより記号的なもので、著者らは計算論的な扱いを今後の研究に委ねている。Circleのゲートも依然としてコードを必要とする。エージェントがそのコードを入手できるのは、ユーザーが受信箱へのアクセスを与えた導入環境に限られる。これは同社が現在、推奨しない設定だが、論文がこの設定を選んだのは、個人向けエージェント製品がメールとウォレットへのアクセスを一体で提供しているためだ。

支出上限は、業界全体でエージェントのリスクに対する標準的な対策となっている。アカウント所有者のもとで上限付きの仮想ウォレットを発行するCloudflareのエージェント向けステーブルコインウォレットから、AIショッピング残高の購入ごとの上限まで、さまざまだ。論文の結びで求めているのは、その下層の仕組みだ。ウォレットおよび認証器のベンダーに対して、人間が目にしたメッセージに承認を結び付ける方式の採用を促し、モバイルOSのベンダーには、セキュアハードウェアが表示する確認画面と、鍵の使用に指紋または顔認証が必要であることを証明する手段という、欠けている2つの機能の提供を求めている。