Um agente de IA que consegue fazer login em sites

Quase tudo que vale a pena fazer na web está atrás de um login: o painel, o portal, o back-office sem API. Veja por que a maioria dos agentes para na tela de login, o que é preciso para passar por ela de forma honesta e onde ainda falha.

Peça para a maioria dos agentes de IA "conferir os números no portal do fornecedor" e eles vão fazer uma de duas coisas: explicar como fariam, ou tentar, bater em um formulário de login e desistir. A web pública é fácil. A web com login, onde ficam de fato suas notas fiscais, seus pedidos, seus clientes e as ferramentas da sua equipe, é onde os agentes se calam.

Isso não é uma questão de qualidade do modelo. Vem da forma como o agente é construído. Trabalhar atrás de um login exige três coisas, e a maioria dos agentes não tem pelo menos duas delas.

O que realmente é necessário para fazer login

1. Um navegador de verdade, não um fetch

Uma página de login não é um documento; é uma pequena aplicação. Ela define cookies, executa scripts, às vezes verifica se há um navegador real do outro lado e, com frequência, redireciona por um segundo domínio antes de deixar você entrar. Um agente que busca o HTML e o interpreta nunca passa do primeiro passo. Um agente que controla um navegador genuíno, o mesmo Chromium que uma pessoa usaria, passa, porque, do ponto de vista do site, ele é o navegador de uma pessoa.

2. Uma sessão que sobrevive

Fazer login uma vez não é a parte difícil. Difícil é continuar logado. A maioria dos agentes roda em um sandbox criado para uma tarefa e destruído depois, o que significa que toda tarefa começa deslogada e toda tarefa começa com o pedido de senha, o pedido de dois fatores e o e-mail de "novo dispositivo". Isso não é só irritante; é o que faz as contas serem sinalizadas. Um site que vê um dispositivo novo fazendo login vinte vezes por dia trata aquilo como um ataque.

A solução é simples e estrutural: o agente precisa de uma máquina que persista. Mesmo navegador amanhã, mesmos cookies, mesmo "dispositivo lembrado". Você faz login uma vez, e a sessão simplesmente está lá na próxima vez, como acontece no seu próprio notebook. Essa é a maior diferença entre um agente com computador próprio e um que usa emprestado um sandbox temporário.

3. Uma pessoa para o que só uma pessoa pode fazer

Algumas etapas não devem ser automatizadas, e um bom agente sabe disso. A senha em si. O código do seu celular. O CAPTCHA. A tela de consentimento de um banco. Um agente que tenta passar por essas etapas com script ou vai falhar ou vai fazer algo que você não autorizou.

O desenho honesto é a transferência: o agente chega à tela de login, para e passa o teclado para você. Você digita a senha na própria tela do agente, aprova o código e devolve o controle. Ele segue a partir daí e, como a máquina persiste, você faz isso uma vez, não toda vez. Na MyClawn essa transferência é literal: o desktop é transmitido para o seu navegador e você assume clicando nele. Você pode ver como isso funciona.

Como as abordagens se comparam

Scrapers e wrappers de API

Rápidos e baratos quando o site tem uma API pública ou uma página HTML simples. Inúteis atrás de um login que exige navegador, e frágeis assim que o site muda um campo de formulário. Bons para ler preços públicos; errados para o seu portal.

Uma extensão no seu próprio navegador

Resolve o problema do login usando as suas sessões: o agente já está logado como você, em tudo. E aí está exatamente o problema. Funciona só enquanto o seu notebook estiver aberto, age dentro da conta que você usa para todo o resto, e uma página que ele visita pode convencê-lo a fazer coisas com a sua identidade logada. Conveniente, mas não é algo para deixar rodando sem supervisão.

Um desktop na nuvem persistente, próprio do agente

O agente tem a própria máquina, o próprio navegador e as próprias sessões, separados dos seus. Ele continua logado entre as tarefas, segue trabalhando depois que você fecha o notebook, e os logins que ele mantém são os que você escolheu dar a ele, em uma tela que você pode acompanhar e assumir a qualquer momento. É isso que é a MyClawn. Custa mais do que um fetch (uma máquina de verdade precisa existir), e é a única das três que se sustenta para o tipo de trabalho "conferir o portal todas as manhãs".

O que ainda quebra

• Sites que proíbem automação. Alguns serviços banem o acesso automatizado nos termos de uso, e alguns o detectam bem. Um agente que usa um navegador real passa na maioria das verificações, mas "maioria" não é "todas", e um banimento atinge a sua conta, não a do agente. Leia os termos para qualquer coisa que importe.
• Sessões que expiram de propósito. Bancos e algumas ferramentas corporativas desconectam você após alguns minutos e exigem um código novo a cada vez. A persistência ajuda menos nesses casos; espere ter que passar o teclado com frequência.
• Dois fatores que ficam no seu celular. O agente não consegue e não deve ler o seu autenticador. Cada aprovação de novo dispositivo é uma etapa humana, uma vez por máquina.
• Qualquer coisa irreversível. Estar logado é uma coisa; clicar em "pagar" ou "excluir" é outra. Configure o agente para parar antes disso e deixar você confirmar na tela. O sentido de poder acompanhar é justamente esse.

Quando esta é a ferramenta errada

Se o trabalho é ler páginas públicas, um scraper é mais barato. Se você precisa que o agente aja como você dentro das suas próprias contas por alguns minutos enquanto acompanha, uma extensão de navegador serve. O computador persistente se justifica quando o trabalho é recorrente, fica atrás de um login e deve continuar acontecendo quando você não está, e quando você quer uma separação entre a identidade do agente e a sua.

Leia como funcionam as sessões, as credenciais e a transferência de controle em Segurança e confiança, ou dê a um agente um computador próprio e faça login no primeiro portal você mesmo.