Linux Foundationは2026年7月14日、x402 Foundationの設立を発表し、AIエージェント決済プロトコルに公式な拠点を設けました。Visa、Mastercard、Stripe、Googleが創設メンバーとして名を連ねています。
この発表では、決済の主張が真正であることを証明する方法が示されていません。適合性スイート（conformance suite）も、セキュリティプロファイルも、認証プログラムも、検証手順も存在しません。基盤となる仕組みは定義されていますが、エージェントが実際に支払権限を受け取ったという証明が欠けています。
ローンチと欠落している要素
x402プロトコルは、自律型ソフトウェアエージェントが領収書や支払いの証拠を交換する方法を標準化します。その標準化は必要なステップですが、決済システムに求められる要件の半分に過ぎません。従来の金融では、メッセージ形式が正しいという理由だけで取引が受理されるわけではありません。支払者の意図、リクエストの真正性、および暗号化チェーンの整合性を検証する一連のセキュリティチェックを通過しなければなりません。
x402の創設文書はメッセージ形式を詳細に記述していますが、実装が要求されるセキュリティチェックを強制しているかどうかを確認するためのテストハーネスの指定には至っていません。中立的なテストスイートがなければ、ベンダーは重要な保護策を密かに省略しながら、「仕様に従っている」と主張できてしまいます。
なぜ領収書だけでは不十分なのか
x402の世界における決済領収書は、次の3つの主張を行います。
- アクションが発生した。
- アクションが承認された。
- セキュリティチェックが実際に実行された。
デジタル署名は最初の主張を保証できます。つまり、誰かが特定の記録に署名したことを証明できます。しかし、2番目と3番目の主張に対しては何の役にも立ちません。攻撃者は、有効に見える領収書を偽造したり、古い領収書をリプレイ（再利用）したり、メッセージのタイミングを操作して、根本的な承認が一度も行われないようにしたりすることができます。現在の標準では、これらの攻撃をどのように検知または防止すべきかが規定されていません。
標準的なチェックをすり抜ける具体的な攻撃
最近のShareLockの論文（arXiv 2606.27027）は、領収書の各部分を個別に検証するだけのパーサー（解析器）では検知できない攻撃の一種を示しています。著者らは、攻撃者が複数のツール記述にまたがって悪意のある指示を埋め込む方法を示しました。個々の記述はすべて構文チェックと署名チェックを通過しますが、システムがそれらを組み立てたとき、組み合わせた効果によって、支払者の同意なしに支払いを承認する隠れたコマンドとなります。
x402の仕様は各コンポーネントが正しく解析されることのみを要求しているため、ShareLockで説明されている攻撃は、既存の検証ルールのみに依存するあらゆる実装に対して成功してしまいます。問題は暗号技術の欠陥ではなく、権限の主張が構成（composition）後も維持されるという保証の欠如にあります。
誰が権限をテストすべきか
プロトコルの作成者は偏見なしに自らの設計をレッドチーム（攻撃側）として検証することはできず、ベンダーも独立した視点なしに自社のセキュリティを認証することはできません。したがって、業界には次のような中立的で敵対的なテストフレームワークが必要です。
- 実装による領収書、署名、および状態遷移の処理に対して、一連の適合性テストを完全に実行する。
- ShareLockによって示されたマルチパート・インジェクションのような、脅威モデルに基づいた攻撃シナリオを実行し、構成下でも権限の主張が維持されることを検証する。
- 独立したラボが、実装がリプレイ攻撃、偽造、および同期ずれ攻撃に耐えられることを実証した後にのみ、認証を発行する。
x402のローンチは、初日からそのレイヤーを空のままにしました。第三者によるテストスイートがなければ、「準拠している」という主張は、単に「構文チェックを通過した」という意味に過ぎない可能性があります。
まとめ
x402プロトコルには拠点ができました。しかし、ベンダーに依存しない適合性およびセキュリティテストのフレームワークがなければ、各決済の背後にある権限は検証されないままとなります。独立した機関が、領収書の「承認済み」という主張が現実世界の攻撃に耐えうることを証明できるまで、安全なAIエージェント・コマースの約束は手の届かないところに留まり続けるでしょう。