AP2: El Protocolo de Pagos de Agentes

Este es un análisis técnico profundo de AP2 v0.2, el sistema de mandatos criptográficos detrás de los pagos de agentes autónomos. Lo escribí después de construir una demostración real en Camunda 8, y verifiqué cada afirmación con la especificación en ap2-protocol.org, no con la cobertura de prensa. La mayoría de los artículos de la semana de lanzamiento utilizan terminología que la especificación actual ya ha reemplazado. Lo señalaré donde sea relevante.

El problema que resuelve

“¿Le darías tu tarjeta de crédito a una IA?” Esa es la pregunta que me propuse responder para el EP 03 de Agents, Orchestrated. El protocolo que la responde correctamente es AP2.

Un agente que puede gastar dinero es fundamentalmente diferente de un agente que puede responder preguntas. Cuando un agente llama a una API de búsqueda y se equivoca, obtienes un mal resultado. Cuando llama a una API de pago y se equivoca, pierdes dinero.

La respuesta tradicional es: exigir la presencia humana en el momento del pago. Haz clic en Aprobar. Introduce la OTP. Lo cual está bien, hasta que se supone que el agente debe comprar en el momento en que bajan los precios de las entradas de la FIFA a las 2 de la mañana mientras duermes.

AP2 resuelve un problema específico: ¿cómo delega un humano la autoridad de gasto a un agente de una manera que esté criptográficamente limitada, sea auditable por cada parte en la cadena y sea exigible sin comunicarse con ninguna autoridad central?

La respuesta son los mandatos. Ese es todo el protocolo.

Qué es AP2: datos clave

AP2 = Agent Payments Protocol. El estándar abierto de Google para pagos iniciados por agentes, anunciado el 16 de septiembre de 2025, con más de 60 socios de lanzamiento, incluyendo Mastercard, PayPal, American Express, Coinbase y Salesforce.

Dato	Detalle
Versión actual	v0.2, lanzada en abril de 2026 (GitHub: google-agentic-commerce/AP2)
Socios de lanzamiento	Más de 60 (Mastercard, PayPal, AmEx, Coinbase, Salesforce)
Estandarización	FIDO Alliance (Google donó AP2 al Agentic Auth + Payments TWG)
Implementaciones de referencia	5 lenguajes: Python, Go, TypeScript, Kotlin, Android

Cosas clave que hay que saber de antemano:

• AP2 es una extensión del protocolo A2A (Agent-to-Agent, el estándar de mensajería entre pares de Google para agentes). Añade semántica de mandato de pago sobre el transporte de A2A.
• Se integra con el Universal Commerce Protocol (UCP) como la capa de comercio/pago.
• Admite x402 / stablecoins (USDC) como un medio de pago de primera clase, no como una ocurrencia tardía. Esto es importante para microtransacciones donde el intercambio de tarjetas (0,50 $ a 0,80 $) excede el valor de la transacción.
• La fuente de verdad de la especificación es ap2-protocol.org, no la cobertura de prensa. La mayoría de los artículos de septiembre de 2025 utilizan terminología obsoleta. Lo señalaré donde sea relevante.

Dónde se ubica AP2 en la pila

Esto es lo que me hubiera gustado que alguien me hubiera dibujado claramente el primer día. La pila de comercio agéntico tiene cinco capas distintas: diferentes protocolos, diferentes organizaciones, diferentes problemas que se resuelven.

Capa	Protocolo	Qué hace	Responsable
1	MCP	Model Context Protocol. Descubrimiento y herramientas: cómo los LLM descubren e invocan capacidades externas	Anthropic
2	A2A	Agent-to-Agent Protocol. Transporte: mensajería HTTP entre pares entre roles de agente a través del descubrimiento de AgentCard	Google
3	AP2 (usted está aquí)	Autorización de pago: cadena de mandatos firmada criptográficamente, SD-JWT, ECDSA P-256, W3C Verifiable Credentials	Google / FIDO
4	ACP / UCP	Puntos finales HTTP de pago, ensamblaje de carrito, semántica de cumplimiento de pedidos	Especificación abierta
5	Tarjetas, FedNow, x402	Medios de liquidación: Mastercard, Visa, UPI, Pix, stablecoins USDC	Redes

MCP define lo que un agente puede leer y llamar. ACP define cómo compra un agente. AP2 define cómo la intención del usuario y el cargo del comerciante son atestiguados criptográficamente.

Estas capas se componen. Usas MCP para dar herramientas a un agente. Esas herramientas invocan puntos finales A2A para enviar mensajes a otros agentes. AP2 proporciona las credenciales de autorización firmadas que viajan con esos mensajes. ACP/UCP define la API de pago que expone el comerciante. Los medios liquidan el dinero.

Figura 1: La pila de comercio agéntico de cinco capas. AP2 se ubica en la Capa 3, entre el transporte y la liquidación, proporcionando la cadena de autorización criptográfica.

Las cuatro partes

AP2 define cuatro roles con nombre. Cada transacción involucra algunos o todos ellos:

Rol	Qué hacen	Ejemplos del mundo real
Agente de Compras	Monitorea precios, toma decisiones, actúa en nombre del usuario dentro de las restricciones del mandato	Agentes de compras de Claude Sonnet, Gemini, cualquier agente LLM
Agente Comerciante	Expone un punto final de carrito compatible con AP2, verifica Checkout Mandates, cumple pedidos	TicketVault, cualquier backend de comerciante compatible con ACP
Proveedor de Credenciales	Verifica ambos mandatos, emite credenciales de pago al Agente de Compras	Mastercard Agent Pay, PayPal, Visa
Procesador de Pagos	Liquida la transacción contra el instrumento de financiación	Redes de tarjetas, FedNow, Coinbase (x402)

La Trusted Surface es un concepto especial: el cliente (billetera o aplicación) compatible con AP2 donde el usuario firma los mandatos. Piense en ella como la autoridad de firma digital del usuario. Contiene la clave privada ECDSA del usuario y produce los mandatos abiertos antes de que el Agente de Compras actúe de forma autónoma.

El sistema de mandatos: el mecanismo central

Nota terminológica: muchos artículos todavía usan el marco de tres mandatos de la semana de lanzamiento (Intent Mandate, Cart Mandate, Payment Mandate). La especificación v0.2 reestructura esto en dos tipos de mandatos con dos etapas cada uno. El marco antiguo está obsoleto; use la terminología v0.2.

Dos tipos de mandatos

Mandato	Compartido con	Qué captura
Checkout Mandate	Agente Comerciante	Autoridad para comprar, alcance del artículo, precio máximo, lista blanca de comerciantes, TTL
Payment Mandate	Proveedor de Credenciales / Red	Autoridad para cargar, token del instrumento de financiación, límite de importe, restricciones de categoría

Etapas abiertas vs. cerradas

La distinción entre abierto y cerrado es todo el mecanismo para los pagos sin presencia humana.

	Etapa abierta	Etapa cerrada
Cuándo se crea	En la configuración del mandato, con presencia humana	En el momento de la compra, sin presencia humana
Firmado por	Clave de la billetera del usuario (ECDSA)	Clave del agente (ECDSA)
Contenido	Restricciones, alcance, TTL, listas blancas	Carrito específico / importe exacto, hash de pago
Propósito	Autoridad permanente	Prueba específica de la transacción

Ejemplo concreto: escenario de entradas de la FIFA

Checkout Mandate, abierto: “Autorizo a mi agente a comprar hasta 2 entradas de Categoría 3 de la FIFA en TicketVault, máximo 1.500 $ cada una, expira en 24h.”

Checkout Mandate, cerrado: “Estoy comprando 2 entradas de Categoría 3 a 1.350 $ cada una, total 2.700 $, checkout_hash: 0xABC...”

El Payment Mandate cerrado solo puede crearse después de que el Checkout Mandate esté cerrado. Debe incluir el checkout_hash del Checkout cerrado. La especificación impone esta dependencia secuencial.

Figura 2: Ciclo de vida del mandato. Los mandatos abiertos son firmados por el usuario en la configuración. Los mandatos cerrados son firmados por el agente en el momento de la compra. El Payment Mandate requiere el hash de Checkout del Checkout Mandate cerrado.

Cómo se ve un mandato

// Simplified mandate JSON (encoded as SD-JWT in practice)
{
  "id": "mandate_7A3F2026",
  "type": "checkout.open",
  "vct": "mandate.checkout.1",       // schema version, must match exactly
  "user_did": "did:key:z6Mk...",     // DID of user's wallet key
  "agent_did": "did:key:z6Mk...",    // DID of shopping agent
  "constraints": {
    "item_scope": "event-tickets",
    "max_unit_price": 1500,
    "max_quantity": 2,
    "currency": "USD",
    "merchant_allowlist": ["ticketvault.com"],
    "ttl": "2026-07-12T00:00:00Z"
  },
  "signature": "ECDSA_P256_sig_by_user_key..."  // MUST be ECDSA, NOT Ed25519
}

La criptografía: por qué esto es un protocolo, no solo un registro de base de datos

Muchas soluciones de “pagos agénticos” son solo registros de bases de datos: el usuario marca una casilla, la aplicación escribe authorized=true, el agente lo lee. Eso se rompe en el momento en que tienes múltiples partes que no confían inherentemente entre sí.

Los mandatos AP2 son SD-JWTs (Selective Disclosure JSON Web Tokens) firmados con ECDSA P-256. La especificación es explícita: el JWT de Checkout DEBE firmarse usando ECDSA y NO DEBE usar Ed25519.

¿Por qué ECDSA, no Ed25519?

Esto es sutil y vale la pena entenderlo. Ed25519 es determinista: dada la misma mensaje y clave privada, siempre produce la misma firma. Eso significa que dos mandatos idénticos producen el mismo hash de firma. Un atacante que recopila firmas a lo largo del tiempo puede construir una tabla arcoíris contra la afirmación checkout_hash incrustada en el mandato. ECDSA incluye un nonce aleatorio por operación de firma, por lo que cada firma es única incluso para contenidos de mandato idénticos. No es posible un ataque de tabla arcoíris.

La fórmula criptográfica

// From the CSA security framework for AP2
Sig_U(M) = ECDSA.Sign(K_U, Hash(M))

// Verification: any party can run this independently
Verify(M, Sig, PubKey_U) → boolean

// No API call to any central server required
// The credential is self-contained proof

Las cinco garantías criptográficas

1. Evidencia de manipulación: cualquier modificación del mandato después de la firma rompe la firma ECDSA. El comerciante o el proveedor de credenciales lo rechazarán.
2. No repudio: el usuario no puede negar haber firmado el mandato abierto. Su clave privada es la autoridad de firma.
3. Portabilidad: cada parte de la cadena verifica de forma independiente utilizando la clave pública del usuario (a través de DID). Sin autoridad central. Sin comunicación con una autoridad central.
4. Aplicación del alcance: el mandato cerrado debe satisfacer todas las restricciones del mandato abierto o la verificación fallará. El agente no puede exceder el alcance preautorizado por el usuario.
5. Divulgación selectiva: SD-JWT permite a un comerciante que verifica un Checkout Mandate ver los campos de artículo y precio sin ver el token del instrumento de financiación. Los campos se revelan selectivamente por parte.

Los campos de carga útil sensibles (como los tokens de instrumentos de financiación) se cifran con AES-GCM-256 antes de incrustarlos en el JWT. Para transacciones de alto valor, la especificación recomienda la firma de claves respaldada por hardware (TPM/HSM).

AP2 utiliza Decentralized Identifiers (DIDs) para el descubrimiento de claves del emisor: sin autoridad de certificación, sin jerarquía PKI en la que confiar. La verificación es puramente criptográfica.

Modelo de amenazas

AP2 utiliza STRIDE para su modelo de amenazas, extendido por el marco MAESTRO para ecosistemas multiagente. Vale la pena conocerlo porque muestra exactamente lo que AP2 fue diseñado para contrarrestar.

Amenaza (STRIDE)	Ataque	Mitigación de AP2
Suplantación	Firmas de mandatos falsificadas que reclaman autorización falsa	Verificación PKI basada en DID, claves respaldadas por HSM
Manipulación	Contenido del mandato alterado en tránsito (cambiar precio, alcance)	La firma ECDSA se rompe con cualquier modificación, TLS 1.3
Repudio	“Nunca autoricé esta compra”	Firma ECDSA no repudiable en mandato abierto más registro de auditoría
Divulgación de información	Instrumento de pago expuesto al comerciante	AES-GCM-256 en campos sensibles, divulgación selectiva SD-JWT
Elevación	El agente excede el alcance del mandato (compra algo no autorizado)	Restricciones del mandato abierto verificadas criptográficamente en el mandato cerrado
Fraude por alucinación	El LLM compra algo incorrecto debido a un error del modelo	Todas las compras ancladas a la intención firmada por el usuario, no a la salida probabilística del modelo
Coerción del agente	El comerciante engaña al agente para que compre fuera del mandato	Verificación de comerciante basada en DID más merchant_allowlist en el mandato abierto

MAESTRO extiende esto a amenazas multiagente emergentes: envenenamiento del modelo, secuestro de flujo de trabajo, colusión del ecosistema. Para transacciones de alto valor, la especificación recomienda requisitos de consenso multiagente antes del cierre del mandato.

Los flujos: con presencia humana y sin presencia humana

Flujo con presencia humana

El caso más simple. El usuario está frente al teclado cuando se realiza el pago. La Trusted Surface presenta el carrito específico al usuario para su firma antes de cerrar los mandatos.

1. El Agente de Compras ensambla el carrito en el Comerciante a través del punto final ACP
2. El agente presenta el carrito más los mandatos abiertos a la Trusted Surface (billetera o aplicación del usuario)
3. El usuario revisa y firma, produciendo el Checkout Mandate cerrado (firmado por el usuario, carrito específico)
4. El usuario firma el Payment Mandate cerrado (hace referencia al hash de Checkout)
5. El agente presenta ambos mandatos cerrados al Proveedor de Credenciales
6. El Proveedor de Credenciales verifica y emite una credencial de pago
7. El agente completa el pago en el Comerciante con la credencial. Sigue la liquidación.

Flujo sin presencia humana (la característica principal de v0.2)

Este es el que importa para el comercio agéntico. El usuario estableció restricciones de antemano; el agente actúa de forma autónoma cuando se activa el disparador, posiblemente horas o días después.

El Paso 0 lo es todo. La fase de configuración es cuando el humano está presente. Después de eso, el agente actúa de forma totalmente autónoma. La criptografía impone el límite, no un humano que aprueba cada transacción.

Configuración (humano presente, una vez): el usuario firma un Checkout Mandate abierto (restricciones, TTL, alcance del comerciante) más un Payment Mandate abierto (instrumento, límite de importe). Ambos son almacenados por el Agente de Compras / Trusted Surface.

… pasa el tiempo. El usuario se va a dormir. El precio baja a las 2 de la mañana. Se activa el disparador …

1. El Agente de Compras detecta la condición de activación (precio igual o inferior al objetivo)
2. El agente consulta al Comerciante y recibe un Cart Mandate (firmado por el comerciante, SKU y precio específicos)
3. El agente verifica que el carrito satisface todas las restricciones del Checkout Mandate abierto (precio igual o inferior al máximo, comerciante en la lista blanca, TTL no caducado)
4. El agente firma el Checkout Mandate cerrado (clave del agente, carrito específico, checkout_hash)
5. El agente presenta el Checkout Mandate cerrado al Comerciante, que verifica tanto las firmas abiertas (usuario) como cerradas (agente)
6. El agente firma el Payment Mandate cerrado (hace referencia al checkout_hash del paso 4)
7. El agente presenta ambos mandatos al Proveedor de Credenciales, que verifica la cadena completa
8. El Proveedor de Credenciales emite la credencial de pago
9. El agente completa el pago en el Comerciante con la credencial. Se realiza la liquidación; el registro de auditoría está completo.

Figura 3: Flujo sin presencia humana. Cuatro partes, dos tipos de mandatos, nueve pasos numerados. Toda la cadena está criptográficamente vinculada.

Cómo se conecta con el comerciante: no es MCP

La pregunta que me hacía al principio: ¿cómo llega realmente el mandato de mi agente a TicketVault?

La respuesta: a través de llamadas HTTP A2A, no MCP.

MCP es la capa de herramientas y contexto. Es cómo Claude (o cualquier LLM) obtiene acceso a search_inventory o create_mandate como herramientas invocables. Lo que el LLM hace con esas herramientas (los mensajes entre el Agente de Compras y el Agente Comerciante) es A2A. Las credenciales del mandato son la carga útil, no los resultados de la herramienta MCP.

MCP define lo que un agente puede leer y llamar. Los mandatos se transportan junto con las llamadas A2A como artefactos de evidencia, no son generados por MCP mismo.

En una implementación real de AP2, el flujo a TicketVault sería:

1. El Agente de Compras envía un POST de un Checkout Mandate firmado (SD-JWT) al punto final A2A del comerciante AP2 de TicketVault
2. El agente comerciante de TicketVault valida: verificación de firma, luego verificación de restricciones, luego coincidencia de hash de pago
3. TicketVault devuelve un Recibo de Pago (firmado por el comerciante)
4. El Agente de Compras lleva ese recibo más el Payment Mandate al punto final A2A del Proveedor de Credenciales

En nuestra demostración, simulamos esto dentro de un único BFF de Node.js: los workers de Camunda desempeñan los roles de agente distribuidos, y SSE reemplaza las llamadas A2A entre ellos. La mecánica es real; la distribución es simulada. Una simplificación honesta para una demostración.

Medios de pago: deliberadamente multicanal

AP2 no elige un ganador entre los medios de pago con tarjeta y las criptomonedas. Define puntos de extensión para todos ellos:

Medio	Cómo funciona en AP2	Mejor para
Redes de tarjetas	Mastercard Agent Pay, Visa: credenciales de tarjeta tokenizadas emitidas por el Proveedor de Credenciales	Compras de consumo de alto valor, relaciones bancarias existentes
Pagos en tiempo real	FedNow, UPI, Pix: credenciales de transferencia bancaria	B2B de alto valor, mercados donde domina la transferencia bancaria en tiempo real
x402 / USDC	El agente posee una billetera inteligente directamente, USDC en Base/Ethereum, liquidación instantánea	Microtransacciones, pagos de API a API, sin costo mínimo de intercambio

x402 es particularmente interesante para las microtransacciones. Los costos de intercambio de tarjetas tradicionales son de 0,50 $ a 0,80 $ por transacción, independientemente del importe. Un agente que paga 0,01 $ por una llamada a una API no puede usar los medios de pago con tarjeta de forma económica. x402 más las stablecoins resuelven esto: el agente posee USDC, paga directamente en la cadena y puede usar un depósito en garantía programable para compromisos de varios pasos.

Tres implementaciones públicas de AP2 con nombre a partir de abril de 2026: la billetera de PayPal más el Agente de Comercio Conversacional de Google Cloud, el piloto de Mastercard Agent Pay dentro de PayPal y la extensión A2A x402 para pagos con criptomonedas.

Cómo nuestra demostración se mapea a AP2 real

Construí una demostración con Camunda 8 y con forma de AP2 para el EP 03 de Agents, Orchestrated. Aquí está el mapeo honesto:

Nuestra demostración (BFF de Camunda 8)	AP2 real
mandateService.js crea y firma JSON de mandato (ES256)	Trusted Surface más Agente de Compras tienen mandatos abiertos adecuados firmados por el usuario con gestión de claves DID real
Política de gasto de Camunda DMN (HITL, límite, velocidad)	Incrustada en las restricciones del mandato abierto más el motor de políticas del proveedor de credenciales
Los eventos SSE impulsan el sitio del comerciante TicketVault	El Agente de Compras envía un POST del Checkout Mandate al punto final A2A del Agente Comerciante (HTTP estándar)
Worker de Camunda merchant.completeCheckout	Binario de Agente Comerciante distinto que verifica mandatos y ejecuta el proceso de pago ACP
Worker de Camunda credentials.issueToken	Agente Proveedor de Credenciales que verifica el par de mandatos y emite la credencial de pago
Tarea de usuario de Zeebe task_desk_approval (HITL)	AP2 no prescribe la escalada de HITL; Camunda añade esto como gobernanza sobre el protocolo

La capa de Camunda es donde añadimos la gobernanza que AP2 en sí mismo no exige: la política de gasto de DMN, la escalada de humano en el bucle (HITL) al 95% del límite, el registro de auditoría completo del proceso. AP2 es el protocolo de autorización. Camunda es el orquestador de gobernanza que lo complementa.

Qué añadió la v0.2 (abril de 2026)

La característica principal es el pago sin presencia humana: los agentes pueden ejecutar transacciones preautorizadas sin una solicitud de consentimiento interactiva, utilizando el par de mandatos abierto/cerrado.

• Reestructurado de tres tipos de mandatos (Intent/Cart/Payment) a dos (Checkout/Payment) con etapas abiertas y cerradas
• Formalizó SD-JWT como el estándar de codificación de mandatos
• Añadió explícitamente en la especificación la distinción ECDSA DEBE / Ed25519 NO DEBE
• Introdujo soporte oficial para los medios de pago x402 / stablecoin como un tipo de pago de primera clase
• Implementaciones de referencia en Python, Go, TypeScript, Kotlin y Android
• Estandarización de FIDO Alliance a través del Grupo de Trabajo Técnico de Autenticación y Pagos Agénticos

La versión de un párrafo

AP2 es el protocolo abierto de Google para pagos iniciados por agentes. Resuelve bien un problema: ¿cómo delega un humano una autoridad de gasto limitada a un agente de una manera que cada parte en la cadena de transacciones pueda verificar de forma independiente, sin confiar el uno en el otro ni comunicarse con una autoridad central? Lo hace a través de un sistema de dos mandatos, un Checkout Mandate (agente a comerciante) y un Payment Mandate (agente a proveedor de credenciales), donde cada mandato tiene una etapa abierta (el usuario pre-firma las restricciones) y una etapa cerrada (el agente firma la transacción específica). Las credenciales son SD-JWTs firmados con ECDSA P-256, lo que las hace con evidencia de manipulación y portátiles. AP2 se ubica en la capa de autorización entre el protocolo de transporte A2A y la capa de pago ACP/UCP. No es MCP, y no es una pasarela de pago. Funciona en medios de pago con tarjeta, pagos en tiempo real y stablecoins. El escenario principal de la v0.2 es el pago sin presencia humana: el agente actúa de forma autónoma mientras el usuario duerme, limitado por las restricciones criptográficas que estableció de antemano.

La autonomía es un requisito mínimo. La ventaja competitiva es todo lo que rodea al agente.

Referencias

• Especificación AP2: ap2-protocol.org (fuente de verdad para tipos de mandatos, codificación SD-JWT, requisitos ECDSA, roles de las partes)
• Google Cloud: Anuncio de AP2 (contexto de lanzamiento, más de 60 socios, anuncio de donación a FIDO Alliance)
• GitHub de AP2: google-agentic-commerce/AP2 (implementaciones de referencia en Python, Go, TypeScript, Kotlin, Android, además de escenarios ejecutables)
• Cloud Security Alliance: Uso seguro de AP2 (modelo de amenazas STRIDE, fórmula ECDSA P-256, marco MAESTRO, AES-GCM-256)
• ACP vs AP2 vs MCP: Comparación de la pila de protocolos (desglose capa por capa de la pila de comercio agéntico)
• Eco: AP2 v0.2 Explicado (reestructuración de mandatos v0.2, flujo sin presencia humana, DIDs para el descubrimiento de claves)
• Cobo Agentic Wallet: Guía completa de AP2 (detalles de x402, medios de pago con stablecoins, integración de billetera multipartita)
• UCP: Extensión de mandatos AP2 (cómo AP2 se integra con el Universal Commerce Protocol en la capa de pago)
• Google Codelabs: Comercio seguro de agentes con AP2 y UCP (implementación práctica contra el ADK oficial de Google)
• arXiv: Verificación en tiempo de ejecución de confianza cero para AP2 (tratamiento académico de ataques de repetición y fallos de vinculación de contexto en AP2)
• AP2: Perspectiva de la UE (contexto regulatorio y de estandarización europeo para pagos agénticos)
• Guía técnica de AP2: Medium / Vishal Mysore (recorrido de implementación con ejemplos de código)