Políticas de agentes personales de Cloudflare: cómo permitir, limitar o bloquear asistentes de IA en tu web

Los controles de bots más recientes de Cloudflare buscan sacar a los propietarios de sitios de una trampa concreta. Como explica Cloudflare en su artículo sobre Trusted Agent Delegation, cuando un usuario abusa de un agente compartido para relleno de credenciales (credential stuffing), scraping o pruebas de tarjetas, el sitio puede detectar el abuso, pero solo puede bloquear al agente, lo que también bloquea a todos sus usuarios legítimos. Con cada vez más clientes que envían asistentes de IA a navegar, comparar y comprar por ellos, verse obligado a esa elección sale caro.

Los nuevos controles te permiten elegir una política distinta para cada agente personal compatible, en lugar de conformarte con un bloqueo de todo o nada. A continuación explico cómo funcionan, un modelo de despliegue que puedes reutilizar y dónde las pruebas siguen siendo escasas.

Por qué los agentes personales necesitan su propia política

Los rastreadores y los agentes pueden parecerse en tus registros, pero plantean preguntas distintas. Un rastreador de entrenamiento recopila contenido para construir un modelo. Un rastreador de búsqueda indexa páginas para mostrarlas más adelante.

Con los rastreadores, te preguntas si quieres que se use tu contenido. Con los agentes personales, te preguntas si quieres atender a un cliente que eligió enviar software en su lugar. El lado de los rastreadores tiene su propio conjunto de decisiones, que tratamos en nuestro mapa de migración de rastreadores de Cloudflare para equipos de búsqueda.

No te aferres demasiado al argumento del volumen. Cloudflare sostiene que el tráfico agéntico crece con rapidez y podría superar a la navegación humana tradicional en un futuro próximo. En septiembre, el CEO de Cloudflare, Matthew Prince, pronosticó que el tráfico de bots alcanzaría 1,000 veces el tráfico humano en cinco años. Son previsiones de una empresa que vende herramientas para gestionar ese tráfico. No son mediciones.

La idea más útil es lo que Cloudflare llama el Principio de Intermediación (Intermediation Principle): la relación comercial entre usuarios y sitios, y las responsabilidades de seguridad de cada participante, deben mantenerse con independencia de la intermediación. Tu cliente sigue siendo tu cliente cuando un asistente hace los clics. Gran parte de este lanzamiento es un intento de hacer viable ese principio.

La escala es la razón para prestar atención aunque no uses Cloudflare. La empresa afirma que más del 20% de los dominios web están detrás de su red, así que los valores predeterminados y las categorías que define condicionan cómo trata a los agentes una gran parte de la web.

Qué ha cambiado en las políticas de acceso

La configuración se encuentra en Security Settings. Como explica el anuncio de Cloudflare sobre agentes personales, defines una política general de Agents y después eliges una política distinta para cada agente personal compatible. Cada agente recibe una de estas acciones:

• Allow (do not block): el tráfico coincidente pasa. A partir de aquí lo llamaré Allow (permitir).
• Block on pages with ads: el agente se detiene en las páginas con anuncios, pero puede seguir accediendo al resto del sitio.
• Block: el tráfico coincidente se bloquea en todo el sitio.

Como contexto, el panel subyacente de Account Abuse Protection se presentó el 2 de octubre de 2026.

Cómo funciona la herencia

Aquí es donde los equipos se llevan sorpresas. Según la documentación de políticas de acceso de Cloudflare, los agentes personales heredan la política de Agents de forma predeterminada, y cambiar la política de Agents actualiza cada agente personal. Puedes volver a configurar acciones individuales después, pero tus excepciones por agente no sobrevivirán a una edición de la política principal.

Cloudflare recomienda Allow para los agentes personales. Para la mayoría de las empresas es el valor predeterminado correcto, por las razones que explica la matriz de decisión más abajo.

Cómo leer la categoría Personal Assistants

En Security Analytics, el gráfico de Bot Analysis muestra ahora Personal Assistants como una nueva categoría, junto a Verified Bot, Likely Human, Likely Automated y Automated. Abre esta vista antes de tocar cualquier política. Comprueba cuánto tráfico de asistentes reconocidos recibes y si es estable o se dispara en torno a eventos concretos. Sobre todo, comprueba a qué rutas llega.

Las rutas deciden la política. Un asistente que lee artículos financiados con publicidad es una cuestión de ingresos. Uno que llega al inicio de sesión y al checkout es una cuestión de fraude y conversión. El mismo volumen puede justificar configuraciones muy distintas según dónde aterrice.

Hay una limitación desde el primer día. La documentación de Cloudflare indica que las solicitudes de asistentes que no reconoce aparecen como tráfico ordinario. Trata la categoría como un mínimo, no como un recuento completo.

Control a nivel de cuenta con Hashed User ID

Esta es la parte del lanzamiento que ataca directamente la trampa del agente compartido. Si parece que un atacante está usando un agente en una cuenta, los analistas de fraude pueden mitigar esa cuenta con una regla WAF sobre su Hashed User ID, sin bloquear el agente para todos los demás que dependen de él. La cobertura independiente de Unite.AI describe el mismo mecanismo: la regla se dirige al Hashed User ID de la cuenta, no al agente en su conjunto.

Hay dos acciones. Managed Challenge añade fricción, mientras que Block detiene por completo las solicitudes de la cuenta. La documentación de Account Abuse Protection de Cloudflare indica que solo se ve afectada la cuenta objetivo, incluso cuando usa un asistente de IA del que dependen otros usuarios.

El panel también muestra señales sobre credenciales. En el propio ejemplo de panel de Cloudflare, aproximadamente 2.4K eventos dieron como resultado un nombre de usuario o una contraseña filtrados, frente a 11.7K eventos en los que las credenciales se clasificaron como limpias. Eso te enseña cómo es la vista. No es una referencia para tu propio tráfico.

Planifica en torno a dos restricciones. Primero, Account Abuse Protection está en Early Access para clientes de Bot Management Enterprise, sin coste adicional durante un periodo limitado hasta que esté disponible de forma general. Presupuesta como si el precio fuera a cambiar. Segundo, la documentación de Cloudflare limita la visibilidad de asistentes de IA a los eventos de inicio de sesión y registro, así que el abuso en otras partes de una sesión no se atribuirá a un asistente mediante esta función.

Matriz de decisión por modelo de negocio

La configuración adecuada depende de cómo gana dinero tu sitio. Trata las posiciones siguientes como entradas para el paso de Excepción del manual que aparece más abajo. Son puntos de partida. Si tu propia línea base indica otra cosa, sigue tus datos.

Editores financiados con publicidad

Cuando un asistente lee tu artículo y lo resume para su usuario, esa visita puede no generar ingresos publicitarios. La propia Cloudflare se ha inclinado en esta dirección. Su anuncio de julio de 2026 indicaba que, para todos los dominios nuevos que se incorporaran a Cloudflare, las categorías Training y Agent se bloquearían de forma predeterminada en las páginas que muestran anuncios, mientras que Search seguiría permitida. La documentación actual describe valores predeterminados distintos, sobre los que vuelvo más abajo, así que revisa tus propias zonas.

SaaS

En un producto SaaS, un agente que inicia sesión es, con toda probabilidad, un cliente de pago que automatiza su propio trabajo. Bloquear los agentes de forma generalizada te expone a flujos de trabajo rotos y a una oleada de tickets de soporte. La configuración Allow recomendada encaja con este modelo. Cuando aparezca abuso, actúa sobre el Hashed User ID en lugar de sobre todo el agente.

Ecommerce

Los agentes ya llegan al checkout. Los datos de Microsoft Clarity mostraron que el checkout aparecía en el 25% de las sesiones de agentes de IA, frente al 15% en las de humanos. Si bloqueas un agente, puede que estés bloqueando a compradores.

Los bloqueos generales ocurren. A principios de octubre, Muse de Meta representaba el 72% de las solicitudes de agentes de IA en los datos de HUMAN, y Amazon impidió que Muse comprara en su sitio. Sugerimos tratar cualquier bloqueo general aislado como la decisión de una empresa concreta, no como una plantilla para la tuya.

La exposición al fraude también es real. Arkose Labs informó de que el 65.2% de sus clientes vio agentes de IA llegar a flujos de inicio de sesión, registro y checkout. Es una proporción de clientes de Arkose, no de sesiones. Sugerimos leerlo como una indicación de tendencia y no como una referencia para tu propio sitio. Aun así, es un argumento para combinar Allow con una supervisión activa de cuentas, en lugar de plantear la decisión como abierto frente a cerrado.

Contenido y comercio mixtos

Muchos sitios combinan artículos financiados con publicidad con checkout, un área de miembros o un producto con sesión iniciada. Una única acción para todo el sitio rara vez les conviene. Un punto de partida razonable es mantener la política general de Agents en Allow, para que los agentes puedan llegar a las páginas de inicio de sesión, cuenta y checkout, y aplicar Block on pages with ads solo a los agentes cuya línea base muestre mucha lectura de páginas con anuncios. Esa acción sigue a los anuncios, no a la sección del sitio. Confirma que tus páginas de comercio y de sesión iniciada no llevan anuncios, o el bloqueo también las alcanzará. Reparte la responsabilidad siguiendo la misma línea: el equipo de contenido o de ingresos se encarga de las excepciones en páginas con anuncios, y el equipo de fraude de las respuestas a nivel de cuenta.

Tabla resumen

Manual: Línea base, Herencia, Excepción, Contención y Revisión

Sugerimos ejecutarlo como un ciclo de cinco pasos. Cada paso produce un resultado concreto, para que sepas cuándo está terminado y por dónde retomarlo en la siguiente revisión.

Paso 1: Línea base

Revisa el tráfico de Personal Assistants en Bot Analysis durante un periodo lo bastante largo como para cubrir los ciclos semanales normales y cualquier promoción. Agrupa las páginas que tocan los asistentes en páginas con anuncios, inicio de sesión y registro, páginas de producto y checkout. Resultado: una vista guardada de Bot Analysis y las rutas principales por agente.

Paso 2: Herencia

Define primero la política general de Agents, ya que todos los agentes personales la heredan. Anótala como primera línea de un registro de excepciones, con la fecha y la persona que la aprueba. Trata cualquier edición posterior como una solicitud de cambio y guarda la configuración actual por agente antes de que nadie la toque, porque la edición la restablece. Resultado: una política principal registrada y un acuerdo de que solo cambia mediante revisión.

Paso 3: Excepción

Empieza con todos los agentes en Allow. Pasa uno a Block on pages with ads o a Block solo cuando una entrada del registro lo justifique. Esta es una plantilla ilustrativa, no el registro de un cliente real:

Resultado: una entrada por excepción. Todo lo que no tenga entrada vuelve a la política principal en la siguiente revisión.

Paso 4: Contención

Si tienes Bot Management Enterprise, activa Account Abuse Protection y prepara reglas WAF dirigidas a un Hashed User ID. Empieza con Managed Challenge y escala a Block solo cuando las pruebas lo respalden. Redacta la escalada como un runbook de interruptor de emergencia para agentes de IA, con disparadores y responsables claros, para que el analista de guardia no tenga que improvisar. Registra cada regla de cuenta igual que registras una excepción: referencia de la cuenta, acción, disparador, responsable y fecha de caducidad. Resultado: una ruta de escalada por escrito y un registro de reglas.

Paso 5: Revisión

Revisa cada mes o cada trimestre, según el tráfico. Comprueba los valores predeterminados en los dominios añadidos recientemente, vuelve a aplicar las excepciones registradas tras cualquier cambio en la política principal, retira las reglas de cuenta que ya no necesites y revisa la configuración tras lanzamientos importantes de agentes. Después vuelve al Paso 1 con una línea base nueva.

La asignación de responsables es lo que mantiene honesto el ciclo. Los equipos de marketing o de ingresos deberían encargarse de las decisiones sobre páginas con anuncios, porque pueden sopesar las visitas frente a los ingresos. Los equipos de seguridad o de fraude deberían encargarse de las acciones a nivel de cuenta, porque son quienes tienen las pruebas.

Errores comunes

Tratar Allow como identidad. Como señala Forkast, una política de agentes controla si se permite el tráfico coincidente, pero no establece por sí sola la identidad de la cuenta de usuario ni quién autorizó la acción concreta. Tu autenticación habitual sigue aplicándose, ya sean contraseñas con MFA o un despliegue de passkeys con una recuperación sólida.

Suponer que las firmas verifican a la persona. Una firma de Web Bot Auth autentica la identidad del agente o del bot. No te dice nada sobre la persona que hay detrás.

Bloquear un agente compartido para frenar a un solo abusador. Eso deja sin acceso a todos los usuarios legítimos del agente. Usa la mitigación a nivel de cuenta siempre que puedas.

Olvidar la herencia. Si editas la política principal de Agents, tendrás que volver a aplicar cada elección por agente.

Interpretar una cifra baja de Personal Assistants como poco tráfico de agentes. Los asistentes no reconocidos aparecen como tráfico ordinario, así que una categoría pequeña puede ocultar un panorama mayor.

Advertencias y límites

La brecha de visibilidad. Solo los asistentes que Cloudflare reconoce reciben etiqueta y control por agente. Tu política cubre los agentes que Cloudflare puede identificar, no todos los asistentes automatizados.

Fuentes contradictorias sobre los valores predeterminados. El blog de julio de 2026 decía que los dominios nuevos bloquearían Training y Agent en las páginas con anuncios de forma predeterminada. La documentación actual indica que, para los dominios nuevos, Search, Agents y Training usan Allow de forma predeterminada. Cuando ambas fuentes no coincidan, confía en tu panel.

Límites de detección. En la prueba propia de Resemble AI, las herramientas contra bots detectaron entre el 3.1% y el 14.8% de los agentes de IA camuflados. Es una cifra de un proveedor sin tamaño de muestra publicado, pero la tendencia es clara: los agentes diseñados para parecer humanos son difíciles de detectar.

La brecha de identidad. Arkose Labs descubrió que el 97.7% de las sesiones legítimas de agentes de IA no llevaban ningún ID verificado entre el 1 de julio y el 30 de septiembre. Sugerimos planificar partiendo de que el tráfico legítimo de agentes puede llegarte sin ninguna identidad verificada.

Estándares incipientes. El artículo sobre Trusted Agent Delegation menciona una coalición que trabaja en la delegación de agentes, pero no nombra a ningún miembro, y el propio sitio web de la coalición tampoco. Ese sitio indica que los estándares abiertos se están desarrollando en el IETF y el W3C. Es de esperar que los mecanismos cambien a medida que madure ese trabajo.

Cifras sin enlace. Varias cifras y citas de terceros de este artículo están atribuidas, pero no enlazan a sus publicaciones originales. Comprueba la metodología y las fechas en la fuente antes de reutilizarlas. Las previsiones de tráfico también proceden de la propia Cloudflare, así que úsalas como orientación, no para planificar capacidad.