Resumen: señales de canvas, cadencia y cursor para bloquear agentes de IA
- Tres defensas, todas burladas: Todo stack lleva WAF, gestor de bots de CDN y CAPTCHA. OpenAI Operator, Claude for Chrome, Playwright y Puppeteer pasan los tres porque corren dentro de un motor de navegador real y resuelven retos de JavaScript a velocidad humana.
- Cuatro señales de navegador: Cuatro señales solo del navegador los delatan: entropía del canvas fingerprint, cadencia de sesión, geometría del cursor y fingerprint de fuentes y WebGL. cside las recoge desde una única etiqueta, analiza más de 250 señales por sesión, identifica el framework de automatización y devuelve un veredicto antes de que el login o el checkout se envíe.
- Política por página: En páginas de login y checkout, bloquea de forma dura las sesiones identificadas como Playwright, Puppeteer o Selenium. En sesiones automatizadas ambiguas, inyecta un reto. Los crawlers conocidos que quieres indexar, permítelos. El plan gratuito de cside de 1.000 llamadas API por mes basta para medir el volumen real de agentes primero.
¿Poco tiempo? Consulta la detección de agentes de IA de cside. Cubre todo lo de abajo en un solo despliegue.
Para bloquear agentes de IA en tu sitio web, primero tienes que detectarlos, y esa detección tiene que ocurrir dentro del navegador. Los agentes automatizados ahora corren dentro de motores de navegador reales, así que las comprobaciones en la capa de red en las que confían la mayoría de los equipos nunca los ven. Esta guía cubre las señales que delatan a un agente y cómo convertir un veredicto en un bloqueo, un reto o un permiso.
Bloquear agentes de IA en un sitio web empieza por entender por qué las herramientas que la mayoría de los equipos ya tienen no pueden hacerlo. Los WAF bloquean IPs maliciosas conocidas y patrones de peticiones. Los gestores de bots de las CDN filtran el tráfico que no procede de navegadores. Los retos CAPTCHA bloquean las peticiones que no pueden ejecutar JavaScript. Herramientas como OpenAI Operator, Claude for Chrome, Playwright y Puppeteer pasan todos estos controles, porque corren dentro de motores de navegador reales, ejecutan JavaScript, resuelven CAPTCHAs y operan a velocidades humanas. Las señales que las delatan solo existen en la capa del navegador.
Paso 1: Entiende qué señales identifican realmente a los agentes de IA
Cuatro categorías de señales distinguen de forma fiable a los agentes de IA de los usuarios humanos. Las cuatro necesitan un script que corra dentro del navegador para observarlas.
Entropía de la huella de canvas. Cada dispositivo real renderiza el canvas del navegador de forma distinta según su hardware de GPU, su sistema operativo y su motor de renderizado de fuentes. Los dispositivos reales producen huellas de canvas de alta entropía por la variación de las configuraciones de hardware entre usuarios. Los agentes de IA que corren en entornos mínimos o virtualizados producen menos entropía porque el entorno de renderizado es menos variado. Esa diferencia se puede medir en la salida del canvas.
Cadencia de la sesión. Los usuarios humanos escriben, hacen clic y navegan con una variación natural en los tiempos. Son pequeñas irregularidades orgánicas que produce la atención, la familiaridad y el control motor. Los agentes de IA ejecutan eventos del navegador a intervalos mecánicamente precisos. Un campo de formulario que se rellena con un intervalo fijo entre cada carácter, repetido de forma consistente en varias interacciones, no es un patrón humano.
Geometría del cursor. Las trayectorias del ratón de los humanos son curvas, aceleran y desaceleran, e incluyen microcorrecciones antes de aterrizar en un objetivo. Los agentes de IA producen trayectorias de cursor geométricamente rectas, o ningún movimiento de cursor entre interacciones. Los usuarios reales casi nunca producen trayectorias de cursor en línea recta.
Huella de fuentes y WebGL. Los dispositivos de usuarios reales tienen instalado un conjunto completo de fuentes del sistema y una GPU que produce una salida WebGL consistente. Los agentes de IA que corren en entornos mínimos tienen un conjunto restringido de fuentes y un hardware de GPU virtualizado o ausente. La combinación de fuentes que faltan y una firma WebGL anómala es un discriminador potente.
Paso 2: Despliega un script de detección en la capa del navegador
El script de detección tiene que cargarse con la página y empezar a recopilar señales antes de que el usuario interactúe con cualquier elemento. Este momento importa: las señales son observables a lo largo de toda la sesión, y los primeros puntos de datos establecen la línea base de comportamiento con la que se comparan los eventos posteriores.
Un script en la capa del navegador de la detección de agentes de IA de cside se carga con la página, recopila las cuatro categorías de señales de forma pasiva y está listo para devolver un veredicto por API para cuando el usuario llega a un formulario de inicio de sesión, a un pago o a cualquier otro flujo que quieras proteger.
El script se integra como una sola etiqueta en la cabecera de la página. No hace falta ningún cambio en el SDK del lado del servidor.
Paso 3: Llama a la API y lee el veredicto
Una vez que el script ha recopilado las señales, una sola llamada a la API devuelve un veredicto en tiempo real para la sesión. cside analiza más de 250 señales por sesión y las combina en una puntuación de riesgo, marcando las sesiones de agentes de IA y automatizadas e identificando automatización con nombre, como OpenAI Operator, Claude for Chrome, Playwright, Puppeteer y Selenium cuando es posible. La respuesta también indica si la conexión se enruta a través de una VPN o un proxy, y devuelve un identificador de dispositivo estable para la sesión.
El veredicto está disponible antes de que se envíe el formulario o se dispare la acción crítica, así que tu aplicación puede decidir qué hacer mientras la sesión sigue abierta.
Paso 4: Define tu respuesta según el tipo de sesión
Bloquear todas las sesiones de agentes de IA detectadas no siempre es la respuesta correcta. La acción adecuada depende de quién crees que es el agente.
Bloquear: sesiones en las que el veredicto nombra una herramienta de abuso conocida (Playwright, Puppeteer, Selenium) en un flujo de inicio de sesión o de pago. Estas herramientas no tienen ningún caso de uso legítimo de cara al usuario en esas páginas.
Retar: sesiones marcadas como automatizadas en las que el tipo de agente es ambiguo. Inyecta un reto para confirmar la presencia humana antes de permitir que la interacción continúe.
Permitir: sesiones de crawlers que reconoces y permites, como tus propias herramientas de monitorización, crawlers de motores de búsqueda que operan en páginas que deberían indexar, o integraciones de API legítimas que hayas autorizado. Producen señales de automatización pero no justifican ninguna acción.
Registrar y monitorizar: sesiones en páginas no críticas donde el bloqueo no está justificado pero la visibilidad es útil. El identificador de dispositivo y el tipo de agente te permiten construir una imagen de la actividad automatizada en tu sitio sin tomar medidas disruptivas.
Paso 5: Aplica las acciones de respuesta en tu aplicación
Una vez que llega el veredicto, tu aplicación aplica la respuesta. Implementaciones típicas:
Para flujos de inicio de sesión: comprueba el veredicto de agente antes de procesar la solicitud de autenticación. Si la sesión está marcada como una herramienta de abuso conocida, devuelve un 403 antes de validar las credenciales. No se valida ninguna contraseña, lo que reduce la carga en la base de datos por credential stuffing además de bloquear la sesión.
Para flujos de pago: comprueba el veredicto de agente y la puntuación de riesgo de la sesión antes de mostrar el formulario de pago. Las sesiones automatizadas de alto riesgo no deberían llegar a la fase del campo de pago.
Para flujos de registro: comprueba el identificador de dispositivo frente a las cuentas vinculadas conocidas antes de completar la creación de la cuenta. Esto aborda el multi-accounting además de la creación de cuentas impulsada por agentes de IA y los registros falsos.
Dónde encaja el bloqueo en tu stack
La detección en la capa del navegador no sustituye a tu WAF ni a tu gestor de bots de CDN. Se sitúa junto a ellos y cubre el hueco al que no pueden llegar: el tráfico automatizado que llega dentro de una sesión de navegador genuina. Mantén los controles de la capa de red para el tráfico volumétrico y no procedente de navegadores que gestionan bien, y añade veredictos de la capa del navegador para los agentes que superan esos controles. Las dos capas juntas te dan una decisión por sesión en los flujos de inicio de sesión, de pago y de registro sin sobrebloquear los crawlers que quieres conservar.
Lecturas relacionadas
- Detección de agentes de IA: cómo cside puntúa las sesiones de agentes y automatizadas desde una sola etiqueta de script
- Account takeover: detener el abuso automatizado de inicio de sesión y el credential stuffing
- Multi-accounting: vincular dispositivos para detectar la creación de cuentas impulsada por agentes
