エージェント決済のAP2とACPは委任の範囲をどう縛るか

FIDO Alliance, “FIDO Alliance to Develop Standards for Trusted AI Agent Interactions”, 2026年4月28日公開。「これらの取り組みには、Agentic Authentication Technical Working Groupの設置と、Google(AP2)とMastercard(Verifiable Intent)からの初期の寄稿を踏まえたagent-initiated commerce向けの仕様策定が含まれる」(“These initiatives include the formation of an Agentic Authentication Technical Working Group and efforts to develop specifications for agent-initiated commerce, drawing from initial contributions from Google (AP2) and Mastercard (Verifiable Intent).”)、「今日の認証・認可モデルは、直接の人間の操作のために設計されており、委任された、エージェント発の行為のためではない」(“today’s authentication and authorization models were designed for direct human interaction, not delegated, agent-initiated actions.”)、「サービス提供者は、誰が行為を認可したか、どんな条件のもとで、どんな上限で認可したかを含め、利用者の意図を検証する信頼できる相互運用可能な手段を欠いている」(“service providers lack reliable, interoperable ways to verify user intent – including who authorized an action, under what conditions, and with what limits.”)と書き、「GoogleはAgent Payments Protocol(AP2)を寄稿した」(“Google has contributed its Agent Payments Protocol (AP2)“)とする。作業部会の割り当ては「開始時点で、Agentic Authentication Technical Working GroupはCVS Health・Google・OpenAIのメンバーが議長を務め」(“At launch, the Agentic Authentication Technical Working Group is chaired by members from CVS Health, Google and OpenAI”)、「並行して、FIDO AllianceはMastercardとVisaのメンバーが議長を務めるPayments Technical Working Groupの中でagent-initiated commerce向けの仕様を策定している。GoogleとMastercardからの技術的な寄稿が、これらの仕様の初期の土台を提供している」(“In parallel, the FIDO Alliance is developing specifications for agent-initiated commerce within its Payments Technical Working Group, chaired by members from Mastercard and Visa. Technical contributions from Google and Mastercard are providing an initial foundation for these specifications.”)、「MastercardはGoogleと共同開発しAP2と組んで動くよう設計されたVerifiable Intentの枠組みを寄稿した」(“Mastercard has contributed its Verifiable Intent framework, co-developed with Google and designed to work with AP2”)と書く。https://fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/ ↩ ↩² ↩³

Agentic Commerce Protocol, “RFC: Agentic Commerce — Delegate Payment API”, Version 2025-09-29, Status Draft（GitHub、2026年9月21日取得）。「本RFCは、決済資格情報のための委任済みvault tokenを発行する、単一の、実装必須(MUST-implement)なHTTPエンドポイントを定義する」(“This RFC defines a single, MUST-implement HTTP endpoint that issues a delegated vault token for a payment credential.”)、「支払い・清算・コンプライアンスは加盟店のレールに残る」(“Payments, settlement, and compliance remain on the merchant’s rails.”)、「加盟店がChatGPT発のチェックアウトのために決済資格情報を安全に委任できるようにする」(“Enable merchants to safely delegate a payment credential for use in ChatGPT-initiated checkouts.”)、「返されるtokenは、提供されたAllowance(reason、max_amount、currency、expiry)の範囲内でのみ使用できる」(“The returned token MUST ONLY be usable within the provided Allowance (reason, max_amount, currency, expiry).”)、「reasonはone_timeでなければならない」(“reason: MUST be one_time”)、「tokenはその後、加盟店の既存のPSPが明示的なAllowanceの制約の範囲内でのみ使用できる」(“The token may then be used by the merchant’s existing PSP only within explicit Allowance constraints.”)、「Clientは自身の秘密鍵で分離署名を計算しなければならない」(“Client MUST compute a detached signature with its private key”)、「今日サポートされる資格情報の種類はちょうど一つ、cardである」(“Exactly one credential type is supported today: card.”)と書く。Version 2025-09-29はこのRFCのAPI-Versionである。同リポジトリの”RFC: Payment Handlers”（https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.payment_handlers.md）は、handlerのrequires_delegate_paymentを「すべてのhandlerについてtrueを推奨」(“RECOMMENDED: true for all handlers to ensure explicit allowance constraints and secure credential handling.”)とし、決済手段に"payment_methods": ["card", "card.agentic_token"]を例示し、委任端点を通す理由を「1. 明示的なallowanceの上限 2. リスク信号の標準化 3. 資格情報のスコープ 4. 監査証跡 5. セキュリティの分離」(“1. Explicit allowance bounds: max_amount, currency, expires_at, checkout_session_id 2. Risk signal standardization: Consistent risk data format across payment methods 3. Credential scoping: Tokens bound to specific checkout sessions and merchants 4. Audit trail: Clear record of credential creation and usage 5. Security separation: Vault infrastructure separate from payment processing”)と列挙する。同RFCの§6.4は資格情報の保管の流れを「2. エージェントは加盟店のPSP(Stripe)に対しmerchant_idを使ってdelegate_paymentを呼ぶ 3. PSP(Stripe)が加盟店のアカウントに限定したvault token(SPT)を作る 4. エージェントがSPTを加盟店へ渡す 5. 加盟店はSPTを自分のPSP(Stripe)で開いて使う」(“2. Agent calls delegate_payment with the Seller’s PSP (Stripe) using the merchant_id 3. PSP (Stripe) creates vault token (SPT) scoped to the Seller’s merchant account 4. Agent submits SPT to Seller 5. Seller unwraps and uses the SPT with their PSP (Stripe)“)と書く。“RFC: Agentic Commerce Checkout”（https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.agentic_checkout.md）は「3DSなどの認証が必要なとき、サーバはsession.statusをauthentication_requiredにしなければならない」(“Server MUST set session.status to authentication_required when authentication (e.g., 3DS) is required.”)、「そのときクライアントは提供されたメタデータで認証を試み、POST /completeのリクエスト本文でauthentication_resultを返さなければならない」(“When status is authentication_required, the client MUST attempt authentication using the provided metadata and MUST return the authentication_result in the POST /complete request body”)と定める。“RFC: Orders”（https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.orders.md）は調整の種類の一つにdisputeを置き、「紛争またはチャージバック」(“Dispute or chargeback”)と説明する。README（https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/README.md）は最新安定版をspec/2026-04-17/とし、「本仕様はOpenAIとStripeによって保守されており、現在betaである」(“The specification is maintained by OpenAI and Stripe and is currently in beta.”)と書く。リポジトリは2025年9月29日に作られ、2026年9月21日時点のスターは1,546（GitHub API調べ）。https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.delegate_payment.md ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹

Google Agentic Commerce, “Agentic Payment Protocol (v0.2)” specification（GitHub、2026年9月21日取得）。「以下の役割は非エージェント的でなければならない」(“The following role MUST be non-agentic:”)、「役割がエージェント的かどうかに関わらず、それは決定的なコードで行われなければならない」(“it MUST happen in deterministic code regardless of whether the role is agentic or not.”)、「Mandateは、AP2がエージェントを認可するために使う中核の手段である」(“Mandates are the core means that AP2 uses to authorize agents.”)、「CheckoutとPaymentのMandateの中身は、利用者が何の作業を望むかを決めたあとにShopping Agentが組み立てる」(“The Checkout and Payment Mandate contents are assembled by the Shopping Agent after it has determined what task the user wishes it to perform.”)、「人が居ない場合(自律)：利用者は、閉じたCheckoutとPaymentが自分の意図をどのように満たすかについての制約の集合を見て承認する」(“Human Not Present (Autonomous): The User sees and approves a set of constraints over what closed Checkout and Payment would meet their intent.”)、「自律の場合、閉じたMandateはエージェントの鍵で署名される。この鍵への信頼は、利用者または信頼されたエージェント提供者の一覧が署名した開いたMandateが与える」(“In the Autonomous case, the closed Mandates are signed by an Agent key. Trust in this key is provided by open Mandates that are signed by the User or a trust list of Agent Providers.”)、「これらはエージェントの公開鍵をcnfクレームとして含まなければならない」(“These MUST include the agent’s public key as a cnf claim.”)、「これらのMandateのexpクレームは、Shopping Agentが割り当てられた作業を完了できる最小の値に設定することが推奨される」(“It is RECOMMENDED to set the exp claim for these Mandates to the smallest value that will allow the Shopping Agent to complete the assigned task.”)、「Shopping Agentは、前のMandateからの拒否の受領を受け取ることなく、後続の開いたPaymentまたはCheckout Mandateを提示してはならない」(“Shopping Agents MUST NOT present any subsequent open Payment or Checkout Mandates without receiving a rejection receipt from the previous one.”)、「これは、エージェントが同じ開いたMandateを使って複数の異なるCheckoutを承認することを防ぐためである」(“This is to prevent an Agent approving multiple different Checkouts using the same open Mandate.”)、「加盟店の決済処理事業者は、Payment CredentialがそのCheckoutに適切に絞られていることを検証しなければならない」(“Merchant Payment Processor MUST verify the Payment Credential is appropriately scoped to the Checkout.”)、「現行仕様では、Shopping Agentが該当するMandateと開示をCheckoutに基づいてその場で決める必要がある。将来、商取引プロトコルに明示的な問い合わせ言語を用いると相互運用に役立つ」(“In the current specification, the Shopping Agent needs to determine the applicable Mandates and Disclosures ad-hoc based on the Checkout. In the future, utilizing an explicit query language in the commerce protocol can help practical interoperability.”)、「これがどのように紛争解決に使われるか、保存と取り出しの要件についての具体的な詳細は、本仕様の範囲外である」(“Specific details of how this is used for dispute resolution, retention, and retrieval requirements are outside the scope of this specification.”)、「単一の主体が複数、あるいはすべての役割を担うことも可能である。その場合、主体は担う各役割の責任をすべて負う」(“it is possible for a single entity to play multiple (or even all) of the roles. In that case, they would take on all of the responsibilities of each role they are playing.”)、「支払いの経路が二つの非エージェント的な面のあいだで直接行われる場合には、既存のECセキュリティモデルで十分である」(“In the case where the payment journey happens directly between two non-agentic surfaces (such as a Trusted Surface communicating directly with a non-agentic Merchant), then existing e-commerce security models are sufficient.”)、人が居る場合の注記として「利用者が閉じたCheckoutを承認するので、これは加盟店とTrusted Surfaceが直接やり取りする従来のECの流れに置き換えられることが多い」(“Because the User approves the closed Checkout, this can often be replaced with a traditional e-commerce journey where the Merchant and the Trusted Surface communicate directly.”)、「利用者のプライバシーを確保するため、Shopping Agentは閉じたMandateの評価に必要な開いたMandateからの開示だけを提示しなければならない」(“To ensure user privacy, Shopping Agents MUST present only the disclosures from the open Mandates needed in the evaluation of the closed Mandates.”)、「紛争の場合、Checkout Mandateと受領書、Payment Mandateと受領書を合わせて、取引の否認できない全体像を提供できる」(“In the case of a dispute, the Checkout Mandate and Receipt, and Payment Mandate and Receipt can be brought together to provide a non-repudiable picture of the transaction.”)、「紛争時に検証を行う場合、PaymentとCheckoutのMandateと受領書の完全性を保証するため、以下の手順に従わなければならない」(“When performing verification at the time of dispute, the following steps MUST be followed to ensure the integrity of the Payment and Checkout Mandate and Receipts.”)、「AP2は、Agentic Commerceの要請に適応できるよう、いくつかの拡張点を備える」(“AP2 provides several extension points to allow it to adapt to meet the needs of Agentic Commerce.”)、「概念上、この方式をあるShopping Agentから別のShopping AgentへのMandateの委任を支えるために使うことは可能である。これは現行仕様の範囲外である」(“Conceptually, it is possible to use this protocol to support delegation of Mandates from one Shopping Agent to another. This is outside the scope of the current specification.”)と書く。同リポジトリの”Payment Mandate”（https://github.com/google-agentic-commerce/AP2/blob/main/docs/ap2/payment_mandate.md）は、開いたPayment Mandateの制約に「Agent Recurrence：エージェントがこのPayment Mandateを複数回使うための条件を与える」(“Agent Recurrence: Provides conditions for the agent reusing this Payment Mandate multiple times.”)と「Budget：総額の上限を与える。Agent Recurrenceの制約とともに使う」(“Budget: Provides a total amount limit. To be used with the Agent Recurrence constraint.”)を置き、Agent Recurrenceの評価は頻度と「max_occurrencesの上限が現在の回数以上であること」(“and the max_occurrences limit is greater than or equal to the current occurrences”)を見ると書く。https://github.com/google-agentic-commerce/AP2/blob/main/docs/ap2/specification.md ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵

Avital Aviv, Parth A. Gandh, Ron Bitton, Asaf Shabtai, “Beyond the Mandate: A Systematic Security Analysis of the Agent Payments Protocol (AP2)”, arXiv:2608.23858, v1 2026年8月24日。「署名されたCheckoutとPayment Mandateは、署名後の取引データの完全性を守る。承認前に取引を形づくるエージェントの相互作用と外部入力は、Agent-to-Agent Protocol(A2A)のメッセージやModel Context Protocol(MCP)のツール呼び出しを含め、その保護の外に残る」(“Its signed Checkout and Payment Mandates protect the integrity of transaction data after signing. Agent interactions and external inputs that shape a transaction before authorization remain outside that protection, including Agent-to-Agent Protocol (A2A) messages and Model Context Protocol (MCP) tool calls.”)、「先行研究はAP2 v0.1におけるリプレイ攻撃とプロンプトインジェクション攻撃を特定した。AP2 v0.2はこれらの問題の一部に対処するが、新たな能力と展開の前提を加えており、再分析を要する」(“Prior work identified replay and prompt-injection attacks in AP2 v0.1. AP2 v0.2 addresses some of these issues but adds capabilities and deployment assumptions that require renewed analysis.”)、「MAESTROを用いて、四つの脅威主体、十一の攻撃面、十八の攻撃者能力、六つの攻撃目標をモデル化する」(“Using MAESTRO (Multi-Agent Environment, Security, Threat, Risk, Outcome), we model four threat actors, eleven attack surfaces, eighteen adversary capabilities, and six attacker goals.”)、「結果として得られた目録は、五つの攻撃系統にわたる48件の脅威を含む」(“The resulting catalog contains 48 threats spanning five attack families.”)、「少なくとも一つのアーキテクチャでHigh帯に達する8件を特定した」(“identifying eight that reach the High band in at least one architecture.”)、「完全な公開AP2実装が利用できなかったため、五つのアーキテクチャすべてにわたるテストベッドを構築し、High帯の8件の脅威とその緩和策すべてを覆う五つの概念実証を開発した」(“Because no complete public AP2 deployment was available, we build a testbed spanning all five architectures and develop five proof-of-concept demonstrations covering all eight High-risk threats and their mitigations.”)、「我々の分析は、有効なMandateの署名だけでは、署名前の文脈が操作されたとき、エージェントが仲介した取引が利用者の意図を反映することを保証しないことを示す」(“Our analysis shows that valid mandate signatures alone do not ensure that an agent-mediated transaction reflects the user’s intent when its pre-authorization context is manipulated.”)と書く。PDF版（https://arxiv.org/pdf/2608.23858v1）の§9.1.1は「エージェント認可は、署名された意図だけでなく運用上の文脈を束縛しなければならない」(“Agentic authorization must bind operational context, not only signed intent.”)、「エージェント認可のプロトコルは、関連する署名前の文脈を発行する成果物に束縛するか、そうした束縛を作らない実行経路を拒否すべきである」(“Agentic authorization protocols should bind relevant pre-signature context to issued artifacts or reject execution paths that do not produce such bindings.”)と書き、§9.2.1は「そのため我々は、概念実証に用いたAP2のテストベッドを構築した」(“We therefore built the AP2 testbed used for our PoCs.”)とし、「これは、同じ失敗が将来の第三者の展開でも変わらず現れると主張する我々の能力を制限する」(“This limits our ability to claim that the same failures will appear unchanged in future third-party deployments”)と断る。§6（p.12）の実証AM1は「利用者はSAに、50ドル以下でカメラを1台買うよう頼む」(“The user asks the SA to buy one camera for no more than $50.”)、「SAはその結果を、min=5000、max=8000、currency=USDのpayment.amount_range制約に写す」「そのMCPの見積もりツールは50ドルから80ドルの金額の範囲を返すが、支払先の欄は無い」(“Its MCP quote tool returns an amount range from $50 to $80 but no payee field.”)、(“The SA maps that result into a payment.amount_range constraint with min=5000, max=8000, and currency=USD.”)、「ツールが支払先を返さないので、写す処理はpayment.allowed_payeesの制約を出さない」(“Because the tool supplies no payee, the mapper emits no payment.allowed_payees constraint”)、「同意の手順が警告しなかったことと加盟店の説明を頼りに、利用者は開いたMandateを承認する」(“Relying on the consent workflow’s lack of a warning and the merchant’s explanation, the user authorizes the open mandates.”)、「加盟店はのちに同じカメラの80ドルの加盟店署名付きCheckoutを作り、SAは結びつけられたエージェント鍵で対応する閉じたCheckoutとPayment Mandateに署名する」(“The merchant later creates a merchant-signed checkout for the same camera at $80, and the SA signs the corresponding closed Checkout and Payment Mandates with its bound agent key.”)と書き、緩和として「利用者の上限を超える最大値や、利用者が明示的に認めていない支払先の制限の欠落を拒み、自らが表示したバイトだけに署名する」(“It rejects a maximum above the user’s limit or an absent payee restriction that the user did not explicitly authorize, and signs only the bytes it rendered.”)を挙げる。https://arxiv.org/abs/2608.23858 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹

Google Agentic Commerce, “Agent Authorization”（GitHub、2026年9月21日取得）。「非決定的な処理のため、行儀の良いエージェントであっても、通常の認可モデルが人間の利用者に求める以上に、その挙動を強く制約する必要がある」(“Due to their non-deterministic processes, even well-behaving Agents need to have their behavior tightly constrained above what a normal authorization model would require of human users.”)、「Mandateの委任：利用者は、エージェントが自分に代わって何らかの行為を行うことを認可する」(“Mandate Delegation: A User authorizes an Agent to perform some action (or actions) on their behalf.”)、「行為の認可：ここでは検証者がエージェントに対し、利用者に代わって行為を行う権限を持つことの証明を求める」(“Action Authorization: Here a Verifier challenges an Agent to provide proof that it is authorized to perform an action on behalf of a User.”)と書く。Mandate Delegationの型として「本書は以下のモデルを定義する: User Credential、Trusted Agent Provider」(“This document defines the following models for Mandate Delegation: - User Credential - Trusted Agent Provider”)を挙げ、後者について「エージェント提供者は、安全に保管した署名鍵を使ってMandateを作る」(“The Agent Provider uses a securely stored signing key to create the Mandate.”)、「エージェント提供者は、エージェントがその署名鍵にアクセスできず、Trusted Surfaceなしに使えないことを保証しなければならない」(“The Agent Provider MUST ensure that the Agent is not able to access the Agent Provider signing key, or use it without the Trusted Surface.”)と書く。立ち位置: リポジトリは2025年5月30日に作られ、2026年9月21日時点のスターは3,183（GitHub API調べ）。v0.1.0は2025年9月16日、v0.2.0は2026年4月28日で、リリースノートは「これはAP2の第二版であり、Human Not Presentのフローを提供することに焦点を当てる」(“This is the second release of AP2. It focuses on providing Human Not Present flows.”)と書く。https://github.com/google-agentic-commerce/AP2/blob/main/docs/ap2/agent_authorization.md ↩ ↩² ↩³

Google Agentic Commerce, “Security and Privacy Considerations”（GitHub、2026年9月21日取得）。「エージェントセキュリティの現状を踏まえ、AP2はプロンプトインジェクション攻撃を防ぐことは不可能だと仮定する。したがって、すべてのLLMとエージェントは潜在的な攻撃者とみなさなければならず、脅威モデルに明示的に含まれる」(“Given the current state of agent security, AP2 assumes that preventing prompt injection attacks is infeasible. Therefore, all LLMs and Agents MUST be considered potential attackers and are explicitly included in the threat model.”)、「閉じたMandateは、提示された開いたMandateに結びつけるため、sd_hashクレームを含まなければならない」(“Closed Mandates MUST contain the sd_hash claim to bind them to the presented open Mandate.”)、「開いたMandateは、そのエージェントだけが有効な署名を持つ閉じたMandateを作れるようにするため、cnfクレームを介してエージェントの鍵を含まなければならない」(“Open Mandates MUST contain the Agent’s key (via a cnf claim) so that only the agent could create a Closed Mandate with a valid signature.”)と書く。Manipulated Discoveryの節は脅威として「プロンプトインジェクションにより、Shopping Agentが悪意ある商品を選んだり、まずい購買判断をしたりする」(“Prompt injection causes the Shopping Agent to select malicious products or make poor purchase decisions.”)を挙げ、緩和として「LLMが最適な選択に失敗しても、閉じたMandateの検証時の制約評価により、最悪の場合の金銭的・論理的な影響は厳密に有界になる」(“Even if the LLM fails to make the optimal choice, constraint enforcement during closed Mandate verification ensures that the worst-case financial and logical impacts are strictly bounded.”)と書く。Double Spendの節は脅威として「プロンプトインジェクションを受けた、あるいは悪意あるShopping Agentが、同じ開いたMandateを使って複数の有効なCheckoutを承認しようとする」(“A prompt injected, or otherwise malicious Shopping Agent attempts to approve multiple valid Checkouts using the same open Mandate.”)を挙げ、緩和として「Shopping Agentの非決定的な部分は、前に出したMandateを拒否する受領書を受け取らずに、同じ開いたMandateについて重なり合う複数の閉じたMandateに署名することを避けなければならない」(“The non-deterministic portion of the Shopping Agent MUST avoid signing multiple, overlapping closed Mandates for the same open Mandate without receiving Receipts rejecting the previously released Mandates.”)、「これらの受領書は、Shopping AgentのLLMから完全性を保護されなければならない」(“These Receipts MUST be integrity protected from the Shopping Agent’s LLM.”)、「Credential Provider、決済網、MPPは、重なり合う複数のMandateを拒否するか、前に発行した決済トークンを無効にしてよい」(“Credential Provider, Networks or MPPs MAY reject multiple overlapping Mandates, or invalidate previously issued payment tokens.”)と書く。https://github.com/google-agentic-commerce/AP2/blob/main/docs/ap2/security_and_privacy_considerations.md ↩ ↩² ↩³ ↩⁴ ↩⁵