--- title: "Cloudflare quiere que los agentes de IA dejen de ser anónimos: así es su propuesta para identificarlos sin rastrearte" url: https://hernandez.systems/es/articulos/cloudflare-quiere-que-los-agentes-de-ia-dejen-de-ser-anonimos lang: es type: NewsArticle section: Infraestructura published: "2026-11-09T15:34:27+00:00" modified: "2026-11-10T15:01:25+00:00" publisher: Osky Networks image: https://oskydj.sfo3.cdn.digitaloceanspaces.com/calamardo/news_item/2026-11-09/e96-portada-43de2805.png alternate_en: https://hernandez.systems/en/articles/cloudflare-wants-ai-agents-to-stop-being-anonymous-heres-its-proposal-for-identifying-them-without --- # Cloudflare quiere que los agentes de IA dejen de ser anónimos: así es su propuesta para identificarlos sin rastrearte > Cuando un agente de IA entra a tu sitio a comprar, comparar precios o iniciar sesión, tu servidor ve al agente y no a la persona que lo mandó. El 5 de noviembre Cloudflare publicó un documento largo, "Agents aren't humans (but they kinda are)", que pone nombre a ese problema y propone cómo resolverlo sin bloquear a todos los agentes ni obligarlos a hacerse pasar por humanos. También anunció una coalición, Trusted Agent Delegation (TAD), para llevar el tema a estándares abiertos en la IETF. No es un producto nuevo: es la hoja de ruta de cómo Cloudflare cree que va a cambiar el control de acceso en la web. Si tienes una tienda, una API con plan gratuito, un login o un bot que navega sitios ajenos, esto te va a tocar. Cuando un agente de IA entra a tu sitio a comprar, comparar precios o iniciar sesión, tu servidor ve al agente y no a la persona que lo mandó. El 5 de noviembre Cloudflare publicó un documento largo, ["Agents aren't humans (but they kinda are)"](https://blog.cloudflare.com/trusted-agent-delegation/), que pone nombre a ese problema y propone cómo resolverlo sin bloquear a todos los agentes ni obligarlos a hacerse pasar por humanos. También anunció una coalición, **Trusted Agent Delegation (TAD)**, para llevar el tema a estándares abiertos en la IETF. No es un producto nuevo: es la hoja de ruta de cómo Cloudflare cree que va a cambiar el control de acceso en la web. Si tienes una tienda, una API con plan gratuito, un login o un bot que navega sitios ajenos, esto te va a tocar. ## El problema: el sitio solo ve al intermediario Cloudflare define a los "agentes personales de IA" como automatizaciones que reciben instrucciones de una persona y cumplen un objetivo controlando una computadora o un navegador en la nube. Normalmente los opera una empresa, a la que el documento llama **operador**, como parte de un servicio. Da como ejemplos a Muse, de Meta, y a dots, de OpenAI. El punto central es que esos agentes son **intermediarios**, igual que una VPN, un proxy o un navegador en la nube. La diferencia, según Cloudflare, es la escala: el tráfico de agentes crece rápido y "podría superar" pronto a la navegación humana tradicional. Antes un sitio podía bloquear el tráfico de intermediarios y pedirle a la gente que apagara su VPN. Cuando la mayoría del tráfico sea de agentes, esa salida deja de funcionar. Para explicarlo, el texto usa una analogía. Ezra es asistente personal de cuatro clientes y les hace los mandados. El tendero de la esquina ya no sabe qué le gusta a cada quien, porque solo ve a Ezra. Si un cliente le pide un iPhone y luego dice que nunca lo autorizó, la tienda no puede probar nada, porque la única persona que vio fue Ezra. Y si otro cliente le da a Ezra una lista de contraseñas para "probar cuál era", el banco solo puede vetar a Ezra, y con eso deja fuera también a los otros tres. De ahí sale lo que Cloudflare llama el **principio de intermediación**: la relación comercial entre el usuario y el sitio, y las responsabilidades de seguridad de cada uno, deben mantenerse aunque haya un intermediario en medio. ## Catorce dolores de cabeza, y casi todos los paga el sitio El documento enumera catorce problemas que antes estaban resueltos y que los agentes vuelven a abrir. Algunos de los que más le van a sonar a quien opera un sistema: - **Mezcla de tráfico.** Si un usuario usa un agente compartido para probar contraseñas robadas, raspar contenido o probar tarjetas, el sitio solo puede bloquear al agente completo, con todos sus usuarios legítimos. - **Fraude amistoso.** Alguien aprueba la compra de su agente y luego la desconoce. Antes la tienda ganaba la disputa con evidencia circunstancial (mismo dispositivo, misma IP, misma dirección), pero el agente compra desde la infraestructura del operador y esa evidencia no existe. - **Agotamiento de recursos.** Los agentes consultan precios e inventario sin parar, golpean endpoints caros como búsqueda o chat de soporte y se acaban pruebas gratuitas y promociones. - **Suplantación.** Un atacante copia el user agent de un agente conocido para obtener los mismos permisos. - **Consumo sin compensación.** El agente lee el artículo o la ficha del producto para responderle al usuario en otro lado. El sitio paga por servirlo y no recibe visita, impresión de anuncio ni compra. - **Autenticación por riesgo rota.** Los sistemas que esperan que el dispositivo y la ubicación coincidan con el usuario ven a un agente "raro" cada vez, porque corre en la nube. La conclusión del texto es directa: en casi todos los casos el costo principal lo absorbe el sitio. ## Por qué el CAPTCHA "pasado al humano" no alcanza Cloudflare descarta dos soluciones que se proponen mucho. La primera es que el agente le pase el CAPTCHA a su usuario para que lo resuelva. Según el documento, eso solo prueba que hay un humano presente en ese instante, no quién es ni por quién actúa el agente el resto del tiempo. Además, los agentes existen para quitar fricción, así que los operadores tienen incentivos para saltarse ese paso. La segunda es limitar los permisos del agente con alcances (*scopes*) muy cerrados. El problema, dice Cloudflare, es que los agentes están hechos para hacer todo lo que haría su usuario, así que en la práctica piden permiso para todo. Y aunque el alcance fuera estrecho, no responde la pregunta que de verdad le importa al sitio: quién da la cara cuando el agente se equivoca. ## Lo que propone: identidad, reputación y responsabilidad La propuesta no es inventar un protocolo único, sino combinar piezas que ya existen o se están escribiendo. Cloudflare las ordena así: - **Identidad del agente.** Su método preferido es [Web Bot Auth](https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/): el agente firma sus peticiones HTTP con una llave Ed25519 y publica sus llaves públicas en un directorio `/.well-known/http-message-signatures-directory`. Con eso se identifica el agente y, de paso, su operador. Falta resolver las cadenas: cuando el agente A usa al agente B dentro del navegador C, el sitio debería poder saberlo. - **Reputación sin rastreo.** [MOLE](https://moderation-of-unlinkable-endorsements.github.io/internet-drafts/draft-jms-mole-architecture.html) (Moderation of unLinkable Endorsements) es un borrador de la IETF publicado el 3 de noviembre de 2026 y firmado por autores de Google, Mozilla y Cloudflare. Un tercero que ya conoce al cliente (un "ancla") lo avala, y el sitio le da una credencial con la que puede limitarle el ritmo o retirarle la confianza sin saber quién es. Cloudflare lo presenta como sucesor de Private Access Tokens y [explicó en otro post](https://blog.cloudflare.com/vole-mole/) cómo piensa hacerlo resistente a computadoras cuánticas. - **Pagos.** El protocolo [x402](https://developers.cloudflare.com/agents/tools/payments/x402/) busca habilitar pagos en la web preservando la privacidad. - **Datos puntuales de la persona.** Hay acciones que necesitan un hecho concreto, como ser mayor de 18 o ser el titular de la tarjeta. Cloudflare dice que hacen falta mecanismos para que el sitio lo pida y el operador o un tercero lo confirme, sin entregar todo lo demás. - **Reglas legibles por máquina.** Hoy un agente descubre las reglas de un sitio a prueba y error, sobre todo cuando lo bloquean. `robots.txt` dice a dónde puede ir un crawler, pero no qué puede hacer un agente. El grupo [AI Preferences de la IETF](https://datatracker.ietf.org/wg/aipref/about/) trabaja en preferencias de uso (entrenamiento, inferencia, búsqueda), pero, según Cloudflare, todavía no hay un grupo dedicado a la necesidad más amplia. ![Diagrama con los cuatro niveles de identidad que propone Cloudflare (nada, sesión, cuenta y única) y los protocolos que responden cada pregunta: Web Bot Auth, MOLE, OAuth, x402 y AIPREF](https://oskydj.sfo3.cdn.digitaloceanspaces.com/calamardo/news_item/2026-11-09/e96-diagrama-5493b424.png) La identidad, además, se plantea como un espectro de cuatro niveles. En el primero el usuario no entrega ningún identificador. En el segundo se liga una sesión a un agente, como hace el session ID de [Poppy](https://personalagentprotocol.org/). En el tercero hay un identificador estable de cuenta, que permitiría "vincular tu cuenta del sitio con tu cuenta del agente". En el cuarto hay un identificador único por persona, que cruza operadores y agentes, para acciones de alto riesgo u obligaciones de cumplimiento, como una identificación oficial o una verificación de terceros. La idea es que cada sitio pida solo lo necesario para la acción. ## La coalición TAD y lo que queda fuera Cloudflare anunció la coalición [Trusted Agent Delegation](https://trustedagentdelegation.org/) para reunir a operadores de agentes, verificadores de identidad, proveedores de pagos, comercios, medios, proxies y empresas de navegadores en la nube. El plan es discutir el problema, revisar los protocolos que ya existen y llevar problemas bien definidos a la IETF, con reuniones paralelas y talleres. El anuncio no nombra a los participantes. Hay un límite importante: el documento cubre agentes alojados por un operador. Los agentes locales que corren en tu propia máquina, y cita a OpenClaw como ejemplo, quedan fuera del enfoque inicial. Cloudflare reconoce que esos agentes "parecen automatización" y no tienen una parte única a la cual pedirle cuentas. Una de las salidas que menciona es pedirles un identificador único, pero no lo desarrolla. ## Qué puedes hacer hoy Lo que ya está en producción salió el 4 de noviembre y [lo cubrimos aquí](https://osky.dj/es/noticias/infraestructura/05-11-2026/cloudflare-ya-te-deja-decidir-que-agentes-de-ia-entran-tu-sitio). En resumen, si tu sitio está detrás de Cloudflare, según el [anuncio de esa semana](https://blog.cloudflare.com/personal-agents-visibility-control/): - **Security Analytics** separa a los "Personal Assistants" como una categoría propia de tráfico y muestra qué agentes te visitan, cuántas peticiones hacen, qué rutas tocan y qué errores reciben. - En **Security Settings → AI Crawler and Agent access policies** puedes permitir, bloquear solo en páginas con anuncios o bloquear cada agente compatible por separado, sin mover tus políticas de búsqueda y entrenamiento. - Con **Account Abuse Protection** (todavía en acceso anticipado) ves qué agente hizo cada inicio de sesión o registro, y puedes mitigar una sola cuenta con una regla de WAF sobre su Hashed User ID sin bloquear al agente para todos los demás. No probé estas funciones. Lo anterior sale de la documentación y los anuncios oficiales de Cloudflare. ## Mi lectura Para quien opera sitios, el mensaje es que bloquear a todos los agentes va a salir cada vez más caro, porque detrás de muchos de ellos hay clientes reales. Para quien construye agentes o bots que navegan sitios ajenos, firmar las peticiones con Web Bot Auth va camino a ser el mínimo para que no te traten como raspador anónimo. Hay que leerlo también con lupa. Cloudflare está en medio de una parte enorme del tráfico web, propone los estándares, coescribe varios de ellos y vende las herramientas para aplicarlos. Que el trabajo vaya a la IETF y que MOLE lleve firmas de Google y Mozilla ayuda, pero falta ver quién más se sienta a la mesa de TAD y si los grandes operadores de agentes aceptan identificarse. Mientras eso no pase, el agente sigue siendo Ezra: amable, útil y anónimo. ## Fuentes - [Agents aren't humans (but they kinda are), Cloudflare](https://blog.cloudflare.com/trusted-agent-delegation/) - [Trusted Agent Delegation](https://trustedagentdelegation.org/) - [See the agents, set the terms: new visibility and control for personal agents, Cloudflare](https://blog.cloudflare.com/personal-agents-visibility-control/) - [Moderation of unLinkable Endorsements (MOLE) Architecture, borrador de la IETF](https://moderation-of-unlinkable-endorsements.github.io/internet-drafts/draft-jms-mole-architecture.html) - [The post-quantum future of web privacy, Cloudflare](https://blog.cloudflare.com/vole-mole/) - [Web Bot Auth, documentación de Cloudflare](https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/) - [AI Preferences Working Group, IETF](https://datatracker.ietf.org/wg/aipref/about/)