AI エージェントの自動支払いには上限と受取先の検証を入れる（x402 の 25 件の問題から）

何が起きていたか

x402 では API 提供側が「金額・暗号資産の種類・受取先」を 402 応答で示し、利用側クライアント（AI エージェントなど）が人の承認なしで支払いに署名する。調査元 V12 が報告した 25 件のうち重要なのは次の 3 つ（重大なものは 8 月 20 日までに修正済み）。

• 支払い上限なし: 修正前の既定クライアントには 1 回分・合計とも上限がなかった。攻撃者は先に少額決済で得たアドレスから残高を調べ、その額を請求できる。
• 販売側の検証漏れ: TypeScript 版の Solana 向け exact 方式で、送金を許可するだけの ApproveChecked 命令を実際の送金と誤認し、代金を受け取らずに有料リソースを渡すおそれ。
• Sign-In-With-X の中継: クライアントが、接続先とは別のサイトが発行した認証要求にも自動で署名していた。攻撃者が署名を中継すれば、利用者のウォレットとしてログインできる。

対策

1. SDK を更新し、組み込みの支出制御を有効にしたままにする。 TypeScript 版 core 2.23.0 以降は spendControls があり、既定では認識済みの米ドル連動資産だけを 1 回 1 米ドルまで許可する。spendControls: false は制御を丸ごと切るので使わない。
2. 署名前に自前でも検証する。 許可する資産・ネットワーク・受取先アドレスを許可リストにし、1 回あたりと期間合計の上限を超えたら署名しない。
3. 署名機能（外部ウォレット・KMS）側にも上限をかける。 アプリ側の制御が外れても残高全額が出ていかないよう、エージェント専用のウォレットに少額だけ入れておく。
4. 販売側は「送金命令」を確認する。 支払い検証では命令の種別まで見て、許可（approve）だけの取引を支払い済みと扱わない。
5. ウォレット認証は接続先と照合する。 修正版と同じく、認証要求の domain を 402 応答の最終 URL のホストと、uri のオリジンを最終 URL のオリジンと照合し、一致しなければ署名を拒否する。

考え方

「人が毎回承認しない支払い」は、クレジットカードを渡しっぱなしにするのと同じ。x402 に限らず、エージェントに課金 API やクラウドの請求先を触らせる場合は、上限・許可リスト・専用の少額財布の 3 点をそろえる（請求先乗っ取りの例は クラウドの請求先を乗っ取られて AI 利用料を払わされない（GCP の LLMjacking 事例） も参照）。

出典

• @MalwareBibleJP · 2026-10-27
• 一次情報: V12 v12.sh/blog/x402 、x402 CHANGELOG github.com