Mientras unos bloquean bots, otros les enseñan a presentar un pasaporte. En 2026, Cloudflare, Google, Amazon, Akamai y OpenAI se unieron en torno a un único estándar — Web Bot Auth. La idea es simple y radical: el tráfico automático ya no se verifica por dirección IP y cadena User-Agent, que son fáciles de falsificar. En su lugar, el agente firma criptográficamente cada solicitud, y el sitio verifica instantáneamente la firma. El 2 de marzo de 2026 se publicó la quinta versión del borrador de la arquitectura (draft-meunier-web-bot-auth-architecture-05), en mayo Google comenzó las pruebas en producción, y el grupo de trabajo de IETF se propuso lanzar el estándar para agosto de 2026. Vamos a ver qué es este mecanismo, quién está detrás de él y por qué para todos los que se dedican al scraping y al multi-cuentas, esto representa un giro de 180 grados.
Qué sucedió: los bots obtienen una identidad criptográfica
La verificación clásica de "propio-extraño" en la web se sostenía sobre dos muletas. La primera — User-Agent: una cadena que el cliente informa sobre sí mismo y que cualquier script reescribe en una línea de código. La segunda — listas de direcciones IP: el sitio mantiene un listado de los rangos "oficiales" de Googlebot, Bingbot y otros, y verifica el DNS inverso. Ambos enfoques colapsaron definitivamente en 2026.
Cloudflare formula directamente el problema en su documentación técnica: una misma IP puede ser utilizada por múltiples usuarios o servicios al mismo tiempo, y los rangos cambian constantemente junto con la infraestructura. El User-Agent, por su parte, no es una prueba en absoluto — es simplemente una auto-representación. La firma criptográfica, según los autores, proporciona autenticación sin depender de "rangos de IP que cambian constantemente" ni de "encabezados falsificables como User-Agent".
Técnicamente, Web Bot Auth se basa en el estándar ya aceptado HTTP Message Signatures (RFC 9421). A cada agente se le asigna un par de claves Ed25519. Antes de enviar una solicitud, el agente no firma cualquier cosa, sino la autoridad del URI objetivo — es decir, el dominio al que se dirige (al acceder a example.com, se firma precisamente example.com). Se añaden encabezados Signature-Input (ventana de validez con etiquetas created y expires, identificador de clave keyid en formato JWK Thumbprint y la etiqueta web-bot-auth) y Signature-Agent, que apunta al directorio con las claves públicas (JWKS). El sitio descarga la clave pública de este directorio y verifica la firma. Falsificarla sin la clave privada es imposible, y la ventana de validez protege contra la reproducción de solicitudes interceptadas.
Quién está detrás del estándar
No es un experimento de una sola empresa. Web Bot Auth es respaldado por Cloudflare, Amazon, Akamai y OpenAI. El borrador de la arquitectura es coescrito por Thibaut Meunier (Cloudflare) y Sándor Major (Google). AWS WAF ya ha añadido soporte para la verificación de firmas, Cloudflare la ha integrado en su programa Verified Bots y la ha activado en su edge en producción. Un grupo de trabajo separado de IETF para Web Bot Auth fue establecido en 2026 y tiene como objetivo entregar la especificación para su estandarización en agosto de 2026.
Google se involucra — y este es un momento decisivo
El 6 de mayo de 2026 se supo que Google está probando Web Bot Auth para verificar su propio tráfico de bots. La idea es que el sitio pueda asegurarse de que la solicitud que se presenta como de Google realmente proviene de Google, y no de alguien que simplemente escribió Googlebot en el User-Agent. El tráfico de AI firmado de Google opera bajo la identidad agent.bot.goog — los propietarios de sitios obtienen las claves públicas de Google desde este endpoint y validan los encabezados Signature y Signature-Input.
Por qué esto es importante ahora. Justamente por lo que escribimos sobre el bloqueo de navegadores de agentes: desde el 15 de septiembre de 2026, Cloudflare por defecto corta a los crawlers de AI "mixtos" en páginas publicitarias de nuevos dominios, y alrededor de una quinta parte de toda la web pasa a través de la red de Cloudflare. La web se está cerrando. Y Web Bot Auth no trata de "cómo bloquear", sino de "a quién dejar entrar". Aparece una lista blanca de nuevo tipo: no por IP, sino por identidad criptográfica. El sitio podrá implementar una política del tipo "mostrar precios y detalles del producto solo a agentes firmados verificados" — y todo lo demás queda automáticamente afuera.
Agentes firmados: la primera cohorte
Una categoría aparte son los signed agents (agentes firmados). Son bots que son controlados por el usuario final, no por una sola corporación: la plataforma o el navegador remoto en el que opera el agente firma sus solicitudes HTTP, y Cloudflare valida las firmas. La primera cohorte incluye ChatGPT agent (OpenAI), Goose (Block), Browserbase, Anchor Browser y Cloudflare Browser Rendering. Daouve Osinga de Block describió la ventaja directamente: "Web Bot Auth permite a los sitios confiar en Goose, manteniendo lo que lo hace único".
La diferencia clave: el signed agent actúa en nombre de una persona (un asistente hipotético que accede al sitio a su solicitud), mientras que el crawler "de búsqueda" o "de entrenamiento" trabaja para una empresa. Cloudflare ya está diferenciando estas entidades en las reglas de seguridad — y esta bifurcación determinará a quién se abrirán las puertas en la web de 2026-2027 y a quién no.
Qué significa esto para el scraping y los proxies
A primera vista, parece que la firma criptográfica entierra el scraping anónimo. En la práctica, es más sutil — la web se divide en dos carriles de tráfico, y para nuestra audiencia esto cambia la táctica, no la anula.
- Carril de agentes firmados. Un paso estrecho y privilegiado para grandes plataformas y asistentes "de usuario" de la lista blanca. Para entrar allí, se necesita una clave privada, un directorio JWKS público, registro en CDN y cumplimiento de políticas. Para un proyecto típico de scraping, granjas anti-detección o automatización de SMM, este camino está cerrado: no eres Google ni OpenAI, no te darán una firma.
- Carril de todos los demás. Aquí siguen viviendo scrapers independientes, monitoreo de precios, recolección de datos, multi-cuentas. Y es aquí donde las apuestas por la calidad del proxy y la veracidad de la huella aumentan. Dado que los "legítimos" son admitidos por firma, la relación con todo el tráfico no firmado se vuelve más estricta por defecto.
En otras palabras, Web Bot Auth no elimina la necesidad de proxies — eleva el umbral para aquellos que no están en la lista blanca. Si antes se podía esperar pasar con un User-Agent gris, ahora una solicitud no firmada cae inmediatamente en la categoría de "demuestra que eres un ser humano". Y esto se demuestra con una combinación de IP limpia y comportamiento creíble.
Por qué las IP residenciales y móviles se vuelven aún más valiosas
Cuando la firma no está disponible, la única forma de parecer legítimo es ser indistinguible de un usuario normal. Las direcciones de centros de datos no resuelven esta tarea: según diversas mediciones, Cloudflare solo permite IP de centros de datos en un 40-60% de los casos, mientras que los proxies residenciales ofrecen una tasa de éxito del 85-99%. La razón es precisamente que la dirección residencial pertenece a un proveedor de internet real y a un abonado vivo — por la reputación de la IP, no se puede distinguir de una persona detrás del mismo router.
La situación es aún más dura con las plataformas más protegidas y las aplicaciones móviles, donde juegan un papel las redes celulares. Aquí los proxies móviles son la solución: detrás de una IP de operador se encuentran miles de abonados vivos, por lo que bloquear tal dirección en masa significa cortar a clientes reales. Precisamente este efecto de "olla común" hace que las IP móviles sean la moneda más resistente en un mundo donde todo lo demás es transparente.
Pero una IP limpia ya no es suficiente. Dado que la verificación de identidad se desplaza de la red a la criptografía, todo el ejército no firmado de bots pasa por huellas de comportamiento y de navegador: TLS/JA4, canvas, WebGL, fuentes, tiempos. El proxy elimina una señal de alarma (la reputación de la dirección), pero no elimina las demás. La combinación de trabajo de 2026 es una IP residencial o móvil más un entorno anti-detección con una huella coherente. Un componente sin el otro revela un bot en el primer nivel de protección.
Cómo actuar ya
- Divida los proyectos por carriles. Si la tarea es una integración oficial en nombre de un gran producto, estudie el camino del signed agent: registro en CDN y obtención de claves. Para todo lo demás, planifique el trabajo en "el carril de todos los demás" y establezca sus reglas.
- Invierta en calidad de IP, no en cantidad. Los pools de centros de datos baratos en 2026 se están convirtiendo cada vez más en un factor de detención. Haga hincapié en direcciones residenciales y móviles con rotación según la tarea.
- Sincronice la huella con la red. IP de un país, pero el idioma del navegador, la zona horaria y la localidad de otro — este es un clásico fracaso. La huella debe coincidir de manera coherente con la geolocalización del proxy.
- Esté atento al estándar. Para agosto de 2026, IETF planea finalizar la especificación. Tan pronto como Web Bot Auth se convierta en un requisito obligatorio para acceder a una plataforma específica, la táctica para ella deberá revisarse con anticipación, no después.
Conclusión
Web Bot Auth no es otro anti-bot, sino un cambio en la lógica misma de la confianza en la web: de "quién eres por IP" a "demuestra criptográficamente quién eres". Para gigantes como Google y OpenAI, es un pase al internet que se está cerrando. Para scrapers independientes y proyectos de multi-cuentas, es una señal de que los métodos grises dejan de funcionar, y la brecha entre "parecer humano" y "parecer un bot" se vuelve decisiva. Ganará en la nueva realidad no quien tenga más IP, sino quien tenga una dirección residencial o móvil limpia y una huella perfectamente coherente. No todos han recibido un criptopasaporte — así que todos los demás tendrán que ser más convincentes.
```