Trusted Agent Protocol de Visa: identidad en el borde del merchant

Todo protocolo de pagos para agentes responde a la pregunta "cómo se mueve el dinero". El Trusted Agent Protocol de Visa responde otra: quién está tocando la puerta. Por TAP no se transfiere valor. Es una verificación de firma en la entrada, y se está convirtiendo en el criterio de admisión de la web comercial abierta.

El Trusted Agent Protocol se anunció el 14 de octubre de 2025, desarrollado con Cloudflare, con doce socios de lanzamiento del lado de merchants y procesadores: Adyen, Ant International, Checkout.com, Coinbase, CyberSource, Elavon, Fiserv, Microsoft, Nuvei, Shopify, Stripe y Worldpay. El disparador declarado fue un alza de 4,700% en tráfico impulsado por IA hacia sitios de retail de Estados Unidos. Visa se comprometió a alinearse con el IETF, la OpenID Foundation y EMVCo, a complementar el Agentic Commerce Protocol, y a trabajar con Coinbase en interoperabilidad con x402.

Ese último compromiso es la razón por la que este protocolo importa a quien construye sobre rieles de stablecoin. TAP no compite con x402. Se sienta encima — o más bien, delante. Y la forma de esa puerta decide qué agentes llegan a gastar.

Qué es TAP realmente

Si quitas el envoltorio de comercio, TAP es un perfil de RFC 9421 HTTP Message Signatures aplicado a los requests que un agente hace contra el sitio de un merchant. El agente adjunta headers firmados a cada request. El merchant — o mucho más comúnmente, el CDN que tiene delante — reconstruye la signature base, obtiene la llave pública del agente desde un directorio operado por Visa, verifica, y decide si sirve la página.

Este es el mismo sustrato que Web Bot Auth, que cubrimos hace dos semanas. El writeup de Cloudflare del 24 de octubre de 2025 es explícito: Web Bot Auth es la capa criptográfica de autenticación bajo TAP y bajo Agent Pay de Mastercard, y el objetivo es reemplazar los user-agent strings y las direcciones IP — ambos falsificables — por un identificador estable respaldado por criptografía de llave pública.

La ruta de verificación de Cloudflare para un request de agente autenticado corre siete chequeos: presencia de los headers Signature-Input y Signature; el keyid resuelve a una llave pública obtenida de un directorio; el tiempo actual cae entre created y expires; el nonce no se ha visto antes; el tag es un valor que el merchant acepta; la signature base canónica se reconstruye desde los covered components; y la firma Ed25519 verifica.

La frase crítica del post de Cloudflare es la del alcance. Estos mecanismos identifican agentes y vinculan la identidad del tarjetahabiente. El procesamiento del pago en sí sigue siendo responsabilidad de la red de pagos. TAP es autenticación y reconocimiento. No es settlement.

El formato de cable

La especificación publicada de Visa define el conjunto mínimo de parámetros de firma. Los covered components son las piezas del target URI @authority y @path. Los parámetros son created y expires, un keyid, un alg, un nonce y un tag.

La documentación de Cloudflare muestra el header en la forma en que un merchant lo verá:

Signature-Input: sig2=("@authority" "@path"); created=1735689600;
  expires=1735693200; keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U";
  alg="Ed25519"; nonce="e8N7S2MFd/qrd6T2R3tdfAuuANng..."; tag="web-bot-auth"

Dos propiedades salen directamente de esa estructura. Como @authority y @path están dentro de la signature base, una firma capturada en la página de producto de un merchant no vale nada en el checkout de otro. Y como created, expires y nonce son parámetros firmados, un request capturado no vale nada una vez que su ventana cierra. La especificación de Visa fija esa ventana en ocho minutos, con los merchants rastreando nonces por el mismo periodo.

El tag es donde TAP se separa de la autenticación genérica de bots. Web Bot Auth usa tag="web-bot-auth" para decir "soy un bot declarado". TAP define dos valores que dicen algo más estrecho. agent-browser-auth significa que el agente está navegando — leyendo una página de producto, verificando disponibilidad, comparando un precio. agent-payer-auth significa que el agente está en checkout con intención de pagar.

El directorio es el ancla de confianza

Una firma vale tanto como la llave que la verifica. La especificación de TAP dice que no hay requisito de registro centralizado en sentido de protocolo, pero que los agentes deben participar en un programa de payment scheme — Visa Intelligent Commerce como caso de referencia. Las llaves públicas se publican en https://mcp.visa.com/.well-known/jwks.

Esa es una decisión arquitectónica significativa, y es lo opuesto a cómo el mundo de agentes on-chain abordó el mismo problema. En TAP, un agente es confiable porque Visa respondió por él de antemano. Hay un paso de enrolamiento, términos de producto que aceptar, y un programa de scheme al que unirse antes de que se firme el primer request. El rol de Cloudflare es hacer que la verificación sea gratis para el merchant: los managed rulesets permiten admitir agentes de Visa y Mastercard y bloquear todo lo demás, sin cambiar nada detrás del CDN.

Contrasta esto con ERC-8004, donde cualquier dirección puede registrar un agente y la señal de confianza debería emerger del feedback — que, como mostró la primera auditoría empírica, en gran medida no ocurrió. TAP tiene el modo de falla inverso. Su señal de confianza es fuerte y su puerta de registro es una relación comercial. Ambos diseños responden "quién es este agente". Uno responde con un registro sin permisos que nadie aprendió a leer, el otro con un directorio permisionado que controla una red de tarjetas.

Visa siguió construyendo ese lado. En el Visa Payments Forum del 10 de junio de 2026 la compañía anunció un Agentic Directory de agentes y merchants que verificó como participantes legítimos, un Agent Score que califica si el propio sitio de un merchant es navegable por agentes, un Large Transaction Model para detección de fraude, y una colaboración estratégica con OpenAI. El mismo comunicado ubicó el settlement en stablecoins en un run rate anualizado de alrededor de 7 mil millones de dólares a marzo de 2026, y mostró una prueba de concepto de Crypto Labs que deja a agentes de IA pagar servicios digitales desde una línea de comandos con credenciales Visa tokenizadas. El encuadre de Jack Forestell fue el mejor resumen de la posición de Visa: la IA está transformando el front end del comercio, las stablecoins están rehaciendo el back end.

Recognition: la otra mitad del protocolo

La firma prueba al agente. Una segunda estructura prueba al comprador. La especificación de Visa define un Agentic Consumer Recognition Object que viaja en el cuerpo del request, con un nonce que coincide con el de la firma del mensaje, un idToken, un bloque contextualData, y su propia firma hecha con la misma llave privada que la firma del mensaje.

El idToken es un JWT emitido por el payment scheme, firmado con PS256, que carga identificadores de contacto ofuscados — teléfono y email con flags de verificación — más versiones enmascaradas pensadas para render de UI. El bloque contextualData lleva código de país, código postal, dirección IP e identificadores de dispositivo. Se espera que los merchants mantengan tablas de mapeo que resuelvan un teléfono o email ofuscado contra sus propios registros de cuenta.

Ese último requisito merece atención, porque define el valor comercial real de TAP. El punto no es solo admitir al agente. Es dejar que el merchant reconozca a un cliente que vuelve a través de un agente, prellene el checkout, y aplique lealtad. Los Payment Account References de tarjetas en archivo viajan por el mismo camino cuando el consumidor consiente. TAP es un protocolo de reconocimiento de cliente vestido de autenticación de bots.

Tres contenedores de pago, y uno de ellos es un 402

TAP no mueve dinero, pero sí carga los datos que dejan al merchant moverlo. La especificación define tres enfoques.

Guest checkout / key entry lleva un credentialHash — un hash sobre número de tarjeta, expiración y CVV — que el merchant usa para verificar la credencial que el agente está tecleando. API protocol lleva un payload cifrado con un objeto de pago completo: token, direcciones de envío y facturación, datos de contacto del consumidor. Ambos son flujos de riel de tarjeta, y ambos son lo que esperarías de una red de tarjetas.

El tercero no lo es. Payment IOU se define como una respuesta HTTP 402 que lleva un objeto browsingIOU con referencia a un invoice ID, un monto y datos del adquirente. La descripción del mecanismo por parte de Visa habla de gestionar balances y settlements entre agentes y merchants.

Léelo contra lo que escribimos sobre el scheme batch-settlement de x402 y el parecido es difícil de ignorar. Ambos parten de que un settlement por request — on-chain o sobre riel — es la unidad equivocada para tráfico de agentes de alta frecuencia, y de que la primitiva correcta es una obligación que se acumula y se redime después. La versión de TAP tiene forma de red de tarjetas: el adquirente está nombrado en el objeto y la relación de merchant of record se presume. La de x402 tiene forma de stablecoin. Pero la máquina de estados — commit, acumular, redimir — es la misma, y ambos eligieron HTTP 402 como señal.

Qué trae realmente la implementación de referencia

Las especificaciones dicen qué pretende un protocolo. Las implementaciones de referencia dicen dónde está. Clonamos visa/trusted-agent-protocol el 1 de agosto de 2026 y lo leímos.

El repositorio se creó el 10 de octubre de 2025. El último commit a main aterrizó el 28 de octubre de 2025. En los nueve meses siguientes no se mergeó nada. Tiene 191 estrellas, 40 forks, y 18 issues y pull requests abiertos, nueve de los cuales son pull requests. La licencia no es una licencia open source: LICENSE.md ata el uso a los Visa Developer Center Terms of Use y a los Trusted Agent Protocol Product Terms.

El sample tiene cinco componentes: un agente en Streamlit que genera firmas, un frontend de merchant en React, un backend de merchant en FastAPI, un CDN proxy en Node, y un agent registry que sirve llaves públicas. El agente construye su signature base exactamente como prescribe RFC 9421, con @signature-params como línea final:

# tap-agent/agent_app.py
signature_params = f'("@authority" "@path"); created={created}; expires={expires}; ' \
                   f'keyId="{keyid}"; alg="rsa-pss-sha256"; nonce="{nonce}"; tag="{tag}"'

signature_base = '\n'.join([
    f'"@authority": {authority}',
    f'"@path": {path}',
    f'"@signature-params": {signature_params}',
])

Fíjate en keyId, en camel case. RFC 9421 define el parámetro como keyid, en minúsculas, y tanto el ejemplo de Cloudflare como la propia página de especificación de Visa usan la forma en minúsculas. El agente de ejemplo emite un nombre de parámetro que ningún verificador conforme va a reconocer.

Un componente más allá empeora. El backend del merchant parsea el header con una expresión regular:

# merchant-backend/app/security/signature_verification.py
signature_input_pattern = r'sig1=\("([^"]+)"\);\s*nonce="([^"]+)";\s*created=(\d+);' \
                          r'\s*expires=(\d+);\s*keyid="([^"]+)";\s*tag="([^"]+)"'

El agente emite el label sig2; esto espera sig1. El agente emite covered components entrecomillados individualmente; esto espera un solo bloque entrecomillado. El agente emite created, expires, keyId, alg, nonce, tag en ese orden; esto hardcodea nonce, created, expires, keyid, tag y no tiene lugar para alg. El agente y el verificador de merchant que vienen en el mismo repositorio no pueden hablarse. El CDN proxy, que implementa el parseo y la construcción de la base correctamente, es el único componente que interopera con el agente — y su documentación inline cita un valor de tag, agent-payment-auth, que no existe en la especificación.

El pull request #21, abierto el 15 de julio de 2026, diagnostica exactamente esto y ofrece el arreglo. Sigue abierto. También el #11, abierto el 18 de febrero de 2026, que agrega un flujo x402 funcional al sample — USDC en Solana y Base, el backend del merchant sirviendo HTTP 402 con payment requirements, settlement vía facilitator, probado end-to-end en Solana devnet y Base Sepolia. La interoperabilidad con x402 que Visa prometió en el comunicado de lanzamiento existe, como contribución de la comunidad, sin mergear desde hace cinco meses.

El item abierto más instructivo es el issue #23, presentado el 18 de julio de 2026 por un implementador independiente que construyó un verificador del lado del merchant hasta la profundidad de la spec pública. Su bloqueo no fue la firma del mensaje — esa parte es RFC 9421 y está bien definida. Fue la firma del objeto, la que cubre el Consumer Recognition Object y el Payment Container. La guía pública para esa base es una sola frase: una representación canónica de todos los campos del objeto en el orden recibido, excluyendo el campo de firma. No hay ejemplo trabajado ni test vector, lo que deja sin definir el rendering, la codificación de valores anidados, el join de líneas y el orden de campos. Dos implementaciones razonables producen firmas incompatibles.

Ese es el estado real de TAP en agosto de 2026: un sobre exterior bien especificado que Cloudflare y Akamai pueden verificar en el edge, envolviendo una capa interior que un tercero no puede implementar solo con la documentación pública. Lo que es consistente con el modelo de despliegue. Los procesadores integran una vez y cubren su base de merchants; la adopción se concentró primero del lado del procesador. Visa reportó cientos de transacciones iniciadas por agentes completadas el 18 de diciembre de 2025 con Skyfire, Nekuda, PayOS y Ramp, con Akamai aportando identidad y controles de bots en el edge. Cientos. El protocolo es real y el volumen es un piloto.

Qué significa para LLM4Agents

Tres consecuencias, en orden de qué tan pronto muerden.

La primera es que la web abierta se está volviendo gateada por firma, y nuestros usuarios son los que quedan del lado gateado. Un agente corriendo sobre nuestro gateway que navega el sitio de un merchant para comparar precios es, desde la perspectiva de Cloudflare, tráfico automatizado sin clasificar. Cada vez más se le va a servir un challenge o un bloqueo. El remedio no es enrolarse en TAP — eso es un programa de tarjetas — sino la capa de abajo: un agente que firma sus requests con una llave Web Bot Auth y publica un directorio es, al menos, legible. Los agentes ilegibles pierden acceso primero.

La segunda es la observación espejo. LLM4Agents es él mismo un merchant que vende a agentes, y elegimos el modelo de confianza exactamente opuesto. Nuestro riel walk-up es x402: un agente que nunca vimos presenta una autorización de pago, verificamos, servimos el request, liquidamos. La confianza viene del dinero que se movió, no de un directorio que respondió por él. Ese modelo es estrictamente más sin permisos, y también estrictamente más débil para responder "quién fue este". Ambas cosas son ciertas a la vez, y una plataforma seria debe sostener las dos.

La tercera es el punto de convergencia. El contenedor 402 IOU de TAP y el scheme batch-settlement de x402 son dos implementaciones de la misma idea, llegando desde extremos opuestos de la industria de pagos, ambas apoyadas en HTTP 402. Mientras tanto la propia prueba de concepto de Crypto Labs de Visa tiene agentes pagando servicios digitales desde una terminal con credenciales tokenizadas — que es nuestra superficie de producto descrita en el comunicado de una red de tarjetas. La capa de identidad y la capa de settlement las están construyendo partes distintas, y la costura entre ellas es exactamente donde vive un gateway. Esa costura no es una amenaza. Es la posición.

Cómo mantenerse en la frontera

Firmar los requests salientes y publicar el directorio. Llaves Ed25519, un keyid que sea thumbprint de JWK, un directorio en /.well-known/http-message-signatures-directory, y firmas RFC 9421 sobre @authority y @path en cada llamada HTTP saliente que un agente haga a través nuestro. Es el mismo trabajo sin importar si al otro lado está Verified Bots de Cloudflare, un merchant con TAP, o nada. Es el seguro más barato disponible contra ser clasificado como tráfico anónimo.

Hacer del tag una frontera de política, no un string. Adoptar internamente la división agent-browser-auth / agent-payer-auth, y forzar que nunca se emita una firma payer-auth sin una autorización de gasto explícita y acotada del operador. Es la misma disciplina que la regla de llaves fuera del LLM que aplicamos a la extensión x402 de A2A: el modelo decide qué comprar, el firmante decide qué tiene permitido firmar.

Verificar TAP entrante, en nuestro propio edge. El sobre exterior es implementable hoy con la spec pública más RFC 9421 — parseo agnóstico al label, covered components entrecomillados individualmente, @signature-params como línea final de la base, ventana de ocho minutos, cache de nonces con el mismo TTL, y Ed25519 más RSA-PSS. Un request firmado con TAP que llegue a nuestro gateway debería ser reconocido y registrado como tal aun antes de que hagamos algo con él.

Puentear 402 con 402. Cuando un agente firmado toque un endpoint de pago, responder con payment requirements de x402 y llevar el nonce de la firma al contexto del pago, para que el recibo de settlement quede atado al request que lo disparó. Ese es el eslabón faltante entre "este agente es quien dice" y "este agente pagó" — y es precisamente lo que prototipa el pull request #11 sin mergear. Seguirlo, y construir nuestro lado sin importar si aterriza.

Firmar recibos, en ambas direcciones. El issue #16 del repositorio de TAP pide exactamente esto: un registro a prueba de manipulación que ate la firma original del request a un hash de lo que se procesó, firmado por el vendedor. Ya emitimos hashes de transacción de settlement. Atar el hash a la firma del request convierte dos logs separados en una sola afirmación verificable, que es lo que una disputa realmente necesita.

Vigilar la ruta IETF, no los comunicados. Visa se comprometió a alinear TAP con el IETF, y la capa de firma de Web Bot Auth ya se mueve en un working group. Si el sobre exterior de TAP converge con el perfil del IETF, todo lo construido para uno sirve para el otro. Si no converge, esa divergencia será el hecho más importante sobre identidad de agentes en 2027, y aparecerá en un draft mucho antes que en un anuncio.

Visa construyó una puerta y un portero. El portero revisa credenciales emitidas por Visa. Eso funciona bien para el comercio que fluye por rieles de tarjeta, y no dice absolutamente nada sobre un agente que aparece con una stablecoin y sin presentación. Los dos tipos de tráfico están creciendo. Solo uno de ellos intenta ser sin permisos.