AP2: el Agent Payments Protocol, mandates como credenciales verificables, y cómo lo cableamos en Agent Builder
Cuando un agente autónomo llega a la página de checkout, el sistema de pago del otro lado tiene que responder tres preguntas que los rails clásicos nunca tuvieron que hacer. ¿El humano realmente autorizó esta compra? ¿El pedido del agente coincide con lo que el humano quería? Y si el deal sale mal, ¿quién es responsable — el usuario, el operador del agente, el merchant, o el banco? AP2, el Agent Payments Protocol de Google, fue anunciado el 16 de septiembre de 2025 con sesenta y pico de partners (Mastercard, American Express, PayPal, Coinbase, Adyen, Worldpay, Salesforce, ServiceNow, MetaMask, la Ethereum Foundation entre ellos), shippeó v0.2 el 28 de abril de 2026 con Human Not Present y Verifiable Intent, y fue donado a la FIDO Alliance para gobernanza comunitaria. Es el protocolo que convierte esas tres preguntas en respuestas criptográficas. Este post recorre la spec entera — los tres tipos de Mandate, el modelo de cuatro actores, los flujos Human Present y Human Not Present, la extensión x402 para crypto — y cierra con el plan concreto de ingeniería para AP2 dentro del Agent Builder de LLM4Agents.
Las tres preguntas que los pagos clásicos no pueden responder
Una transacción con tarjeta de crédito asume que un humano apretó físicamente "comprar". Las redes de tarjetas construyeron todo su framework de chargebacks, disputas y responsabilidad alrededor de esa suposición. Los estándares card-present saben quién era el humano porque vieron un chip, un PIN, o un CVC ingresado en una sesión bindeada a un dispositivo. Los estándares card-not-present saben quién era el humano porque vieron un paso 3-D Secure autenticado, un match de billing address, una decisión de scoring de fraude. En cada caso, la cadena de accountability del rail termina en un humano al que se puede contactar.
Un agente autónomo rompe esa cadena. El agente puede estar corriendo en una microVM en algún lugar donde no puede contactar al usuario. Puede estar operando contra una intent que el usuario firmó una hora, un día o un mes atrás. Puede estar combinando múltiples agentes, múltiples merchants, múltiples métodos de pago en una sola compra compuesta. Ninguna de las pruebas de intent a nivel rail — el chip, el PIN, el paso 3-D Secure — puede producirla un agente en nombre del usuario sin (a) que el agente almacene los secretos del usuario, lo cual es un desastre de seguridad, o (b) que el rail afloje sus requisitos de prueba, lo cual es un desastre de fraude.
La apuesta de AP2 es que hay una tercera opción: capturar la intent en el momento en que el usuario la tiene, firmarla criptográficamente, pasar la firma por la cadena, y dejar que cada actor downstream verifique la cadena sin nunca tener los secretos del usuario. Es el mismo truco que las Verifiable Credentials de W3C estandarizaron para documentos de identidad, aplicado a la autorización de pago. La firma es la prueba; al agente no hace falta confiarle porque la criptografía sí es confiable.
Mandates: los tres artefactos firmados
Una transacción AP2 se construye con una cadena de tres Verifiable Credentials firmadas llamadas Mandates. Cada Mandate es un documento JSON autocontenido con sujeto, emisor, claims, expiración, y una prueba criptográfica. La cadena captura el provenance completo desde "qué quería originalmente el usuario" hasta "qué se cobró realmente".
1. Intent Mandate
El Intent Mandate lo firma el usuario (o el agente del usuario actuando bajo consentimiento previo) y declara qué quiere que se haga. Es la versión criptográfica de "encontrame zapatillas blancas de running por menos de $120".
{
"@context": ["https://www.w3.org/ns/credentials/v2",
"https://ap2-protocol.org/v0.2"],
"type": ["VerifiableCredential", "AP2IntentMandate"],
"id": "urn:uuid:8a3f...e21d",
"issuer": "did:key:zUser...",
"validFrom": "2026-05-25T14:21:00Z",
"validUntil": "2026-05-26T14:21:00Z",
"credentialSubject": {
"agentDid": "did:key:zAgent...",
"description": "Zapatillas blancas de running, talle 10 US, menos de $120",
"constraints": {
"maxAmount": { "value": "120.00", "currency": "USD" },
"categories": ["footwear", "running"],
"merchantAllowList": ["did:web:merchant.example"],
"requiresHumanConfirmation": true
},
"humanPresent": true
},
"proof": { "type": "Ed25519Signature2020", "proofValue": "z3..." }
}El campo constraints es la parte que carga peso. Fija el presupuesto del agente, las categorías permitidas, los merchants permitidos, y si el usuario quiere un paso de confirmación final antes de que el agente tire del gatillo. Cualquier cosa que el usuario no pre-autorice queda no-autorizada.
2. Cart Mandate
El Cart Mandate es el momento en que la intent abstracta colapsa en un carrito concreto. Lo firma el merchant (o su agente) y contiene los ítems exactos, precios, impuestos, envío, y total que el merchant ofrece. Cuando el usuario está presente, contra-firma el Cart Mandate después de revisar — este es el checkpoint "lo que ves es lo que pagás". Cuando el usuario no está presente, el agente del usuario lo contra-firma contra los constraints del Intent Mandate.
{
"@context": ["https://www.w3.org/ns/credentials/v2",
"https://ap2-protocol.org/v0.2"],
"type": ["VerifiableCredential", "AP2CartMandate"],
"id": "urn:uuid:4b1c...f098",
"issuer": "did:web:merchant.example",
"validFrom": "2026-05-25T14:23:11Z",
"validUntil": "2026-05-25T14:38:11Z",
"credentialSubject": {
"intentMandateId": "urn:uuid:8a3f...e21d",
"lineItems": [
{ "sku": "RUN-WHT-10", "qty": 1, "price": "109.00" }
],
"tax": "9.81",
"shipping": "0.00",
"total": { "value": "118.81", "currency": "USD" },
"acceptedPaymentMethods": [
"card.visa", "card.mastercard", "x402.usdc.base"
]
},
"proof": [
{ "type": "Ed25519Signature2020", "verificationMethod": "did:web:merchant.example#sign" },
{ "type": "Ed25519Signature2020", "verificationMethod": "did:key:zUser...#sign" }
]
}La firma dual sobre el Cart Mandate es la innovación clave. El merchant firma para comprometerse al precio; el usuario (o el agente pre-autorizado del usuario) firma para comprometerse a la compra. Ambas firmas bindean al mismo artefacto. Ninguna de las partes puede reclamar después "yo nunca acepté ese carrito" porque el carrito es el carrito.
3. Payment Mandate
El Payment Mandate es la autorización final que libera los fondos. Referencia el Cart Mandate, nombra el método de pago, y contiene cualquier dato específico del rail que el Payment Service Provider necesite para liquidar.
{
"@context": ["https://www.w3.org/ns/credentials/v2",
"https://ap2-protocol.org/v0.2"],
"type": ["VerifiableCredential", "AP2PaymentMandate"],
"id": "urn:uuid:c910...d4a7",
"issuer": "did:web:credentials-provider.example",
"validFrom": "2026-05-25T14:23:47Z",
"validUntil": "2026-05-25T14:33:47Z",
"credentialSubject": {
"cartMandateId": "urn:uuid:4b1c...f098",
"paymentMethod": {
"type": "x402.usdc.base",
"network": "base-mainnet",
"payerAddress": "0x...",
"payeeAddress": "0x..."
},
"amount": { "value": "118.81", "currency": "USD" }
},
"proof": { "type": "Ed25519Signature2020", "proofValue": "z3..." }
}El firmante del Payment Mandate es el Credentials Provider — típicamente un banco, una wallet, un emisor de tarjeta, o en el caso x402 una wallet no-custodial que el usuario controla. Esta separación importa: el agente del usuario nunca ve las credenciales de pago del usuario. El Credentials Provider las tiene, firma el Payment Mandate contra un Cart Mandate ya autorizado, y entrega el artefacto firmado al PSP para liquidación.
El modelo de cuatro actores
AP2 define una descomposición de roles chica y filosa en la que todos los participantes de la transacción tienen que encajar. La confusión sobre quién hace qué fue la barrera más grande para el comercio mediado por agentes; el protocolo la resuelve nombrando los actores.
Modelo de actores AP2:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Agente del │◄───►│ Agente del │ │ Credentials│
│ Usuario │ │ Merchant │ │ Provider │
│ (LLM4Agents,│ │ (Shopify, │ │ (Banco, │
│ Gemini, │ │ PayPal, │ │ Wallet, │
│ Copilot…) │ │ Etsy…) │ │ Issuer) │
└─────┬───────┘ └─────┬───────┘ └─────┬───────┘
│ Intent │ Cart │ Payment
│ Mandate │ Mandate │ Mandate
▼ ▼ ▼
┌──────────────────────────────┐
│ PSP / Red de pago │
│ (Adyen, Stripe, Mastercard,│
│ Base RPC, Solana RPC…) │
└──────────────────────────────┘
El Agente del Usuario representa al comprador; el Agente del Merchant representa al vendedor; el Credentials Provider tiene el instrumento de pago; el PSP/Red mueve efectivamente la plata. Cada actor firma solo aquello sobre lo que tiene autoridad. El Agente del Usuario nunca firma un Payment Mandate; el Credentials Provider nunca firma un Intent Mandate; el Merchant nunca tiene las claves privadas del usuario. La separación criptográfica enforza la separación de roles que el sistema legal ya espera.
Human Present vs Human Not Present
La única decisión de diseño que le permite a AP2 funcionar sobre toda la superficie de comercio agéntico es el split explícito entre los dos flujos.
Human Present. El usuario está en el loop. Emite un Intent Mandate que no necesita pre-autorizar un monto específico porque va a firmar el Cart Mandate él mismo cuando el agente le presente el carrito. El Intent Mandate trata más sobre scope ("solo este merchant", "solo esta categoría") que sobre monto. El usuario revisa el carrito, firma, y la transacción liquida. La cadena completa captura provenance para el sistema de disputas; la firma final del usuario es la autorización vinculante.
Human Not Present. El usuario firmó un Intent Mandate antes — posiblemente mucho antes — que le dio al agente pre-autorización para actuar bajo restricciones específicas. El agente descubre un carrito que satisface los constraints, genera una contra-firma usando una clave que el usuario ya le delegó, y procede. El merchant verifica que la firma delegada del agente trazea de vuelta al Intent Mandate original del usuario, y la transacción liquida sin traer al usuario de vuelta al loop.
El feature Verifiable Intent shippeado en v0.2 (abril 2026) afila el caso Human Not Present. El Intent Mandate ahora carga un lenguaje estructurado de constraints — no solo máximos sino condicionales ("comprá solo si SKU X cae por debajo de $90 entre martes y viernes"). Esto le permite a los agentes actuar sobre mandates multi-día y multi-condición sin re-involucrar al usuario, manteniendo la pre-autorización verificable end-to-end.
Composición con A2A, MCP y x402
AP2 se construye sobre el stack agéntico existente en lugar de reemplazar ninguna de sus partes.
AP2 sobre A2A. Los Mandates se transportan como Parts de mensaje A2A de tipo data, con una URI de extensión declarando el schema AP2. La comunicación agente-a-agente que corre la negociación, la construcción del carrito y la liquidación final es A2A plano; lo único que se agrega es que algunos objetos Part cargan Mandates firmadas en lugar de JSON no estructurado.
AP2 más MCP. Las herramientas del agente — sacar precios, consultar inventario, computar envío — se invocan a través de MCP exactamente como antes. AP2 no toca la capa de tools; se sienta encima. Un agente shippeando AP2 sigue usando MCP para mirar el catálogo del merchant; la diferencia es que en el momento en que un carrito se finaliza, el agente ahora firma un Cart Mandate en lugar de hacer POST a un form HTTP.
La extensión x402 de AP2. El soporte del rail crypto dentro de AP2 es la extensión x402-sobre-AP2 que Google co-desarrolló con Coinbase, la Ethereum Foundation y MetaMask. Un Payment Mandate con paymentMethod.type = "x402.*" le dice al PSP que liquide la transacción a través del facilitator de x402 en la cadena nombrada. La cadena de Mandates en sí es idéntica; solo cambia la etapa final de liquidación. Este es el camino que el comercio nativo agente-a-agente va a tomar mayormente, porque no requiere que ninguno de los lados tenga una tarjeta o se integre con un acquirer tradicional.
La composición es el punto. AP2 no inventa una nueva capa RPC (A2A ya lo hizo), una nueva capa de tools (MCP ya lo hizo), ni un nuevo rail de pago (x402 y las redes de tarjetas existentes ya lo hicieron). Agrega la pieza faltante: la cadena criptográfica de autorización que prueba que un humano realmente acordó, y en qué medida.
La historia de las disputas
La razón por la que Mastercard, American Express, PayPal y Adyen firmaron es que AP2 les da algo que su maquinaria existente de chargebacks no tenía: una cadena de evidencia no-repudiable que sobrevive la intermediación del agente.
Cuando un cliente disputa una transacción mediada por AP2, el merchant puede producir tres artefactos firmados: el Intent Mandate (mostrando que el usuario pre-autorizó una categoría y límites), el Cart Mandate (mostrando que el usuario o su agente delegado firmó el carrito exacto), y el Payment Mandate (mostrando que el Credentials Provider liberó los fondos contra ese carrito). Cada eslabón de la cadena es criptográficamente verificable; ningún eslabón depende de un log de servidor que alguien pudo editar después; cada artefacto carga su propia expiración y prueba de frescura.
Si la disputa pivotea sobre "el agente hizo algo que yo nunca autoricé", el campo constraints del Intent Mandate es la evidencia. Si pivotea sobre "el merchant cobró algo distinto del carrito que aprobé", la doble firma del Cart Mandate es la evidencia. Si pivotea sobre "se cobró la cuenta equivocada", la firma del Credentials Provider sobre el Payment Mandate es la evidencia. La primera vez que las redes de tarjetas tienen un audit trail que cruza los bordes de los agentes.
El protocolo no elimina las disputas — nunca podría — pero las desplaza desde "tenemos que averiguar qué pasó" hacia "tenemos que interpretar qué muestra la evidencia firmada". Es el mismo desplazamiento que TLS hizo para el fraude web hace veinte años, y es la precondición para que los rails permitan comercio de agentes a gran escala.
Cómo LLM4Agents cablea AP2 en Agent Builder
Nuestro plan para AP2 dentro de Agent Builder sigue el patrón de integración que usamos para los otros protocolos deAI: shippear defaults sensatos, exponer los escape hatches correctos, y hacer que la composición con A2A/MCP/x402/ERC-8004 sea el camino de menor resistencia.
Firma de Mandates como primitiva de primera clase del SDK. Agent Builder expone un namespace mandates que envuelve el stack de W3C VC. Los operadores no escriben el JSON-LD; escriben lógica de negocio. El SDK genera la credencial, adjunta la prueba, y devuelve un artefacto serializado listo para meter en una Part de mensaje A2A.
// SDK de Agent Builder — namespace AP2
const intent = await ap2.intent.sign({
description: "Zapatillas blancas de running, talle 10 US, menos de $120",
constraints: {
maxAmount: { value: "120.00", currency: "USD" },
categories: ["footwear", "running"],
requiresHumanConfirmation: true
},
validUntil: "PT24H" // duración ISO 8601 abreviada
})
await a2a.sendMessage(merchantAgent, {
skill: "checkout",
parts: [
{ type: "data", data: { ap2: { intentMandate: intent } } }
]
})La gestión de claves se delega a la wallet. Agent Builder nunca tiene la clave de firma del usuario. Para pagos tradicionales, el Credentials Provider (un emisor de tarjeta, un banco, una credencial efímera emitida por Stripe) la tiene. Para pagos por la ruta x402, la wallet no-custodial del usuario la tiene. Agent Builder coordina el flujo de firma pero no ve el secreto. La wallet devuelve el Mandate firmado.
Mandates persistidas en ERC-8004. Por cada transacción que el agente completa, el hash de la cadena de Mandates se postea en la entrada del agente en la Validation Registry de ERC-8004. Esto le da a cada agente construido en Agent Builder una historia tamper-proof y on-chain de los pagos autorizados a través suyo. Las contrapartes que quieran contratar al agente por primera vez pueden ver no solo el score de reputación, sino el conteo verificable de cuántas transacciones mediadas por AP2 completó bajo constraints atestiguados.
UI de revisión de Cart Mandate por defecto. Para los flujos Human Present, Agent Builder shippea un componente estándar de revisión de carrito (web, mobile, Telegram, Discord — donde sea que el usuario corra su agente) que renderea el JSON del Cart Mandate como un resumen humano-amigable y recolecta la firma del usuario. Los operadores pueden reemplazar la UI pero el contrato del protocolo es fijo: hasta que el usuario firme, ningún Cart Mandate se contra-firma.
Políticas de constraints como skills del agente. Los agentes generados por Agent Builder pueden declarar constraints AP2 como skills en la Agent Card A2A. Un agente "renovación de suscripción" declara un template de Intent Mandate con recurrencia mensual; un agente "cazador de ofertas" declara un template de Verifiable Intent con cláusulas condicionales. Las contrapartes navegando al agente por su Agent Card ven los constraints AP2 bajo los que el agente está dispuesto a operar, antes de que empiece la primera conversación.
x402 como rail crypto por defecto. Cuando un agente transacciona a través del marketplace de LLM4Agents, el Payment Mandate AP2 defaultea a x402.usdc.base (USDC sobre Base por las fees bajas, liquidación amigable a Coinbase) con Solana y Polygon como fallbacks. Los operadores pueden fijar otra cadena; no pueden fijar una liquidación non-AP2, porque el marketplace va a rechazar cualquier pago sin Mandate.
Lo que todavía tiene que madurar
AP2 v0.2 está production-ready para sus flujos core. La crítica honesta sigue las brechas que el trabajo v0.2-a-v1.0 tiene que cerrar.
El ecosistema W3C VC en sí todavía está madurando. La suite Ed25519Signature2020 está bien soportada, pero los formatos VC basados en JWT — preferidos por algunos miembros de FIDO por interop con rails de identidad existentes — están llegando más lentamente. AP2 probablemente va a tener que soportar ambos formatos de proof intercambiablemente, de la misma forma en que A2A tuvo que soportar bindings JSON-RPC y gRPC.
La revocación de Mandates necesita primitivas más filosas. Un usuario que delega un Intent Mandate de seis meses y cambia de opinión necesita una forma rápida y confiable de revocarlo antes de que el agente actúe de nuevo. La spec v0.2 describe la revocación conceptualmente pero deja el diseño del registry a los implementadores; la próxima versión debería estandarizar un endpoint de status de revocación análogo a OCSP para certificados TLS.
La composición cross-Mandate para deals multi-parte — un solo usuario pagando a múltiples merchants en una vuelta de compras, o una orden de procurement B2B que alinea decenas de proveedores — actualmente se expresa como múltiples cadenas paralelas de Mandates. Una extensión de bundling permitiría que un solo Intent Mandate cubra el flujo multi-parte sin forzar al agente del usuario a emitir N Intents, ni a cada merchant a firmar su tajada, ni al usuario a trackearlos por separado.
Y el traspaso a la FIDO Alliance, aunque sea la jugada de gobernanza correcta, va a ralentizar la cadencia de cambios breaking — apropiado para un protocolo de pagos, doloroso para plataformas de agentes early-adopter que todavía quieren evolucionar rápido. Esperamos que la spec aterrice en v1.0 en algún punto a fines de 2026, después de lo cual el bar para cambios breaking será apropiadamente alto.
Cierre
El stack agéntico a mitad de 2026 finalmente tiene las cuatro capas que necesita. MCP estandariza el borde agente-a-herramientas. A2A estandariza el borde agente-a-agente. AP2 estandariza el borde autorización-y-pago. ERC-8004 estandariza el borde identidad-y-reputación. Cada protocolo es propiedad de una casa neutral (Linux Foundation, FIDO Alliance, Ethereum Foundation), cada uno es componible con los demás a través de seams bien definidos, y ninguno encierra al operador en un vendor único.
AP2 es la capa que, hasta fines de 2025, faltaba — y es la que, por su ausencia, mantuvo al comercio agéntico atascado en modo piloto durante la primera mitad de 2026. Con mandates como Verifiable Credentials y el traspaso de gobernanza a FIDO, las redes de rails tienen lo que necesitan para underwrittear transacciones mediadas por agentes a escala. Nuestro trabajo dentro de Agent Builder es hacer que usarlo sea el default en lugar de un opt-in, y hacer que las garantías criptográficas sean visibles para el humano en el loop sin descargar JSON-LD en su pantalla.
La spec está en goo.gle/ap2. Las implementaciones de referencia están públicas en Python, TypeScript, Kotlin y Go. Si estás construyendo cualquier agente cuya task exitosa termine con plata cambiando de manos, AP2 pertenece a tu diagrama de stack al lado de A2A y MCP — y dentro de Agent Builder, ya lo está.