Pagos de agentes: mandatos, no confianza

La verificación de presupuesto está dentro del modelo

¿Le darías tu tarjeta de crédito a una IA? Yo lo hice, para este episodio. Lo interesante no es que funcionara. Es el protocolo, y la capa de gobernanza, lo que impidió que gastara demasiado.

Este es el problema con el que me encuentro constantemente. La mayoría de los enfoques de pago agenticos integran la verificación de presupuesto dentro del LLM: un prompt del sistema que dice “no gastes más de $X”. Esto es estructuralmente lo mismo que pedirle a alguien que haga cumplir su propio límite de gasto. El modelo que decide comprar es el modelo que verifica si debe hacerlo. Cuando esos son el mismo componente, no tienes un control. Tienes una sugerencia.

Ahora existe un protocolo abierto destinado exactamente a este problema: AP2, el Agent Payments Protocol v0.2, creado por el equipo A2A de Google y donado a la FIDO Alliance. La acción principal es simple: el mandato reside fuera del agente. Es externo, firmado criptográficamente, y el agente no puede anularlo. El agente opera dentro de un límite que no estableció y no puede reestablecer.

AP2 define una cadena de mandatos, y la cadena es el punto clave: Agente de Compras, Checkout Mandate, Agente Comercial, Payment Mandate, Proveedor de Credenciales, Procesador de Pagos. Cada salto es verificable. Ningún salto puede omitirse. Un pago solo ocurre cuando toda la cadena se valida.

El escenario: entradas para los cuartos de final de la FIFA 2026

Los protocolos abstractos necesitan una compra concreta, por lo que la demostración es un conserje de compras para el consumidor con un encargo estricto. El usuario firma un mandato: 2 entradas de Categoría 3 para un cuarto de final de la FIFA 2026, por menos de $1,500 cada una, con un tope máximo de $3,200 en total. El agente monitorea TicketVault, un mercado de entradas simulado, durante la noche. No hay ningún humano presente.

Cuando el precio baja, una política de gasto DMN evalúa el carrito en una Tarea de Regla de Negocio de Camunda. Esa evaluación ocurre fuera del modelo, nativamente en Camunda, y su resultado determina todo lo que sigue. Construí tres rutas a través de la misma capa de gobernanza:

Ruta	Disparador	Resultado DMN	Resultado
Dorada	El precio baja a $1,350, carrito $2,700	APPROVE	Recibo por $2,700, totalmente autónomo
HITL	El precio baja a $1,560, carrito $3,120 (97.5% del tope)	HITL_REQUIRED	Aprobación del Departamento de Pagos antes de la compra
Incumplimiento de mandato	Compra propuesta de $3,500 excede el tope de $3,200	DECLINE	Rechazado automáticamente antes de que llegue al procesador

La ruta dorada es la demostración que todos quieren ver: el precio baja a las 3 a.m., el agente compra, un recibo espera por la mañana. Las otras dos rutas son el producto. Un carrito al 97.5% del tope no se aprueba por un tecnicismo; activa a un humano en el Departamento de Pagos. Y una compra por encima del tope no se reduce con un prompt inteligente; es rechazada por una tabla de reglas antes de que el procesador de pagos se entere.

La capa de gobernanza

La política de gasto DMN consta de cinco reglas, y me gusta que sea sencilla: una verificación de límite, un disparador de límite cercano que redirige cualquier cosa por encima del 95% del mandato a revisión humana, una lista blanca de instrumentos de pago, un límite de velocidad y una aprobación general. Se ejecuta en Camunda como una Tarea de Regla de Negocio, no dentro del LLM. El agente nunca ve la política como un texto que podría racionalizar. Ve un resultado de decisión.

La tercera capa es el registro de auditoría, y se obtiene automáticamente con la arquitectura. Cada salto de autorización reside en Camunda Operate: mandato emitido, precio capturado, DMN evaluado, credenciales emitidas, recibo almacenado. Cada decisión, permanentemente, como una instancia de proceso que puedes abrir y reproducir. Nadie escribió código de registro para obtener esto.

El LLM propone. El DMN dispone. Si tu política de gasto puede ser alterada por un párrafo bien elaborado, no es una política de gasto.

Mandatos, no confianza

AP2 v0.2 define dos tipos de mandato, y cada uno tiene una etapa abierta y una etapa cerrada. Abierta significa que el usuario pre-firma las restricciones. Cerrada significa que el agente firma la transacción específica que ocurrió dentro de ellas.

El Checkout Mandate. El usuario pre-firma el alcance del artículo, el precio máximo, un TTL y una lista blanca de comerciantes. En el momento de la compra, el agente lo cierra con el carrito específico: SKU, precio, hash de compra. El comerciante verifica el mandato cerrado antes de procesar nada.

El Payment Mandate. El usuario pre-autoriza el instrumento de financiación: la fuente, la cantidad máxima, las restricciones de categoría. El agente lo cierra con la cantidad exacta y el hash de compra. El Proveedor de Credenciales verifica ambos mandatos antes de emitir el token de pago.

El paso de cierre es donde la criptografía demuestra su valía. Cada mandato está vinculado a una transacción específica mediante una firma ECDSA P-256. Ningún mandato puede ser reutilizado. Ninguno puede ser falsificado. Y cualquier parte de la cadena puede verificar de forma independiente, sin necesidad de una autoridad central. Esa última propiedad es lo que hace que la cadena sea un protocolo en lugar de una plataforma.

Este episodio tiene una pieza complementaria que profundiza mucho más en la mecánica del protocolo, el modelo de amenazas y los modos de fallo: la Guía de Campo de AP2. Si este artículo es el episodio, la guía de campo es el manual.

Lo que no llegó a la publicación de LinkedIn

Este episodio todavía está en desarrollo, por lo que las notas honestas importan más de lo habitual.

La demostración simula varios componentes AP2. El Proveedor de Credenciales y el transporte A2A completo están simulados para fines de demostración; TicketVault es un mercado falso. Lo que es fiel a AP2 v0.2 es la parte que importa para evaluar el protocolo: la estructura del mandato, la lógica de firma (SD-JWT real a través de jose, firmas ECDSA P-256 reales) y las interacciones entre partes. Y la capa de gobernanza no está simulada en absoluto: el BPMN, la política de gasto DMN y el Departamento de Pagos HITL son Camunda 8 real ejecutándose en un clúster SaaS en vivo.

Los patrones de mandato también son deliberadamente independientes de la pila. Camunda es mi motor, pero el mismo flujo de mandato de abrir y cerrar funciona en Temporal, LangGraph, n8n o Node.js puro. El repositorio incluye un documento MAKE_IT_REAL con una ruta de actualización de 5 pasos desde esta demostración a AP2 de producción, cubriendo exactamente qué componentes simulados se reemplazan y en qué orden.

Una nota honesta más: el repositorio es privado hasta que se lance el episodio. Se hará público con el episodio, junto con el video de demostración. La guía de campo ya está disponible, porque el análisis del protocolo no necesita esperar mi cronograma de producción.

Registro de lanzamiento

• Protocolo: AP2 v0.2 (Agent Payments Protocol, equipo A2A de Google, donado a la FIDO Alliance)
• Motor: Camunda 8 (clúster SaaS en vivo): orquestación BPMN, política de gasto DMN, Departamento de Pagos HITL
• Modelo: Claude Sonnet como agente de compras
• Criptografía: SD-JWT a través de jose, firmas de mandato ECDSA P-256
• Política: Tabla de decisión DMN de 5 reglas (límite, HITL por límite cercano del 95%, lista blanca de instrumentos, velocidad, general)
• Frontend: React con AG-UI sobre SSE, heredado del EP 02
• Backend: Node.js
• Complemento: Guía de Campo de AP2
• Repositorio: público cuando se lance el episodio