LupaRiel rieles, no fees
EN

Guía · revisada  · fuentes linkeadas

Qué tiene que tener un mandato firmado para que un agente pague

Que un agente pague solo es la parte fácil. Lo difícil es poder responder después quién lo autorizó, hasta cuánto y quién se hace cargo si algo sale mal. Un mandato firmado es el documento que contesta eso antes del pago. Acá hay un checklist de seis puntos, con lo que dicen las fuentes públicas (AP2 y x402) y lo que cubre hoy Mandato AR, nuestro prototipo.

Resumen al . Los seis puntos son: 1) tope por operación y tope diario, 2) activos o comercios permitidos, 3) vencimiento, 4) quién autorizó, 5) quién absorbe la disputa y 6) recibo. Los puntos 1, 3, 4 y 5 son los mínimos. Si falta uno, la auditoría llega tarde. Es un criterio editorial de LupaRiel, no un estándar ni asesoramiento legal. Ninguna fuente pública que revisamos define los seis en un solo formato.

Por qué una llave sola no alcanza

Una llave o una tarjeta prueba que alguien pudo firmar o cobrar. No dice qué se autorizó. Si el agente se equivoca, recibe un prompt malicioso o ejecuta una orden real, el cobro se ve igual. La especificación de AP2 parte de ese riesgo: cuando un rol es agéntico, el agente mismo es un potencial atacante, y hacen falta mecanismos que dejen evidencia de lo que se autorizó (especificación AP2 v0.2).

Cómo lo llama AP2

La especificación actual de AP2 define dos tipos de mandato: Checkout Mandate y Payment Mandate. Un mandato puede estar abierto, con restricciones y la clave pública del agente, o cerrado, atado a una transacción concreta. El usuario lo aprueba en una Trusted Surface (Agent Authorization). Una versión anterior, cuya especificación ya no está en la rama principal del repo (se puede leer en el commit 61f5de49), hablaba de Intent Mandate y Cart Mandate (especificación anterior). Mandato AR, el prototipo de LupaRiel, tiene su propio esquema, Intent Mandate v0.1.0, con los campos del schema.ts del repo.

El checklist, punto por punto

Cada punto dice qué escribir, y debajo qué dicen las fuentes y qué cubre Mandato AR v0.1.0. Lo que no encontramos en la fuente figura como no figura.

1. Tope por operación y tope diario · mínimo

Escribí dos montos: el máximo por pago y el máximo por período, por ejemplo por día, en el activo del pago. Son dos topes distintos. El primero frena un error grande y el segundo frena muchos errores chicos.

  • x402: el cliente oficial paga por defecto solo activos USD reconocidos, con un tope de 1 USD por pago que se ajusta con maxAmountPerPayment (Spend Controls). Tope por período: no figura en esa documentación.
  • AP2: el Payment Mandate abierto define payment.amount_range (monto máximo por pago), payment.budget (total acumulado, se usa junto con payment.agent_recurrence) y payment.agent_recurrence (frecuencia, por ejemplo DAILY, WEEKLY o MONTHLY, y max_occurrences) (Payment Mandate). Un tope en monto por día como restricción propia: no figura.
  • Mandato AR: tiene budgetUsdc, un presupuesto total del mandato. Tope por operación y tope diario: no figuran en el esquema.

2. Activos o comercios permitidos · recomendado

Escribí una lista cerrada de comercios o endpoints (dominio o URL base), el activo con el que se puede pagar y la red. Lo que no está en la lista, no se paga.

  • AP2: el ejemplo de mandato abierto del spec usa las restricciones checkout.allowed_merchants y checkout.line_items (Agent Authorization).
  • x402: allowedAssets permite optar por tokens fuera de los activos USD por defecto, con un tope atómico por pago (Spend Controls).
  • Mandato AR: allowlist de URLs, resourceBase y network. El endpoint /api/mandate/scope comprueba resourceAllowed y que la red sea Base (eip155:8453).

3. Vencimiento · mínimo

Escribí una fecha y hora de vencimiento en formato ISO 8601. Cuanto más corto, menos tiempo tiene un mandato filtrado para hacer daño. Si la tarea sigue, se firma uno nuevo.

  • AP2: los mandatos abiertos pueden llevar el claim exp, un timestamp Unix. El spec recomienda fijarlo en el valor más chico que le permita al agente completar la tarea (especificación).
  • Mandato AR: expiresAt, y el endpoint de scope comprueba notExpired.

4. Quién autorizó · mínimo

Escribí quién firma (persona o empresa), con qué clave, y qué clave del agente puede usar el mandato. Que cualquiera pueda verificar la firma sin preguntarle al agente.

  • AP2: el usuario aprueba el contenido en una Trusted Surface y se crea el mandato, ya sea con una credencial del usuario o con un Trusted Agent Provider en el que confía el verificador. Un mandato abierto lleva la clave pública del agente en el claim cnf (Agent Authorization).
  • Mandato AR: principal, nonce y signature (HMAC o ed25519). El endpoint de scope verifica la firma, pero el HMAC con secreto demo sirve solo de prueba. No crea ni firma mandatos.

5. Quién absorbe la disputa · mínimo

Escribí qué parte responde si el pago fue un error: quien autorizó, el operador del agente, el comercio o el proveedor de pago. Anotá también el plazo para reclamar y qué evidencia vale. Es un acuerdo entre las partes, no un campo técnico.

  • AP2: el Checkout Mandate y el Payment Mandate, junto con sus recibos, sirven como evidencia de lo que vio cada rol. Resolución de disputas, retención y acceso a la evidencia quedan fuera del alcance de la especificación (sección Dispute Evidence). Quién absorbe la pérdida: no figura.
  • Mandato AR: no tiene campo de disputa.

6. Recibo · recomendado

Pedí que quien verifica el mandato devuelva un comprobante firmado de que lo aceptó o lo rechazó, que referencie al mandato, y guardalo junto con él.

  • AP2: el verificador devuelve un recibo firmado (JWT) con result (success o error) y reference, el hash del mandato recibido (Agent Authorization, Action Authorization).
  • x402: los clientes oficiales leen el resultado de la liquidación, settled o settle_failed (quickstart para compradores).
  • Mandato AR: el mandato no incluye recibo. LupaRiel ofrece settle-receipt para una liquidación ya hecha, que es otra cosa: prueba el settle por hash de transacción, no el consentimiento.

Cómo se conecta con x402

En x402 el pago va por llamada: el 402 trae el monto exacto, el activo y la red (hay un ejemplo decodificado en la guía de USDC en Argentina). Un mandato encima le permite al comercio verificar antes de cobrar y a la empresa explicar después qué pasó. Para probar la verificación, LupaRiel tiene /api/mandate/scope: seis checks sobre un mandato de Mandato AR (esquema, firma, vencimiento, red, recurso permitido y presupuesto), a 0.02 USDC por llamada en Base.

Qué no resuelve esta guía

  • No es un estándar. Los seis puntos son un criterio editorial de LupaRiel.
  • No es asesoramiento legal. La disputa se define en un contrato entre las partes.
  • Mandato AR es un prototipo. Su README dice que el pago on-chain real con facilitador es un stub y que el MVP demuestra el flujo mandato, allowlist, 402 y respuesta (repo mswitach/mandato-ar).
  • AP2 y x402 pueden cambiar. Revisá las fuentes antes de implementar.

Preguntas frecuentes

Qué es un mandato firmado para un agente

Es un documento que firma una persona o una empresa y que dice qué puede hacer un agente: con qué comercios o endpoints, hasta qué monto y hasta cuándo. Quien cobra lo verifica antes de aceptar el pago. En AP2 el mandato puede quedar abierto, con restricciones y la clave pública del agente, y se cierra cuando se ata a una transacción concreta.

Intent Mandate y Cart Mandate en AP2

La especificación actual de AP2 (v0.2) habla de Checkout Mandate y Payment Mandate. Una versión anterior, cuya especificación ya no está en la rama principal del repo (se consulta en el commit 61f5de49), definía Intent Mandate y Cart Mandate. Mandato AR, el prototipo de LupaRiel, usa su propio esquema llamado Intent Mandate v0.1.0, que no es el de AP2.

Quién absorbe la disputa según AP2

La especificación no lo define. AP2 describe cómo el mandato y el recibo sirven como evidencia de lo que vio cada parte, y deja fuera de alcance los detalles de resolución de disputas. Quién absorbe la pérdida es un acuerdo entre las partes y conviene escribirlo antes del primer pago.

Si LupaRiel crea o firma mandatos

No. El endpoint /api/mandate/scope de LupaRiel solo verifica el alcance de un mandato de Mandato AR contra un gasto propuesto. Crear y firmar mandatos es local en Mandato AR.

Fuentes