Agent Payments Protocol (AP2)

• AP2 is a cryptographic framework that enables secure, autonomous payments between AI agents using decentralized identifiers and verifiable credentials.
• It integrates on-chain settlement, zero-knowledge privacy, and flexible micropayment mechanisms to minimize trust assumptions and enforce intent alignment.
• The protocol’s layered architecture separates identity, mandate issuance, and payment settlement, ensuring auditability, replay protection, and resilience against adversarial attacks.

The Agent Payments Protocol (AP2) is a cryptographic framework and protocol suite enabling fully autonomous, authenticated, and auditable payments between AI agents within open, multi-agent digital economies. AP2 extends inter-agent communication protocols (notably Google’s Agent-to-Agent, A2A) by integrating decentralized agent identity, verifiable delegation of financial authority, secure intent-binding, on-chain/ledger settlement, zero-knowledge privacy, and flexible micropayment mechanisms anchored in distributed ledger technology (DLT). It is designed to minimize trust assumptions in agent-mediated payments, providing layered defenses against manipulation, unauthorized spending, and breakdowns in intent alignment, particularly in settings where agents act on behalf of end users and collaborate across organizational and network boundaries (Vaziry et al., 24 Jul 2025, Acharya, 8 Nov 2025, Hu et al., 5 Nov 2025, Friolo et al., 2024, Debi et al., 30 Jan 2026).

1. Protocol Architecture and Functional Layers

AP2’s architecture delineates clear boundaries between agent identification/authentication, mandate issuance, settlement workflow, and auditability:

• Agent Identity and Discovery: Each autonomous agent is assigned a decentralized identity (DID), published on-chain using a method such as did:ap2:<agent-id>, and backed by cryptographic keys listed in associated DID documents. Agent metadata (“AgentCard”)—including endpoint URLs, capabilities, and economic parameters—is published on-chain via smart contracts, ensuring tamper-proof, globally synchronized identities (Vaziry et al., 24 Jul 2025, Acharya, 8 Nov 2025).
• Mandate and Credential Infrastructure: Financial authority is granted through user (principal)-signed mandates, typically in the form of W3C Verifiable Credentials (VCs), specifying policy constraints (e.g., permitted spend, payees, and expiration). These VCs are signed using Ed25519 or secp256k1 keys, and anchoring their hashes on-chain enables efficient revocation and verification. Mandates are structured as JSON payloads, cryptographically signed and—when needed—accompanied by zero-knowledge proofs attesting to compliance (Acharya, 8 Nov 2025, Hu et al., 5 Nov 2025).
• Payment Channels and Settlement: For operational payments, AP2 supports both micropayment flows (e.g., HTTP x402 via HTTP 402 status + EIP-3009 transferWithAuthorization) and classic mandate-driven transactions. Settlement occurs via programmable agent wallets or escrow contracts that enforce intent, validate ZK proofs, and emit audit events (Vaziry et al., 24 Jul 2025, Acharya, 8 Nov 2025).
• On-chain/Off-chain Split: While on-chain activities encompass identity, mandate root anchoring, micropayment settlement, and event logging, off-chain logic handles natural language processing, LLM-driven negotiation, user experience, and multi-agent orchestration. This split both improves scalability and compartmentalizes attack surfaces (Vaziry et al., 24 Jul 2025, Acharya, 8 Nov 2025).

2. Agent Identity, Credentialing, and Discovery

AP2 situates agent discovery in a decentralized, verifiable registry landscape:

• Identity Publication: Agents publish AgentCards through on-chain smart contracts, with methods such as getAgentCardJSON() returning all relevant data including DLT-anchored economic parameters and reputation counters (e.g., transaction count). These contracts restrict updates and withdrawals to the contract owner and expose explicit activation/keep-alive logic, ensuring robust liveness semantics (Vaziry et al., 24 Jul 2025, Hu et al., 5 Nov 2025).
• DID and Verifiable Credential Mechanics:
  • Each agent is associated with a DID conforming to W3C standards, and DID Documents enumerate authentication keys and service endpoints for interaction and credential validation.
  • Users grant agents payment authority through W3C VC–formatted “mandates.” These credentials encode domain, scope (e.g., maxSpend, allowed payees, validity window), and public keys, and are cryptographically bound to agent DIDs (Acharya, 8 Nov 2025).
  • Mandates are anchored via hashes in DID Registry contracts, allowing on-chain revocation bitmaps and Merkle-root-based proof-of-possession.
• Discovery Mechanisms: Agents and clients retrieve peer identities and service endpoints by querying on-chain AgentSmartContract instances, off-chain aggregators, or via direct HTTP to the agent’s .well-known location. Economic/contact parameters for payment are revealed directly as x402 extensions (Vaziry et al., 24 Jul 2025).

3. Transaction and Payment Flows

AP2 distinguishes between two primary transaction modalities—micropayment (x402) and mandate-based payment execution:

• HTTP x402 Micropayment Flow: Designed for low-latency service payments between agents, this extension layers EIP-3009 signed transferWithAuthorization flows over HTTP 402 negotiation. The typical flow involves:
  1. Client initiates an A2A JSON-RPC call without payment; server responds with HTTP 402, specifying payment details.
  2. Client constructs and signs an EIP-3009 transfer authorization (receiver, amount, nonce, expiry).
  3. Client resubmits request with X-PAYMENT header containing the signed payload.
  4. Server validates the payment on-chain and, on settlement, executes the requested resource/method and returns transaction confirmation (Vaziry et al., 24 Jul 2025).

• Mandate Proof and Settlement Flow: For higher-value or policy-constrained transactions, agents present signed mandates or VCs during payment requests:

  • All transactions encapsulate an envelope $$E = (\mathsf{DID}_{agent}, \mathsf{DID}_{user}, \mathrm{payload}, \mathrm{nonce}, \sigma_{agent})$$.
  • Optionally, the agent provides a zero-knowledge proof $\pi$ attesting (1) possession of a valid, non-revoked VC, and (2) enforcement of policy constraints (e.g., maximum spend, payee whitelist).
  • On-chain AgentWallet contracts verify signatures, sequence nonces, validate ZK proofs via dedicated ZKVerifier contracts, and enforce additional (optionally dynamic) on-chain policy hooks before releasing funds and emitting an immutable, auditable intent-execution event (Acharya, 8 Nov 2025, Hu et al., 5 Nov 2025).
• Auditability: Every on-chain transaction is accompanied by event logs (e.g., IntentExecuted) tagging agent, action hash, and relevant mandate identifiers. Users and auditors reconstruct mandate inclusion via Merkle proofs or registry anchoring, providing irrefutable linkage between user intent and execution outcome (Acharya, 8 Nov 2025).

4. Security and Privacy Properties

AP2’s security analysis is anchored in cryptographic guarantees, protocol isolation, and explicit intent binding:

• Authenticity and Non-Repudiation: All agent-initiated transactions must be signed by the agent’s private key, and when mandates are involved, also by the user/delegator’s key. This guarantees that only authorized agents—backed by explicit user consent—may transact (Acharya, 8 Nov 2025, Hu et al., 5 Nov 2025).
• Intent Binding and ZK Compliance: The ZK proof system allows agents to demonstrate compliance with delegation policies (e.g., spend ≤ max limit, recipient ∈ allowed set) without disclosing sensitive mandate content on-chain, ensuring selective disclosure and privacy (Acharya, 8 Nov 2025, Friolo et al., 2024).
• Replay and Double-Spend Prevention: Nonce sequencing, proof freshness, and on-chain revocation bitmaps prevent replay attacks and enforce strict one-time-use of mandates where appropriate (Vaziry et al., 24 Jul 2025, Hu et al., 5 Nov 2025).
• TEE Attestation (optional): For scenarios with high misalignment risk or LLM-driven reasoning, AP2 supports Trusted Execution Environment (TEE) attestation. Hardware-generated quotes of enclave hashes and code signatures are validated on-chain, guaranteeing agent code and credential handling integrity (Acharya, 8 Nov 2025).
• Auditable Compliance: The protocol permits post facto audit of all spending actions: each intent, mandate, and proof can be reconstructed, cryptographically checked, and matched to on-chain events. Mandate expiry, decay of staking bonds, and periodic verification cycles are enforced where mandated (Hu et al., 5 Nov 2025).
• Self-Custody and Unlinkability (privacy variant): For advanced privacy, AP2 variants employ public append-only audit logs, Pedersen commitments, and 1-out-of-N zero-knowledge proofs to unlink reissued tokens and spending keys from original owners (editor’s term: "burn-and-mint with anonymized linkage"). Secrets required for a payment may be discarded after use, eliminating persistent blackmail or coercion risk (Friolo et al., 2024).

5. Trust Models and Incentive Structures

AP2’s multi-layer trust architecture synthesizes several orthogonal mechanisms:

Trust Mechanism	Description	Application in AP2
Brief	User/inst.-signed "mandate" VCs; scoping agent privileges	Every agent delegation
Claim	Self-asserted capabilities, e.g. which payment rails an agent supports	AgentCard, discovery
Proof	Cryptographic enforcement (signatures, ZKPs, TEE attestation)	Transaction, payment settlement
Stake	Slashing collateral to disincentivize malfeasance (optional)	High-value/critical workflows
Reputation	Off-chain/ledger risk and trust scoring; Sybil/gaming resistance	Policy hooks, rate-limits
Constraint	Hard-coded or programmable smart-contract parameters	Spend caps, whitelisted payees

No single mechanism suffices: AP2 applies “trustless-by-default” principles for high-impact actions (mandate+proof+stake); lower tiers (read-only, minimal risk) may rely on claim+brief only. Smart-contract-enforced parameters, stake slashing policies, and decay rates for reputation and credentials provide continuous calibration of agent risk exposure (Hu et al., 5 Nov 2025).

6. Attack Surfaces, Vulnerabilities, and Mitigations

Despite robust cryptographic enforcement, AP2 deployments face emergent risks at the LLM-contextual and implementation boundary:

• Prompt Injection via LLM Agents: Attacks such as Branded Whisper and Vault Whisper manipulate internal LLM models to re-rank merchant products or to leak confidential information, bypassing mandate-level constraints by subverting agent tool prompt construction. Experimentally, prompt-injection subversion yielded 90–100% success in adversarial settings (Debi et al., 30 Jan 2026).
• Mitigation Strategies:
  • Input sanitization of all LLM-contextual fields (heuristics and learned detectors, e.g., PromptArmor).
  • Strict binding of tool calls and payment credential access to signed mandates—never executing free-text derived “intent” without cryptographic context proof.
  • Role-based, human-in-the-loop escalations for critical transactions, policy-based gating of agent privilege escalation, and context-hashing or ZK-based enforcement of prompt provenance (Debi et al., 30 Jan 2026, Hu et al., 5 Nov 2025).
• Sybil Resistance and Collusion: Absence of stake allows cheap creation of new agent IDs. Mitigation relies on non-zero cost for issuance of briefs/mandates, off-chain insurance, and reputation gating; systems such as ERC-8004 increase Sybil cost by requiring stake-per-ID (Hu et al., 5 Nov 2025).
• Hallucination and Semantic Misalignment: Agents may execute semantically policy-adherent but user-incoherent actions. Advanced defense includes policy composability, dynamic constraint checks, and TEE or oracle-based context validation (Hu et al., 5 Nov 2025).

7. Performance, Scalability, and Deployment Considerations

AP2 implementations demonstrate the following operational characteristics:

• Latency and Cost: In benchmarked agent-to-agent HTTP 402 micropayment flows, on-chain AgentCard reads average ∼50 ms, cryptographic header verification ∼100 ms, and on-chain settlement via facilitator ∼200–300 ms for aggregate latency of 350–450 ms per paid request. On public testnets, latency is dominated by block time (12–15 s typical; throughput 10–15 TPS) (Vaziry et al., 24 Jul 2025). Mandate credential cost is $0.02 and gas/ledger cost is$0.005 per transaction, ranking between purely off-chain protocols (A2A, lowest cost/latency) and fully staked on-chain protocols (ERC-8004, highest cost/latency) (Hu et al., 5 Nov 2025).
• Scalability and Interoperability: AP2 leverages standard schemas (W3C VCs, gRPC/mTLS for mandate exchange), off-chain indexing for rapid lookup, and smart contract modularity for cross-domain compatibility. Batched ZK proof aggregation and SNARK-based authenticated accumulators are recommended for large-scale deployment (Hu et al., 5 Nov 2025, Friolo et al., 2024).
• Configurable Architecture: Best practices include rotation of agent signing keys, subsidization of on-chain gas fees, integration with state channels for micropayment scalability, and stringent off-chain/on-chain separation for agent business logic (Vaziry et al., 24 Jul 2025, Acharya, 8 Nov 2025).
• Audit and Monitoring: Every economic action is auditable via Merkle proofs or event logs; reputation and stake decay over time drives incentives for continued compliance. Off-chain insurance/dispute systems mitigate residual ambiguity in fraud, latency, or semantic alignment (Hu et al., 5 Nov 2025, Acharya, 8 Nov 2025).

---

In publication, AP2 is a reference architecture for verifiable, scalable, and intent-aligned agentic payments. Its layered approach blends DLT anchoring, cryptographic mandates, ZK-based privacy, programmable constraints, and external trust signaling to enable secure, trust-minimized, and auditable economic activity between autonomous digital agents (Vaziry et al., 24 Jul 2025, Acharya, 8 Nov 2025, Hu et al., 5 Nov 2025, Friolo et al., 2024, Debi et al., 30 Jan 2026).