La web no necesita gatekeepers: la nueva propuesta de "agentes firmados" de Cloudflare

• La política de Signed Agents de Cloudflare se presenta en nombre de la seguridad, pero en la práctica es un intento cerrado de convertir el acceso a la web en un sistema por permisos
• Históricamente, la web creció gracias a la apertura y los estándares, y tecnologías cerradas como Flash y Silverlight terminaron desapareciendo frente a estándares abiertos como HTML5
• En adelante, los principales usuarios de la web serán los agentes de IA, y para eso se necesita un sistema de autenticación distribuido y verificable, junto con autorización por unidad de tarea
• El modelo correcto es combinar delegación basada en cadenas + prueba por solicitud, para implementar autenticación confiable y control de permisos granular
• En lugar de que una empresa específica tenga la llave, hay que proteger una web donde todos puedan participar e innovar mediante protocolos y estándares abiertos

---

Crítica a Signed Agents de Cloudflare

• Cloudflare propuso un nuevo sistema de Signed Agents, pero en realidad se trata de un control de acceso basado en listas de permitidos
• Que una empresa específica decida si un agente puede registrarse o no no es un protocolo de internet, sino apenas un sistema de aprobación del proveedor
• Esto choca con la naturaleza abierta de internet, y “llenar un formulario para recibir permiso” no puede convertirse en un estándar

La web debe seguir siendo abierta

• En los 90, la estrategia de “embrace and extend” de Microsoft fracasó, y eso fue posible porque la web mantuvo su apertura
• Los runtimes cerrados como Flash y Silverlight terminaron siendo reemplazados por el estándar abierto HTML5
• La historia siempre demuestra que los estándares abiertos impulsan la innovación

La llegada de la era de los agentes

• Los agentes de IA serán usuarios clave de la web y realizarán tareas como búsqueda de información, automatización, pagos y negociación de contratos
• La frontera entre las acciones humanas y las de los agentes se volverá difusa, y eso exige de forma indispensable un sistema de autenticación basado en delegación

Autenticación (Authentication) y autorización (Authorization)

• Autenticación: ¿quién está actuando?
• Autorización: ¿qué puede hacer?
• Cloudflare confunde ambos conceptos e intenta resolverlo todo con un “pasaporte”, pero eso es fundamentalmente imposible
• La autenticación correcta debe implementarse mediante cadenas de delegación y firmas por solicitud, aprovechando mecanismos de verificación distribuidos como la emisión de claves públicas basada en DNS

Gestión de permisos

• En el software tradicional, el modelo de scopes de OAuth funcionó bien gracias a su alcance limitado
• Pero como los agentes son de propósito general, se necesita una autorización acotada por tarea (task-scoped)
• Ejemplo: el permiso para “pagar la cena” y el permiso para “consultar el historial de gastos de 3 meses” deben usar tokens distintos, incluso para el mismo agente
• Para esto pueden usarse tokens basados en restricciones como Macaroons y Biscuits, así como motores de políticas como OPA/AWS Cedar

Primero los protocolos, sin gatekeepers

• La autenticación, la autorización y la monetización deben construirse sobre estándares abiertos e interoperables, no depender de una empresa específica
• Si unas pocas empresas determinan la validez de los agentes, la web pronto caerá en un jardín amurallado (walled garden)
• Por eso se propone como open source una combinación de delegación basada en cadenas, prueba por solicitud y autorización por alcance de tarea, para que cualquiera pueda implementarla

Conclusión

• El futuro de la web no depende de “quién controla la puerta”, sino de protocolos que todos puedan construir, compartir y usar para innovar

[GN⁺]

Opiniones de Hacker News

• Todos sueñan con una web completamente libre y abierta, pero en la práctica resulta frustrante que alguien con un blog pequeño o contenido propio casi no tenga forma de protegerse de los bots de entrenamiento de IA; no parece realista confiar en que distinguirán entre agentes y bots de entrenamiento y que de verdad respetarán robots.txt; incluso si lo respetaran, seguiría existiendo el concepto de comprar datos indirectamente bajo la etiqueta de "licensed data"; a menos que seas una empresa como Reddit, X, Google o Meta, con recursos legales casi ilimitados, como individuo no tienes poder. También recomienda este video.

  • Se siente contradictorio querer una web libre y abierta y, al mismo tiempo, querer bloquear bots de entrenamiento de IA; si la web está abierta para todos, entonces los bots de entrenamiento también deberían poder acceder sin excepción.

  • (Sobre el sueño de la web abierta) El sueño de tener contenido abierto en internet es real; mi blog permite el acceso libre a cualquiera, humano o máquina. Mi servidor además está alojado por mí mismo en casa, así que no veo la necesidad de distinguir entre humanos e IA. Si preocupa que un sitio reciba demasiadas visitas, en realidad el problema es el exceso de tráfico en sí, venga de humanos o de IA. Solo dejo en robots.txt una guía mínima para que los bots no caigan en bucles, y fuera de eso permito el rastreo libremente. Amazonbot visita mi sitio con frecuencia y siempre es bienvenido.

  • Creo que hay que desarrollar software libre para luchar contra software hostil. Las grandes empresas están creando agentes de IA hostiles, y frente a eso los hackers capaces deberían desarrollar anti-AI-agent. No estoy de acuerdo con el derrotismo de decir "no tenemos poder".

  • Señala la realidad de que, aunque aquí en Hacker News hay muchísimos ingenieros de grandes empresas tecnológicas, cuando se trata de su propio trabajo nunca hablan de privacidad ni de gobernanza de datos y siempre gritan por otros temas. Si hace falta un espejo para la autocrítica, yo estaría dispuesto a comprarlo.

  • No entiendo por qué siquiera surge la pregunta de si hay que proteger blogs pequeños o contenido contra bots de entrenamiento de IA. Si para generar HTML básico ya hace falta usar frameworks pesados y complejos, y como resultado se consumen demasiados recursos de CPU, ese sí sería el verdadero problema. O quizá tendría sentido preocuparse si alguien cree que lo que publica en línea es el camino hacia riqueza y fama como creador de contenido; pero si no es así, entonces no veo que exista un problema real.

• En la práctica, creo que la “web” dejó de ser abierta hace mucho tiempo. La mayoría de las interacciones, publicaciones y circulación de información ocurren detrás de autenticación (inicio de sesión). Las principales redes sociales, periódicos y demás restringen o bloquean el acceso no autenticado. Los blogs representan una porción ínfima del total de información que consume la gente común.

  • No estoy de acuerdo con la afirmación de que “la web ya no es abierta”. La web no necesita sumar más gatekeepers, y si ya hay demasiados, entonces más bien habría que reducirlos.

• A mí tampoco me molestan los agentes de IA en sí; si detrás hay un usuario real, me parece bien. Pero sí me molesta mucho que Meta, Perplexity, OpenAI y otros rastreen mi sitio de forma agresiva. El rastreo de IA consume más recursos que usuarios reales o incluso que la búsqueda de Google. Es realmente fastidioso que núcleos completos de CPU queden ocupados por ese rastreo.

  • A mí me pasa igual; tengo varias apps personales en línea y el mes pasado un bot de IA se llevó 1.6TB de datos, así que no me quedó otra que activar la protección contra bots de IA de Cloudflare. Llegaban más de 1.3 millones de solicitudes al día sin parar y era imposible soportarlo.

  • En algunos de mis sitios de marketing entran entre 200 y 300 solicitudes por segundo. Incluso generan URLs inexistentes al azar y las llaman, hasta un punto que ya no se puede controlar.

  • Me da curiosidad cuántos ciclos de CPU provoca el web crawling de las empresas de IA. Normalmente, cuando se habla del impacto ambiental de la IA, solo se considera el entrenamiento o la inferencia del servicio, pero también habría que tener en cuenta la carga adicional del rastreo web. Para hacer una comparación precisa, tendría sentido compararlo con lo que pasaría si usuarios humanos hicieran esas mismas acciones directamente; si el bot estuviera diseñado para generar tráfico de forma más eficiente, minimizando trackers, imágenes y otros elementos extra y tomando solo lo necesario para responder a la consulta objetivo, entonces la carga total de CPU para la humanidad podría incluso ser menor que si todos visitaran esos sitios directamente desde el navegador.

  • Igual en mi caso: si detrás del agente de IA hay un usuario real y no accede de forma anormalmente excesiva, no me importa mucho. (No es que yo haya querido que usen mi sitio con agentes de IA, pero me da igual cómo lo use cada quien). Lo que sí no me gusta es el rastreo excesivo. Y, por otro lado, más importante aún, alguien puede simplemente descargar un archivo con curl o usar un navegador de texto como Lynx. Creo que esos escenarios también deben seguir siendo compatibles.

  • Cloudflare distingue entre agentes “intentados por un usuario” que sí se permiten y otros agentes que se bloquean, separándolos del rastreo indiscriminado para recolectar datos de entrenamiento. La mayoría de las solicitudes que envían Meta, Perplexity y OpenAI son búsquedas web activadas por prompts de usuarios reales, y esas solicitudes no se usan para entrenar el siguiente modelo LLM. Cloudflare está difuminando la diferencia entre ambos casos y oficialmente habla de “proteger a los creadores”, pero en realidad está construyendo un sistema para quedarse con una especie de peaje cobrado a los proveedores de LLM. Al final, creo que no se trata de justicia sino de un incentivo económico.

• Yo uso un navegador poco común que no expone demasiada información personal, pero desde la perspectiva de Cloudflare yo también parezco un bot. Creo que en un entorno donde el host (el dueño del sitio web) decide quién accede, no puede existir la privacidad. Estoy de acuerdo con el rate limiting para evitar sobrecarga del servidor, pero bloquear el acceso automatizado en sí es prácticamente imposible, y al final este tipo de bloqueos termina dificultando también el acceso de usuarios reales.

  • Me da curiosidad si actualmente te bloquean seguido por Cloudflare o turnstile. Ya lo insinuaste arriba, pero quería confirmarlo claramente.

  • Si alguien vive en un país autoritario y necesita usar VPN por privacidad y libertad, internet se convierte en un infierno de captchas operado por 2 o 3 empresas. De hecho, cuando uso una VPN y un navegador orientado a la privacidad para navegar normalmente por internet, tengo más problemas que cuando intento entrar a sitios protegidos por Cloudflare con un bot hecho por mí. Y, por cierto, si Microsoft estuviera a cargo del gatekeeping de la web sería todavía peor; en especial, si usas VPN e intentas pasar un captcha de Microsoft, tienes que concentrarte más de 5 minutos y casi prepararte para escribir una tesis antes de lograrlo.

  • Los dueños de sitios web también tienen derechos, por supuesto. Pedirles que no elijan gatekeeping para lograr sostenibilidad financiera en la operación es una exigencia poco razonable.

  • Yo también uso un navegador poco común y a menudo me atrapan los bloqueadores de bots. Aun así, creo que el host también tiene el derecho de manejar mis solicitudes como quiera. En particular, pienso que los sitios del gobierno tienen una responsabilidad mucho mayor de atender a todos de forma justa.

• Si alguien tiene una buena alternativa más abierta, me gustaría escucharla. Pero por ahora, la forma en que Cloudflare lo hace está resolviendo bastante bien el problema real de los bots de IA. Ya se intentó bloquear por IP o por user agent, pero eso tiene límites. Y, de hecho, otros problemas de seguridad también se han resuelto históricamente de maneras algo centralizadas. Las autoridades certificadoras (certificate authority) tampoco son un sistema abierto, ni los proveedores de attestations, y aun así funcionan.

  • Si quieres una solución más abierta, tal vez la respuesta sea la regulación. Podría prohibirse legalmente cualquier solicitud de crawlers que no estén explícitamente permitidos por el operador del sitio en robots.txt, y hacer que las autoridades la hagan cumplir directamente. Si el operador del sitio puede demostrar tráfico de bots, podría denunciarlo al gobierno para que imponga multas elevadas. También podría obligarse a los proveedores de servicios cloud a registrar quién usó qué IP. No sería una solución al 100%, pero si se aplica bien podría tener un efecto disuasivo bastante fuerte.

  • Puede que este enfoque no sea la mejor solución posible, pero en la práctica funciona hasta cierto punto. Hay muchas críticas al problema de la centralización, pero si Cloudflare logra que participen tanto los principales proveedores de IA como los CDN, podría terminar consolidándose como un estándar de facto.

  • Los certificados no bloquean a personas por confundirlas con bots.

  • Más bien creo que el AI poisoning —mezclar intencionalmente información falsa en los datos para entorpecer a la IA— sería una protección más efectiva. Cloudflare incluso podría ofrecer un servicio que entregue datos falsos deliberadamente a los bots de IA.

  • En realidad, antes de Let's Encrypt, las CA muchas veces solo se usaban en sitios web corporativos comunes, y aun así solo en algunas páginas de inicio de sesión. Si no hubiera existido la política abierta de Let's Encrypt, nuestra información personal todavía seguiría expuesta a los ISP o a atacantes intermediarios. Los proveedores de attestation también son impotentes: incluso cuando se conocen ampliamente vulnerabilidades en dispositivos, se niegan a revocar certificaciones por decisiones de negocio. En conclusión, en la mayoría de estas discusiones parece que no se encuentra bien una alternativa real. Que Cloudflare se convierta en gatekeeper de internet es una mala solución, pero el problema en sí es mucho más grave. De hecho ya existen soluciones completamente distribuidas (por ejemplo: remote attestation, modelos de pago por visita/suscripción, firewalls autohospedados). La actitud de ignorar los efectos secundarios de la IA y simplemente decir que se pague el costo es una de las razones por las que Cloudflare ha crecido tanto. Si los ISP y otros no hubieran ignorado problemas como spoofing, DDoS y botnets, Cloudflare probablemente se habría quedado solo como otro competidor más, al estilo de Akamai.

• Ya vivimos en un mundo con demasiados gatekeepers. Cualquier intento adicional de sumar otro gatekeeper debería verse como una acción agresiva. Tanto Cloudflare como Google están empujando cada vez más fuerte su posición de gatekeepers. Si esta tendencia continúa, me gustaría ver a ambos colapsar por completo.

  • Varias empresas están intentando proponer soluciones para el problema de los bots de IA, y si se elige a Cloudflare obtendría enormes ganancias. Pero aunque Cloudflare se retire, el problema no desaparece: solo se adoptaría otra mala alternativa de otra empresa. El gatekeeping, en la práctica, es una opción que el dueño del sitio elige por su cuenta (por ejemplo: paywall, detección propia de bots, verificación de identidad, etc.). Cloudflare ya ofrece este tipo de servicio, y si además se estandariza, aumentan las opciones y el mercado también se abre más, con todo y sus efectos secundarios. La verdadera libertad de la web abierta debe aplicarse por igual no solo a los visitantes, sino también a los dueños de los sitios.

  • Es exagerado hablar del “deseo” de Google de convertirse en el gatekeeper del futuro: Google ya lleva años actuando como gatekeeper gracias a la cuota de mercado de Chrome. Firefox también ha perdido mucha relevancia. La idea es que Google ya está empujando toda la www en la dirección que quiere (uBlock prohibido, imposición del formato .webp, etc.).

• Antes de señalar como problema una allowlist operada por una sola empresa, hay que reconocer que en realidad fue el propio operador del sitio quien eligió ese servicio. Lo curioso es la contradicción de hablar ideológicamente de “justicia” mientras en la práctica cotidiana ya se suben al blog cómics hechos con herramientas de IA y la IA ya está profundamente metida en la vida real.

  • Cloudflare está implementando el estándar emergente Web Bot Auth, y nosotros en Stytch también estamos aplicando ese mismo estándar en IsAgent.dev. La discusión actual se ha calentado bastante, así que lo digo con cuidado, pero al final la allowlist es solo una opción que Cloudflare ofrece a sus clientes, y el núcleo, como HTTP Message Signature, está diseñado de forma abierta/distribuida para que cualquiera pueda usarlo.

  • No hay problema en que alguien use, por elección propia, la allowlist de una empresa, pero eso por sí solo no lo convierte en un protocolo. Y la discusión sobre la justicia no parece tener una relación lógica con usar cómics hechos con IA.

  • Es una situación de elegir el mal menor, y existe el riesgo de que la solución de una empresa termine quedándose como si fuera un estándar público. Esta oportunidad podría haber servido para crear una solución real basada en protocolos y estándares, pero Cloudflare más bien está intentando crear su propio océano azul. Y resulta ingenioso señalar que, mientras se habla de “justicia”, en realidad ya se usa IA en distintos aspectos de la vida diaria.

• Me parece similar a la estructura del correo electrónico: el email se basa en estándares de internet, pero la mayoría de los usuarios está concentrada en muy pocos proveedores como Gmail. Cloudflare también está empujando estándares abiertos, pero su poder real viene del número de clientes a gran escala. (También se plantea la pregunta de cuál sería una buena alternativa). Y así como el email tiene problemas de baja confiabilidad de entrega y de dificultad de implementación por el filtrado de spam, la web podría terminar recorriendo un camino parecido.

  • En la práctica no hay una alternativa real para reemplazar a Cloudflare como CDN gratuito. Tiene servidores distribuidos por todo el mundo y los ofrece gratis, monetizando con servicios serverless premium. Además, los grandes proveedores de servicios cloud cobran tarifas de egress anormalmente caras.

• La web no necesita attestation, signed agent ni que Cloudflare decida quién es un agente “real”. Todos deberíamos volver a entender qué significa “public”, y si procesar tráfico resulta difícil, lo mejor sería aplicar solo rate limiting básico. La web no necesita distinguir si quien solicita es humano, bot o perro; solo debe entregar bytes a cualquiera que lo pida, dentro de recursos razonables. Si se pierde esta esencia de la "web abierta", todos la vamos a extrañar.

  • Incluso el rate limiting básico es vulnerable a ataques. Tampoco se pueden ignorar las botnets, y cuando todo migre a IPv6 el rate limiting útil se volverá prácticamente imposible. Si defines mal los buckets de ancho de banda, algunos operadores de red entregan prefijos /48 con demasiada facilidad y el límite deja de servir, o bien cientos de miles de usuarios móviles terminan atrapados bajo un mismo límite.

  • Ese enfoque equivale básicamente a decir que muchísimos sitios pequeños deberían cerrar porque no pueden soportar el tráfico, lo cual contradice el lema del “internet abierto”.

  • Los crawlers de IA modernos ya son indistinguibles de botnets maliciosas. El rate limiting normal ya no tiene mucho sentido, y justo por eso Cloudflare salió a intentar resolver este problema.

  • La idea de que “public significa PUBLIC” suena bien si un sitio pudiera operar solo con rate limiting básico, pero en la práctica tendría que declarar y publicar explícitamente qué velocidad de acceso es aceptable. Sin embargo, abundan los casos en los que solo por tener un user-agent distinto te bloquean incluso si haces una sola solicitud. Al final, los operadores tienden a bloquear cualquier solicitud no por el comportamiento del bot sino por la identidad (identity) en sí. El criterio es muy tosco y produce muchos falsos positivos, y en esos casos no se evalúan ni el intento ni el contexto: simplemente se bloquea por identidad.

  • Incluso el rate limiting básico muchas veces no es fácil de implementar. Salvo cuando realmente hace falta algún tipo específico de autenticación o delegación de permisos, creo que el acceso a archivos públicos no debería requerir autenticación ni delegación adicional. Y aun si existieran esos temas de delegación, no haría falta que un tercero como Cloudflare interviniera más allá del verdadero delegante.

• Estoy de acuerdo con la mayor parte de la opinión del autor. En entornos enterprise me preocupa cómo controlar el comportamiento de los agentes dentro de redes privadas complejas. Hace poco construí por mi cuenta un sistema de “identity token” basado en biscuit. Con ese token uno se autentica y luego puede crear un token de delegación para entregárselo a agentes subordinados. En mi sistema no se puede hacer nada sin un authorization token (con concepto de alcance único y uso único). En internet, imagino que se podría intercambiar un identity token + un micropago (por ejemplo, una transacción crypto muy pequeña) a cambio de un authorization token. Así, para usuarios humanos el costo sería casi nulo y no habría problema, mientras que los crawlers de IA serían los que acabarían pagando mucho.