Web Bot Auth: identidad criptográfica para agentes en HTTP

La web agéntica tiene un rail de pago (x402) y un protocolo de tools (MCP). Lo que no tenía, hasta hace poco, era una forma de que un agente pruebe quién es ante un servidor que nunca ha visto. Web Bot Auth — HTTP Message Signatures con un directorio de llaves publicado — se está convirtiendo en esa capa, y en 2026 pasó de experimento de Cloudflare a working group de la IETF con despliegues en producción en dos de las mayores redes edge.

Esto importa a cualquiera que opere agentes autónomos. La web se está cerrando a la automatización anónima: los origins bloquean por defecto a los bots sin identificar, y la infraestructura que deja pasar a un agente verificado es la misma que le va a cobrar por request. Identidad y pago están convergiendo en un solo handshake. Este post recorre el formato en el cable, la ruta de estandarización, los despliegues y el punto exacto donde un request firmado se convierte en uno pagado.

Por qué fallaron los identificadores viejos

Históricamente los servidores tenían dos formas de decidir si el tráfico automatizado era bienvenido: el header User-Agent y la IP de origen. Ambas están rotas para agentes, y la propuesta original de Web Bot Auth de Cloudflare (mayo 2025) es directa sobre el porqué.

Un string de User-Agent es una afirmación auto-reportada sin mecanismo de verificación. Cualquiera puede enviar User-Agent: MyTrustedAgent/1.0. Las allowlists de IP son más fuertes pero frágiles: los agentes corren cada vez más desde infraestructura cloud compartida, detrás de proxies de privacidad y VPNs, donde un rango de IP dice de qué datacenter salió un request, no qué operador controla el software. Los rangos además cambian constantemente, así que cada origin termina manteniendo listas CIDR ad-hoc que nacen desactualizadas. Los secretos compartidos tampoco escalan — un crawler no puede provisionar un token distinto con cada sitio de internet antes de visitarlo.

La falla es estructural. Los tres mecanismos atan la identidad a de dónde viene un request o a qué dice ser. Ninguno la ata a algo que solo el operador posee. Ese es un trabajo para criptografía asimétrica.

RFC 9421: firmas sobre mensajes HTTP

RFC 9421, HTTP Message Signatures, es el estándar de la IETF para crear y verificar firmas sobre componentes seleccionados de un mensaje HTTP — headers específicos, más componentes derivados como @authority (el host destino) y @target-uri. El firmante declara exactamente qué componentes cubrió y bajo qué parámetros; el verificador reconstruye la misma base de firma y la valida contra una llave pública conocida.

RFC 9421 es deliberadamente genérico. No dice quién firma, dónde viven las llaves ni qué significa una firma. Web Bot Auth es un perfil de RFC 9421 que responde esas tres preguntas para el tráfico automatizado: el proveedor del bot firma cada request, las llaves se publican en una ubicación HTTPS well-known, y una firma válida significa "este request lo produjo el operador que controla este directorio de llaves".

El formato en el cable

Un request de Web Bot Auth lleva hasta tres headers extra. Según la documentación de implementación de Cloudflare y el draft de protocolo vigente, se ven así:

# Dónde puede encontrar el verificador las llaves públicas
Signature-Agent: "https://signer.example.com"

# Qué se firmó, y bajo qué parámetros
Signature-Input: sig=("@authority" "signature-agent");\
                 created=1700000000;\
                 expires=1700011111;\
                 keyid="ba3e64==";\
                 tag="web-bot-auth"

# La firma Ed25519, en base64
Signature: sig=abc==

Cada parámetro hace trabajo real. created y expires acotan la ventana de validez — el draft vigente recomienda que las firmas vivan como máximo 24 horas, lo que limita el replay. keyid no es un string libre: debe ser el JWK SHA-256 Thumbprint en base64url (RFC 7638) de la llave firmante, para que el verificador ubique la llave exacta en el directorio sin ambigüedad. tag debe valer web-bot-auth, acotando la firma a este protocolo para que no pueda confundirse con una firma hecha con otro propósito. Y los componentes firmados deben incluir el destino — al menos @authority en la implementación de Cloudflare; al menos uno de @authority o @target-uri en el draft vigente — de modo que una firma capturada en un sitio no pueda reproducirse contra otro.

El lado del verificador gira en torno al directorio de llaves. Un operador publica un JSON Web Key Set en una ruta fija del dominio nombrado en Signature-Agent:

GET https://signer.example.com/.well-known/http-message-signatures-directory

{
  "keys": [{
    "kty": "OKP",
    "crv": "Ed25519",
    "x": "JrQLj5P_89iXES9-vFgrIy29clF9CC_oPPsw3c5D0bs"
  }]
}

Ed25519 es el único algoritmo que soporta Cloudflare — una curva, sin negociación, sin superficie de downgrade. El directorio debe servirse por HTTPS, y el verificador de Cloudflare además valida una firma sobre la propia respuesta del directorio antes de confiar en las llaves que contiene. El ciclo completo: descargar el directorio, verificar su propia message signature, extraer las llaves Ed25519, hacer match del thumbprint del keyid del request, verificar la firma del request. Sin listas de IPs en ninguna parte del camino.

De drafts individuales a un working group de la IETF

Vale la pena rastrear la trayectoria de estandarización con precisión, porque te dice cuánto construir sobre esto hoy. Web Bot Auth arrancó como drafts individuales de Thibault Meunier (Cloudflare): un documento de arquitectura y uno de directorio de llaves. El draft de arquitectura, draft-meunier-web-bot-auth-architecture, llegó a la versión 05 en marzo de 2026 y desde entonces fue reemplazado por draft-meunier-webbotauth-httpsig-protocol ("HTTP Message Signatures for automated traffic"), cuyo -00 aterrizó en junio de 2026 con autores de Cloudflare y Google.

Más significativo: la IETF constituyó un working group dedicado, Web Bot Auth (webbotauth), en el área Web and Internet Transport, presidido por David Schinazi y Rifaat Shekh-Yusef. Los hitos de su charter apuntan a especificaciones standards-track para la técnica de autenticación y para transmitir metadata adicional del bot, más un documento operacional Best Current Practice hacia fines de agosto de 2026. Que drafts individuales se conviertan en un WG con charter es la diferencia entre "la idea de Cloudflare" y "la forma en que la web va a hacer esto" — con la salvedad habitual de que nada es RFC todavía y los drafts explícitamente carecen de standing formal hasta que el WG los publique.

El discovery se estandariza en paralelo. Una firma te dice que las llaves viven en signer.example.com, pero no le dice a un origin qué signature agents existen ni qué hacen. La propuesta de registry de Cloudflare (octubre 2025, draft-meunier-webbotauth-registry) define un formato liviano: listas de URLs de signature agents que cualquiera puede curar y hostear, más "signature agent cards" que extienden el directorio JWKS con metadata — nombre y contacto del operador, user-agent esperado, propósito, expectativas de rate control, cumplimiento de robots.txt (RFC 9309). Es la misma forma del problema de reputación que ERC-8004 ataca on-chain: la identidad es el paso uno, la reputación descubrible es el paso dos.

Quién lo despliega hoy

Esto ya no es un demo de investigación. Importan tres despliegues en producción.

Cloudflare. Las message signatures son un método de verificación de primera clase en el programa Verified Bots: un operador genera llaves, hostea el directorio, firma requests y registra la URL del directorio en el dashboard. Una vez verificado, cada sitio detrás de Cloudflare puede actuar sobre eso — el campo cf.verified_bot_category está disponible en WAF Custom Rules, rate limiting y Transform Rules, así que un origin puede expresar "permitir agentes de investigación académica, cobrar a los crawlers de AI, bloquear todo lo no firmado" como expresiones de reglas ordinarias evaluadas en el edge.

OpenAI. Citado directamente en el anuncio de Cloudflare: "With HTTP Message Signatures (RFC 9421), OpenAI signs all Operator requests so site owners can verify they genuinely originate from Operator." El agente que navega — el bot más difícil de distinguir de un humano — es precisamente donde la auto-identificación tiene más valor.

AWS. Amazon Bedrock AgentCore Browser agregó Web Bot Auth en preview (anunciado en octubre 2025): el browser administrado firma automáticamente cada request HTTP saliente, y los vendors de bot control — Cloudflare, Akamai, HUMAN Security — verifican las firmas y aplican la política del dueño del sitio, reduciendo la fricción de CAPTCHAs para agentes verificados. Del lado receptor, AWS WAF Bot Control verifica firmas de Web Bot Auth. Detalle notable: AgentCore hoy firma con una llave a nivel de servicio y planea pasar a llaves por cliente a medida que el protocolo madure — la pregunta de granularidad (identidad del proveedor vs. identidad por tenant) sigue abierta.

El tooling es abierto. El repo cloudflare/web-bot-auth (Apache 2.0) publica paquetes TypeScript (web-bot-auth, http-message-sig, jsonwebkey-thumbprint) y crates Rust (web-bot-auth, http-signature-directory), más ejemplos funcionales: una extensión de browser que firma, un Cloudflare Worker que verifica y un plugin de Caddy. El repo dice sin rodeos que el código no está auditado — suficiente para adoptar el formato de cable, algo a recordar antes de que custodie algo valioso.

Donde la identidad se encuentra con el pago

Acá está el porqué esto no es solo una historia de bot management. Todo diseño reciente de pagos máquina-a-máquina asume que el pagador está identificado por una firma de Web Bot Auth antes de que el dinero se mueva.

El pay per crawl de Cloudflare (julio 2025) hizo explícita la dependencia. Un crawler debe registrar su directorio de llaves y firmar cada request con los tres headers de Web Bot Auth. Cuando toca contenido pago, el edge responde 402 Payment Required con un header crawler-price; el crawler reintenta con crawler-exact-price para aceptar, o envía crawler-max-price por adelantado para saltarse la vuelta extra; una respuesta exitosa confirma el cargo con crawler-charged. La firma no es un accesorio — es la identidad de facturación. Cloudflare actúa como merchant of record y liquida los cargos agregados a los publishers contra el crawler registrado y verificado.

El esquema "deferred" de x402 que Cloudflare propuso junto con la x402 Foundation empuja la misma idea al protocolo abierto: desacopla el compromiso criptográfico del settlement, de modo que un agente puede acumular compromisos de pago firmados — autenticados con los headers Signature-Agent y Signature-Input — y liquidar en batch diario, o bajo un acuerdo de licencia pre-negociado. Compáralo con la ruta de settlement inmediato que cubrimos en EIP-3009, donde cada request lleva un transferWithAuthorization auto-contenido: deferred cambia atomicidad por menos overhead por request, y solo funciona porque el pagador tiene una identidad persistente y verificable contra la cual facturar.

El Monetization Gateway (waitlist abierta el 1 de julio de 2026) generaliza esto a todo lo que está detrás de Cloudflare: páginas web, datasets, APIs, tools de MCP. Los vendedores escriben reglas de precio como expresiones en el edge; los compradores reciben un 402 con precio, activo y destino; un facilitator verifica el pago en stablecoins (USDC entre ellas) y el edge libera el recurso — con enforcement en 330+ ubicaciones antes de que el tráfico llegue al origin. Y en la propia formulación de Cloudflare, los vendedores pueden "require agents to authenticate with Web Bot Auth and apply usage-based pricing against accounts they already hold". El acceso con identidad verificada y precio por uso se está volviendo un checkbox en el reverse proxy más grande del mundo.

En conjunto, el stack queda así: RFC 9421 responde quién llama, x402 responde cómo paga, y el edge hace cumplir ambos en una sola negociación 402. Es la misma estratificación que describimos desde el lado del pago en nuestro deep dive de x402, ahora con la capa de identidad que faltaba.

Las salvedades honestas

Tres límites que vale la pena enunciar. Primero, madurez: los documentos del protocolo son drafts, el draft de arquitectura anterior está formalmente expirado, y las implementaciones advierten que los detalles pueden cambiar antes de que el WG produzca RFCs. Construir contra el comportamiento desplegado de Cloudflare y AWS es razonable; tratar los drafts como congelados, no. Segundo, granularidad: las firmas de hoy identifican proveedores, no agentes. Que Cloudflare verifique "esto es tráfico de AgentCore" no dice nada sobre cuál de miles de tenants está manejando el browser — las llaves por cliente están en el roadmap, no en producción. Tercero, gatekeeping: las listas de verificación y los registries los curan las mismas redes edge que venden bot management. El formato abierto del draft de registry, hosteable por cualquiera, es el contrapeso, pero los anclajes de confianza por defecto hoy son las bases de datos de Cloudflare y AWS. El paso de la x402 Foundation a la Linux Foundation muestra que el ecosistema entiende esta preocupación del lado del pago; la identidad va a necesitar el mismo tratamiento.

Qué significa para LLM4Agents

LLM4Agents opera en ambos lados de este handshake, así que Web Bot Auth corta dos veces.

Del lado saliente, los agentes fondeados a través de nuestro gateway alcanzan cada vez más la web abierta — descargan páginas, llaman APIs de terceros, hacen walk-up a endpoints x402. A medida que los origins bloquean por defecto la automatización sin firmar, una flota de agentes sin firma se degrada: más CAPTCHAs, más 403s, más fallas silenciosas que parecen errores del modelo pero son negaciones de acceso. Firmar requests se vuelve requisito de confiabilidad, igual que las cadenas de fallback lo son para la disponibilidad de modelos. Un gateway que firma el tráfico de egreso con un directorio de llaves publicado le da a cada agente detrás de él una identidad verificable sin que cada operador monte su propia infraestructura de firma.

Del lado entrante, nuestros endpoints de API y tools de MCP reciben tráfico automatizado por diseño — ese es el producto. Web Bot Auth nos da una señal criptográfica para segmentar ese tráfico: los agentes verificados de proveedores conocidos pueden recibir rate limits más altos o pricing x402 walk-up, y el tráfico sin firma toma la ruta conservadora. Y el patrón de settlement diferido mapea directo a nuestro ciclo de facturación reserve–proxy–settle: una identidad persistente verificada es exactamente lo que hace seguro ofrecer facturación post-paga o liquidada en batch. La identidad no es adyacente al stack de pagos que venimos construyendo — es el prerequisito de su siguiente iteración.

Cómo mantenerse en la frontera

Pasos concretos, en orden.

1. Firmar el egreso del gateway. Generar un keypair Ed25519, publicar el JWKS en /.well-known/http-message-signatures-directory en el dominio de llm4agents, y firmar el HTTP saliente de las cargas de agentes con tag="web-bot-auth", expiries cortos y cobertura de @authority. Las librerías TypeScript y Rust con licencia Apache 2.0 cubren la mecánica; esto es días de trabajo, no meses.

2. Registrarse con los verificadores que importan. Enviar el directorio de llaves al programa Verified Bots de Cloudflare y seguir la ruta de registro de AWS WAF Bot Control a medida que se abra más allá de AgentCore. Estar en el conjunto confiado por defecto antes de que los origins endurezcan sus defaults es barato ahora y caro después.

3. Verificar firmas entrantes. Agregar verificación RFC 9421 en nuestro edge para el tag web-bot-auth, y exponer el resultado a la política de facturación y rate limiting. Empezar en modo observacional — loguear qué callers ya firman — y luego dejar que la identidad verificada desbloquee mejores tiers de precio.

4. Publicar una signature agent card. Cuando el draft de registry se estabilice, publicar la metadata extendida del directorio: contacto del operador, propósito, expectativas de rate. Costo bajo, y posiciona la plataforma para la capa de reputación que gane — listas de registry del lado web2, ERC-8004 on-chain.

5. Seguir el WG webbotauth y el esquema deferred de x402. La salida del WG hasta agosto de 2026 va a fijar los detalles del protocolo; el esquema deferred decide si las llaves por tenant y el settlement en batch se vuelven estándar. Ambos moldean directamente nuestro roadmap de identidad por agente — la granularidad que el ecosistema aún no resuelve, y donde un gateway que ya conoce la wallet y el historial de cada agente tiene una ventaja natural.