DEV Community

Edison Flores
Edison Flores

Posted on

Visa tiene un protocolo de agentes de confianza. Mastercard tiene Verifiable Intent. Esta es la capa que ninguno te da (en español)

Versión condensada en español. La versión completa en inglés —incluida la discusión sobre revocación que abrió Alex Shev en comentarios— es la canónica.

Por qué en español

Casi toda la conversación sobre confianza entre agentes IA ocurre en inglés. Pero los agentes no eligen idioma para operar — y los equipos que los construyen en LATAM y España terminan confando en decisiones que nadie les explica cómo auditar. Este artículo corrige eso: qué lanzaron Visa y Mastercard, qué NO dan, y qué piezas puedes verificar tú mismo, hoy, con URLs públicas.

Qué acaba de pasar

En 2026 las redes de pago dejaron de hablar de "agent commerce" en abstracto y empezaron a publicar especificaciones:

  • Visa publicó el Trusted Agent Protocol (TAP): repo abierto con spec e implementación completa. Cada petición de un agente lleva firma criptográfica con timestamp, session ID único, identificador de clave y algoritmo — ligada al dominio del comercio y a la operación específica, sin reutilización posible.
  • Mastercard lanzó Verifiable Intent (VI): el comercio valida la credencial de intención firmada en tiempo real dentro del flujo de autorización, antes de que se mueva el dinero.
  • Alrededor: x402 (Coinbase → Linux Foundation) y AP2 (Google + Visa + Mastercard + PayPal + ~60 socios).

Cuando las empresas que mueven la mayor parte del dinero del mundo construyen la misma capa a la vez, eso no es una tendencia: es validación. La infraestructura de confianza entre agentes ya es load-bearing.

La brecha que nadie cubre

Lo que un tercero no puede hacer con esos protocolos:

  1. Auditar al verificador. ¿Cómo sabes que lo que dice "este agente es confiable" no está corrompido, parcheado o memorizando respuestas? Con un protocolo de red, confías en el veredicto porque confías en la red. Circular.
  2. Reproducir la credencial. ¿Puede un externo reconstruir el artefacto desde bytes públicos y obtener el mismo resultado, bit a bit?
  3. Encontrar evidencia inmutable. ¿Dónde está el registro append-only, hospedado por un tercero, que pruebe qué se publicó y cuándo — y que ni el editor pueda reescribir?

La diferencia en una línea: TAP y VI le dan a un agente permiso para transaccionar dentro de una red. Un ATC le da a cualquiera evidencia verificable fuera de toda red — offline, sin membresía, sin API key.

La analogía: las redes emiten la licencia de conducir. Nosotros publicamos los expedientes judiciales — verificables por cualquier desconocido, sellados en un log público que nadie puede editar. El comercio necesita ambos.

Las tres lecciones que adoptamos

  1. De Visa: la frescura debe ser de dos lados y derivarse de los bytes. Nuestro runner de referencia impone ventana de validez bilateral — issued_at <= NOW < expires_at. Una tarjeta fechada en el futuro (nuestro vector premature-atc, emitido 2030-01-01) falla igual que una expirada. Y el chequeo se deriva de los bytes de la tarjeta, no de metadata lateral: un sidecar mentiroso o borrado no puede voltear el veredicto.
  2. De Mastercard: la verificación va dentro del flujo — la nuestra corre offline. Una ATC se verifica offline en milisegundos: una verificación Ed25519 contra anclas fijadas, cero llamadas de red, cero API keys, cero membresía. Verificación en el flujo sin pedirle permiso al flujo.
  3. De ambas: registro, pero append-only y fuera de nuestro control. Cada release de nuestro suite de conformance está contra-firmado y anclado en Rekor, el log público de transparencia de Sigstore. La entrada #3 (logIndex 2764479676) lleva los digests del suite v1.3.3 completo. Si intentáramos cambiar la historia en silencio, el log nos contradiría.

Los recibos (todo verificable por un desconocido, URLs vivas)

El bug que motivó v1.3.3 lo encontró un desconocido corriendo nuestras propias herramientas contra nosotros. No es vergüenza: es el producto funcionando.

Cierre honesto

Los gigantes van a ganar la capa de permiso del comercio entre agentes — para eso existen las redes. Lo que construimos es la pieza que las redes estructuralmente no venden: prueba que no requiere confiar en el vendedor. Cuando una empresa pregunta "¿quién audita a los auditores?", la respuesta no puede ser "los auditores". Tiene que ser: cualquiera puede, y estos son los comandos.

Validaron la capa. Nosotros guardamos los recibos.

— AliceLabs / MarketNow · marketnow.site · UTA en GitHub

Top comments (0)