Los agentes IA rompen la seguridad de cuentas al automatizar las partes del takeover que antes necesitaban una persona. Controlan navegadores reales, así que reproducen credenciales robadas, reutilizan sesiones y tokens secuestrados, y recorren flujos de recuperación como lo haría un usuario. Eso derrota controles diseñados para bots básicos a nivel de request. Para detectar account takeover (ATO) impulsado por bots, tienes que leer la sesión del navegador, no solo la IP y la tasa de requests.
Este artículo cubre las tres etapas donde los agentes IA entran de verdad: replay automatizado de credenciales, reutilización de sesiones y tokens, y abuso de recuperación. En cada etapa nombra las señales de navegador y dispositivo que exponen al agente, y dónde cside las aporta.
¿En qué se diferencia el ATO con agentes IA de un bot normal?
Un bot legacy de stuffing es un script. Envía pares de usuario y contraseña al endpoint de login, rápido, desde unas cuantas IPs, sin un navegador real detrás. Límites de velocidad, reputación IP y una comprobación headless paran gran parte de ese tráfico.
Un agente IA funciona de otra manera. Ejecuta un navegador real mediante frameworks de automatización como Playwright o Puppeteer, a menudo envuelto en un kit stealth que parchea las señales obvias. Renderiza tu página, razona sobre lo que ve, rellena formularios y cambia de ruta cuando aparece un desafío. Eso le permite terminar flujos que un script no puede: hacer clic en un enlace de reset en el buzón de la víctima, reenviar un código de un solo uso interceptado o completar un checkout después de un step-up.
El tooling se volvió más barato y fácil. La investigación de seguridad web 2026 de cside informa que las instalaciones de playwright-stealth, uno de muchos kits de stealth-browser, crecieron aproximadamente 10x durante 2025, una medida de lo rápido que la automatización controlada por navegador se convirtió en equipamiento estándar de atacante. investigación 2026 de cside
Las tres etapas donde entran los agentes IA
| Etapa | Qué hace el agente | Señal que lo expone |
|---|---|---|
| Replay de credenciales | Controla un navegador real para enviar pares filtrados y superar desafíos | Banderas de automatización, deriva de fingerprint, salida de proxy residencial |
| Reutilización de sesión / token | Reproduce una cookie o token OAuth robado para saltarse el login | Desajuste de entorno frente al dispositivo de origen de la sesión |
| Abuso de recuperación | Recorre el flujo de reset o cambio de factor para quedarse la cuenta | Dispositivo nuevo en un evento de recuperación, comportamiento de agente durante el flujo |
Etapa 1: replay automatizado de credenciales
Esto es credential stuffing con un navegador por delante. En lugar de requests crudos, el agente inicia sesión a través de la página renderizada para que el tráfico parezca humano. Rota fingerprints de navegador entre intentos para evitar agrupación, distribuye la salida por pools de proxy residencial para vencer límites por IP, y resuelve o externaliza CAPTCHAs.
El entorno del navegador sigue delatando al agente. Los frameworks de automatización exponen navigator.webdriver y otras propiedades parcheadas que contradicen el navegador declarado. Los kits stealth intentan ocultarlas, pero los propios parches son detectables: una propiedad redefinida, un artefacto de Runtime de Chrome DevTools Protocol (CDP), una rareza de renderizado headless o un fingerprint que cambia entre requests de una misma sesión. Esas incoherencias son invisibles en un paquete de red y evidentes en el entorno del navegador.
Etapa 2: reutilización de sesiones y tokens
Los agentes más capaces se saltan tu login. Si roban una cookie de sesión o un token OAuth/bearer, mediante una sesión phishing, malware o un script skimmer en tu propia página, lo reproducen y heredan una sesión autenticada sin enfrentar la contraseña ni la MFA. Es el patrón de reutilización de tokens por agentes IA.
Un token correcto no dice nada sobre si lo sostiene el mismo usuario. El entorno del navegador sí. Una sesión reproducida suele mostrar un fingerprint distinto, un dispositivo distinto y una ruta de red distinta a la que autenticó originalmente. Cuando el token es válido pero el entorno que lo rodea no coincide con el dispositivo de origen de la sesión, ese desajuste es la señal. También explica por qué un script de terceros comprometido en tu página de login o checkout es tan peligroso: puede levantar el token antes de que tu servidor vea un request malformado.
Etapa 3: abuso del flujo de recuperación
La recuperación es el objetivo blando, porque está diseñada para devolver acceso a un usuario legítimo que perdió su factor. Un agente abusa exactamente de eso. Lanza un reset de contraseña, intercepta o manipula socialmente el enlace de reset, y vuelve a vincular la cuenta a un email, teléfono o passkey controlado por el atacante, convirtiendo una intrusión temporal en propiedad permanente.
Esta etapa rara vez muestra los picos de velocidad que delatan el stuffing. El volumen es bajo y deliberado. La señal importante es el contexto: un evento de recuperación o cambio de factor desde un dispositivo y entorno de navegador totalmente nuevos, ejecutado con tiempos y navegación de automatización en vez de un humano confundido. Instrumenta la recuperación con el mismo escrutinio de navegador que el login, o proteges la puerta principal y dejas abierta la lateral.
¿Qué señales de navegador y dispositivo exponen el ATO con bots?
Las señales de red describen de dónde vino el tráfico. Las señales de navegador describen quién opera realmente la sesión. En ATO con agentes IA, la evidencia vive en el segundo grupo.
- Señales de automatización y stealth.
navigator.webdriver, propiedades del navegador redefinidas o parcheadas, fugas de Runtime CDP y rarezas de renderizado headless que contradicen el navegador declarado. - Deriva de fingerprint. Un fingerprint de dispositivo o navegador que cambia entre requests dentro de una misma sesión, el patrón de rotación que usan los agentes para evitar agrupación.
- Desajuste entorno-token. Una sesión o token válido presentado desde un dispositivo, fingerprint o ruta de red que no coincide con el origen de la sesión.
- Comportamiento de proxy residencial. Salida que parece residencial pero se comporta como infraestructura, usada para lavar tráfico automatizado y superar la reputación IP.
- Contexto por etapa. Un dispositivo nuevo en un evento de recuperación, o comportamiento de automatización que aparece justo en reset, cambio de factor o checkout.
Una sola fila no condena. La decisión viene del conjunto: una señal de stealth-browser más deriva de fingerprint más recuperación desde un dispositivo nuevo casi nunca describe a un usuario real. Capturar estas señales, junto con el dispositivo y la IP real detrás, también da al equipo de fraude un rastro de auditoría defendible cuando el ataque se adapta a mitad de sesión.
Cómo encaja cside
cside es una plataforma de client-side security que opera en la capa del navegador, donde realmente se ejecutan los agentes IA. Combina detección de agentes IA con fingerprinting de dispositivo y navegador y análisis de comportamiento VPN/proxy para aflorar las señales anteriores, y las entrega como señales crudas vía API para que equipos liderados por desarrollo las conecten a su propia lógica de riesgo de login, sesión y recuperación.
Como el análisis se basa en el navegador, cside detecta stealth browsers, replay de tokens y abuso de recuperación que las herramientas solo de red no ven. También da visibilidad sobre scripts de terceros en tus páginas de login y checkout, la misma superficie que un atacante usa para levantar un token de sesión antes de que tu servidor vea un solo request malo.
