Resumen: account takeover impulsado por agentes de IA
- La brecha: La MFA sube el listón en el paso de la contraseña, pero los agentes de IA apuntan a lo que viene después: reutilizan cookies de sesión y tokens OAuth robados para saltarse la autenticación por completo, o recorren el flujo de recuperación para revincular la cuenta a un email y un teléfono controlados por el atacante.
- La evidencia: La investigación de cside 2026 informa que las instalaciones de playwright-stealth crecieron del orden de 10 veces a lo largo de 2025. Ese es el kit que conduce instancias reales de Chromium a velocidad humana, superando la reputación de IP, las comprobaciones headless y los límites de velocidad que detienen a los bots con script.
- La decisión: Si tu señal de ATO solo se activa en el login, un agente que reproduce un token válido o restablece el factor mediante un evento de recuperación desde un dispositivo nuevo pasa sin problemas. Instrumenta la recuperación y el post-auth con el mismo escrutinio a nivel de navegador que el login, o la puerta lateral se queda abierta.
¿Poco tiempo? Consulta la detección de robo de cuentas de cside. Cubre todo lo de abajo en un solo despliegue.
Los agentes de IA rompen la seguridad de las cuentas al automatizar las partes del takeover que antes requerían una persona. Controlan navegadores reales, así que reproducen credenciales robadas, reutilizan sesiones y tokens secuestrados, y recorren los flujos de recuperación de cuenta igual que lo haría una persona. Eso derrota los controles pensados para bots básicos a nivel de request. Para detectar el account takeover (ATO) impulsado por bots, tienes que leer la propia sesión del navegador, no solo la IP y la tasa de requests.
Este artículo cubre las tres etapas en las que los agentes de IA realmente entran: el replay automatizado de credenciales, la reutilización de sesiones y tokens, y el abuso del flujo de recuperación. Para cada una, indica las señales de navegador y dispositivo que exponen al agente, y dónde las aporta cside.
¿En qué se diferencia el ATO con agentes de IA de un bot normal?
Un bot de stuffing tradicional es un script. Envía pares de usuario y contraseña a tu endpoint de login, rápido, desde un puñado de IPs, sin un navegador real detrás. Los límites de velocidad, la reputación de IP y una comprobación headless detienen la mayor parte.
Un agente de IA funciona de otra manera. Ejecuta un navegador real a través de 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 rumbo cuando aparece un desafío. Eso le permite terminar flujos que un script no puede: hacer clic en un enlace de reset en la bandeja de entrada de la víctima, volver a enviar un código de un solo uso interceptado, o completar un checkout después de una solicitud de step-up.
El tooling se volvió más barato y más fácil. La investigación de seguridad web 2026 de cside informa que las instalaciones de playwright-stealth, uno de los muchos kits de stealth-browser, crecieron del orden de 10 veces a lo largo de 2025, una medida de la rapidez con la que la automatización controlada por navegador se convirtió en equipamiento estándar del atacante. investigación 2026 de cside
Las tres etapas en las que entran los agentes de 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 un token OAuth robado para saltarse el login por completo | 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 con la cuenta de forma permanente | Dispositivo nuevo en un evento de recuperación, comportamiento de agente a mitad de 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 los fingerprints del navegador entre intentos para evitar ser agrupado, distribuye la salida entre pools de proxy residencial para superar los límites por IP, y resuelve o externaliza los 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 que ha sido redefinida, un artefacto de Runtime del Chrome DevTools Protocol (CDP), una rareza de renderizado headless o un fingerprint que cambia entre requests dentro 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 obtenida por phishing, malware o un script de skimming en tu propia página, lo reproducen y heredan una sesión autenticada sin llegar nunca a enfrentar la contraseña ni la solicitud de MFA. Este es el patrón de reutilización de tokens por agentes de IA.
Un token correcto no dice nada sobre si lo posee 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 se 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. Esto también explica por qué un script de terceros comprometido en tu página de login o checkout es tan peligroso: puede robar el token antes de que tu servidor llegue a ver un request malformado.
Etapa 3: abuso del flujo de recuperación
La recuperación es el objetivo blando, porque está diseñada para que un usuario legítimo pueda volver a entrar después de perder su factor. Un agente abusa exactamente de eso. Provoca un reset de contraseña, intercepta o manipula socialmente el enlace de reset, y re-vincula 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 que importa es el contexto: un evento de recuperación o de cambio de factor que llega desde un dispositivo y un entorno de navegador completamente nuevos, ejecutado con los tiempos y el patrón de navegación propios de la automatización, en lugar de los de un humano confundido. Instrumenta la recuperación con el mismo escrutinio a nivel 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 impulsado por 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 el ATO con agentes de IA, la evidencia está en el segundo grupo.
- Señales de automatización y stealth:
navigator.webdriver, propiedades del navegador redefinidas o parcheadas, filtraciones 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 la 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: una salida que parece residencial pero se comporta como infraestructura, usada para lavar tráfico automatizado y superar la reputación de IP.
- Contexto según la etapa: un dispositivo nuevo en un evento de recuperación, o un comportamiento de automatización que aparece específicamente en el reset, el cambio de factor o el checkout.
Ninguna fila por sí sola condena. La decisión viene del conjunto: una señal de stealth-browser más deriva de fingerprint más un evento de 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 que hay detrás, es también lo que le da a un equipo de fraude un rastro de auditoría defendible cuando un ataque se adapta a mitad de sesión.
Cómo encaja cside
cside es una plataforma de seguridad del lado del cliente que opera en la capa del navegador, donde realmente se ejecutan los agentes de IA. Combina la detección de agentes de IA con fingerprinting de dispositivo y navegador y análisis de comportamiento VPN/proxy para hacer aflorar las señales anteriores, y luego las entrega como señales en bruto vía API para que los equipos liderados por desarrollo las conecten a su propia lógica de riesgo de login, sesión y recuperación.
Como el análisis está anclado en el navegador, cside detecta navegadores stealth, replay de tokens y abuso de recuperación que las herramientas solo de red no ven. También da visibilidad sobre los scripts de terceros en tus páginas de login y checkout, la misma superficie que un atacante usa para robar un token de sesión antes de que tu servidor vea un solo request malicioso.
Lecturas adicionales en cside
- Detecta el account takeover antes de que ocurra: señales de navegador y dispositivo
- Credential stuffing: cómo detectarlo y detenerlo
- Qué es la seguridad del lado del cliente
- Las mejores herramientas para detectar agentes de IA en tu sitio web
- cside Signup Shield para el problema previo: detener cuentas nuevas falsas en el registro antes de que lleguen al login
- cside AI Agent Detection
