Os agentes IA quebram a segurança de contas ao automatizar as partes do takeover que antes precisavam de uma pessoa. Controlam navegadores reais, por isso reproduzem credenciais roubadas, reutilizam sessões e tokens sequestrados e percorrem fluxos de recuperação como um utilizador faria. Isso derrota controlos desenhados para bots básicos ao nível do pedido. Para detetar account takeover (ATO) impulsionado por bots, tem de ler a sessão do navegador, não só o IP e a taxa de pedidos.
Este artigo cobre as três etapas onde os agentes IA entram de verdade: replay automatizado de credenciais, reutilização de sessões e tokens, e abuso de recuperação. Em cada etapa nomeia os sinais de navegador e dispositivo que expõem o agente, e onde a cside os fornece.
Em que é que o ATO com agentes IA difere de um bot normal?
Um bot legacy de stuffing é um script. Envia pares de utilizador e palavra-passe para o endpoint de login, rápido, a partir de um punhado de IPs, sem nenhum navegador real por trás. Limites de velocidade, reputação de IP e uma verificação headless param a maior parte.
Um agente IA funciona de forma diferente. Executa um navegador real através de frameworks de automatização como Playwright ou Puppeteer, frequentemente envolvido num kit stealth que corrige os indícios óbvios. Renderiza a sua página, raciocina sobre o que vê, preenche formulários e muda de rumo quando aparece um desafio. Isso permite-lhe terminar fluxos que um script não consegue: clicar num link de reset na caixa de entrada da vítima, reenviar um código de uso único interceptado ou completar um checkout depois de um step-up.
O tooling ficou mais barato e mais fácil. A investigação de segurança web 2026 da cside relata que as instalações de playwright-stealth, um de muitos kits de stealth-browser, cresceram cerca de 10x durante 2025, uma medida da rapidez com que a automatização controlada por navegador se tornou equipamento padrão de atacante. investigação 2026 da cside
As três etapas onde os agentes IA entram
| Etapa | O que o agente faz | Sinal que o expõe |
|---|---|---|
| Replay de credenciais | Controla um navegador real para enviar pares fugados e ultrapassar desafios | Flags de automatização, deriva de fingerprint, saída de proxy residencial |
| Reutilização de sessão / token | Reproduz um cookie ou token OAuth roubado para saltar o login | Desfasamento de ambiente face ao dispositivo de origem da sessão |
| Abuso de recuperação | Percorre o fluxo de reset ou mudança de fator para ficar com a conta | Dispositivo novo num evento de recuperação, comportamento de agente durante o fluxo |
Etapa 1: replay automatizado de credenciais
Isto é credential stuffing com um navegador à frente. Em vez de pedidos crus, o agente inicia sessão através da página renderizada para que o tráfego pareça humano. Roda fingerprints de navegador entre tentativas para evitar agrupamento, distribui a saída por pools de proxy residencial para vencer limites por IP, e resolve ou externaliza CAPTCHAs.
O ambiente do navegador continua a denunciar o agente. Os frameworks de automatização expõem navigator.webdriver e outras propriedades corrigidas que contradizem o navegador declarado. Os kits stealth tentam ocultá-las, mas as próprias correções são detetáveis: uma propriedade redefinida, um artefacto de Runtime do Chrome DevTools Protocol (CDP), uma particularidade de renderização headless ou uma fingerprint que muda entre pedidos numa mesma sessão. Essas incoerências são invisíveis num pacote de rede e evidentes no ambiente do navegador.
Etapa 2: reutilização de sessões e tokens
Os agentes mais capazes saltam o seu login. Se roubarem um cookie de sessão ou um token OAuth/bearer, através de uma sessão phishing, malware ou um script skimmer na sua própria página, reproduzem-no e herdam uma sessão autenticada sem nunca enfrentar a palavra-passe ou a MFA. É o padrão de reutilização de tokens por agentes IA.
Um token correto não diz nada sobre se o mesmo utilizador o sustenta. O ambiente do navegador sim. Uma sessão reproduzida costuma mostrar uma fingerprint diferente, um dispositivo diferente e um caminho de rede diferente do que autenticou originalmente. Quando o token é válido mas o ambiente à sua volta não coincide com o dispositivo de origem da sessão, esse desfasamento é o indício. Isto também explica porque é que um script de terceiros comprometido na sua página de login ou checkout é tão perigoso: pode levantar o token antes de o seu servidor ver um pedido malformado.
Etapa 3: abuso do fluxo de recuperação
A recuperação é o alvo mole, porque é desenhada para devolver acesso a um utilizador legítimo que perdeu o seu fator. Um agente abusa exatamente disso. Dispara um reset de palavra-passe, intercepta ou faz engenharia social do link de reset, e volta a vincular a conta a um email, telefone ou passkey controlado pelo atacante, transformando uma intrusão temporária em propriedade permanente.
Esta etapa raramente mostra os picos de velocidade que delatam o stuffing. O volume é baixo e deliberado. O sinal que importa é o contexto: um evento de recuperação ou mudança de fator vindo de um dispositivo e ambiente de navegador totalmente novos, executado com o timing e o padrão de navegação de automatização em vez de um humano confuso. Instrumente a recuperação com o mesmo escrutínio de navegador do que o login, ou protege a porta da frente e deixa a lateral aberta.
Que sinais de navegador e dispositivo expõem o ATO com bots?
Os sinais de rede descrevem de onde veio o tráfego. Os sinais de navegador descrevem quem está realmente a operar a sessão. No ATO com agentes IA, a evidência vive no segundo grupo.
- Sinais de automatização e stealth.
navigator.webdriver, propriedades do navegador redefinidas ou corrigidas, fugas de Runtime CDP e particularidades de renderização headless que contradizem o navegador declarado. - Deriva de fingerprint. Uma fingerprint de dispositivo ou navegador que muda entre pedidos dentro de uma mesma sessão, o padrão de rotação que os agentes usam para evitar agrupamento.
- Desfasamento ambiente-token. Uma sessão ou token válido apresentado a partir de um dispositivo, fingerprint ou caminho de rede que não coincide com a origem da sessão.
- Comportamento de proxy residencial. Saída que parece residencial mas comporta-se como infraestrutura, usada para branquear tráfego automatizado e ultrapassar a reputação de IP.
- Contexto por etapa. Um dispositivo novo num evento de recuperação, ou comportamento de automatização que surge especificamente no reset, mudança de fator ou checkout.
Uma única linha não condena. A decisão vem do conjunto: um sinal de stealth-browser mais deriva de fingerprint mais recuperação a partir de um dispositivo novo quase nunca descreve um utilizador real. Capturar estes sinais, juntamente com o dispositivo e o IP real por trás deles, é também o que dá a uma equipa de fraude um rasto de auditoria defensável quando um ataque se adapta a meio da sessão.
Como a cside se encaixa
A cside é uma plataforma de client-side security que opera na camada do navegador, onde os agentes IA realmente correm. Combina deteção de agentes IA com fingerprinting de dispositivo e navegador e análise comportamental de VPN/proxy para trazer à superfície os sinais acima, e entrega-os como sinais em bruto via API para que equipas lideradas por desenvolvimento os liguem à sua própria lógica de risco de login, sessão e recuperação.
Como a análise se baseia no navegador, a cside apanha stealth browsers, replay de tokens e abuso de recuperação que as ferramentas só de rede não veem. Também dá visibilidade sobre scripts de terceiros nas suas páginas de login e checkout, a mesma superfície que um atacante usa para levantar um token de sessão antes de o seu servidor ver um único pedido mau.
