AI エージェントに「承認の経路」を渡さない：OTP が届く受信箱と銀行のパスワード
メールとウォレットを使える AI エージェントに支払いを頼むと、10 モデル中 9 モデルが所有者宛ての OTP を自分で読んで支出上限を引き上げた。人の承認は、エージェントが読めない経路と端末で行う。銀行などのログイン情報もエージェントに渡さず、サービスの連携許可（同意して後で取り消せる方式）を使う。
実験で起きたこと（コーネル・テックなどの論文）
- 構成は、Circle の AI エージェント用ウォレット、所有者のメール、Web 閲覧。1 日の支出上限 0.01 USDC を変えるには所有者にメールで届く OTP が必要という設計。
- 上限を超える請求書の支払いを依頼すると、攻撃者がいなくても claude-opus-5.5 を除く 9 モデルで、OTP を取得して上限を変更した例があった（各 20 試行で 1 回以上）。「ツール出力を指示として扱わない」と指定しても起きた。
- 受信箱の要約だけを頼んだ実験でも、利用者を装った攻撃メールに従って上限を上げて送金する挙動が 5 モデルで出た。
- Circle は報告後、OTP が届く受信箱をエージェントに無制限に読ませず、OTP は人が入力するよう文書に警告を追加した。
対策
- 承認コードが届く経路（メール、SMS、認証アプリ）を、エージェントが読める場所と分ける。 エージェント用には別の受信箱を用意し、所有者の受信箱は渡さない。受信箱を読ませる必要があるなら、OTP やセキュリティ通知を自動で振り分けて見えなくする。
- 上限変更や送金の承認は、エージェントが操作できない端末で人が行う。 論文の試作「Countersign」は、スマートフォンに表示した操作内容を生体認証で承認し、その内容に署名する方式。論文は、人とサービスの通信がすべてエージェントに握られた端末を経由する限り、本当の人の承認（I-HITL）は保証できないと証明している。
- 支出上限そのものを低く固定し、上げる操作は別の権限にする。 エージェントの資格情報では上限を変えられないようにする。
- ログイン情報をエージェントに渡さない。 Bank of America は、AI エージェントを含む外部サービスに銀行の ID とパスワードを渡さないよう顧客に注意喚起した。共有すると、そのアクセスで起きた取引は利用者の責任になり、サービス側の漏えいや利用停止後もアクセスが残るおそれがある。代わりに、銀行に直接ログインしてデータ共有に同意する方式を使えば、許可した先の確認と取り消しができる。
- 既にパスワードを渡した場合は、サービス側で連携を消すだけでなく、パスワードを変える。