GoDaddy, Infoblox, Google y Cloudflare presentan Chain of Trust junto con la Infocomm Media Development Authority de Singapur (IMDA) en GovWare 2026. La arquitectura de referencia se pone a prueba con una compra simulada de un vuelo entre Madrid y Singapur: una persona autoriza la operación y varios agentes comprueban la identidad y los permisos antes de tramitarla. El ensayo no mueve dinero real. El proyecto sitúa GovWare 2026 del 13 al 15 de octubre, y su caso técnico describe el flujo de la prueba.
Cuatro agentes, cuatro funciones
La prueba distribuye el trabajo entre cuatro agentes desplegados en tres proveedores de nube y cuatro dominios. El agente comprador busca al vendedor y solicita la compra; el agente vendedor publica su perfil y sus ofertas; el servicio de aprobación emite los mandatos que delimitan la autorización; y un verificador independiente revisa los registros y la cadena de mandatos. La persona conserva la decisión de aprobar la compra.
En la implementación descrita, el comprador se ejecuta en AWS, el vendedor en Cloudflare y tanto el servicio de aprobación como el verificador en Google Cloud. La separación importa: la identidad de un agente permite reconocer quién envía una solicitud, pero no le concede por sí sola autoridad para gastar.
Del descubrimiento al pago de prueba
El caso técnico describe una secuencia de once etapas, desde la solicitud inicial hasta la verificación independiente:
- La persona inicia sesión con una passkey y presenta la solicitud de compra.
- El agente comprador descubre al vendedor mediante DNS.
- El comprador realiza catorce comprobaciones sobre el vendedor.
- El agente vendedor publica su perfil y las herramientas disponibles.
- El vendedor envía cotizaciones firmadas.
- La persona aprueba la compra y se emiten dos mandatos firmados.
- El comprador envía una solicitud de finalización de compra firmada mediante UCP.
- El vendedor efectúa diez comprobaciones antes del pago.
- Stripe procesa el pago en modo de prueba y se generan recibos firmados.
- Los participantes registran puntos de control en sus libros de transacciones.
- El verificador independiente reproduce las comprobaciones y emite un resultado firmado.
DNS ayuda a localizar servicios asociados a dominios; A2A permite la comunicación entre agentes, mientras que MCP conecta el asistente de la persona con el comprador. UCP transporta el perfil comercial y las solicitudes de compra. Así, la arquitectura combina descubrimiento, autorización y comunicación en una misma operación, en vez de tratar el pago como una orden aislada.
Qué limita la autorización humana
La aprobación se expresa mediante mandatos del Agent Payments Protocol (AP2), firmados por un servicio independiente. El mandato de compra se limita a un vendedor y a un proceso de pago concretos; el mandato de pago especifica un beneficiario y un importe. Ambos tienen una duración limitada y quedan vinculados a la clave del agente comprador. El propio comprador no puede emitir esos mandatos por su cuenta.
La persona puede detener al agente o cancelar una aprobación. Antes de proceder, el vendedor consulta el estado vigente del mandato en el servicio de aprobación. El operador también puede retirar la clave de un agente o eliminar su registro DNS. Son controles descritos para esta implementación de referencia, no reglas universales de los sistemas de pago con agentes.
Qué acreditan los registros
Cada participante mantiene un registro encadenado mediante hashes, y sus puntos de control firmados se anotan en un registro de transparencia SCITT. El caso técnico explica que ese registro puede acreditar que una entrada existía sin alteraciones en un momento dado, pero no que su contenido sea verdadero.
Los libros de transacciones eran públicos en la demostración con fines ilustrativos. Para despliegues comerciales, el proyecto prevé que cada participante los mantenga privados y permita el acceso a verificadores elegidos. La transparencia de los puntos de control, por tanto, no exige publicar todos los detalles de cada operación.
El caso técnico informa de que las solicitudes falsificadas o manipuladas que se probaron fueron rechazadas y ninguna terminó en un pago. Stripe funcionó en modo de prueba y no se movieron fondos reales. El proyecto presenta Chain of Trust como una arquitectura de referencia en fase inicial; además, identifica DNS-AID y ANS como borradores del IETF y ARD como una especificación comunitaria.
