A IA para o suporte de recuperação de conta é segura quando toda ação que ela pode realizar continua ajudando o verdadeiro dono, mesmo que a pessoa que pede esteja mentindo. Enviar seu e-mail normal de redefinição para o endereço que já está na conta passa nesse teste: um atacante pode pedir isso o dia inteiro e o link continua caindo na caixa de entrada do dono. Trocar o e-mail, redefinir o 2FA ou "simplesmente desativá-lo" não passa. Então deixe a IA resolver senhas esquecidas e bloqueios, triar e redigir os casos de 2FA e troca de e-mail e mandar direto para uma pessoa qualquer coisa que cheire a invasão de conta.
A divisão importa porque as centrais de suporte são uma porta de entrada conhecida. O alerta sobre o Scattered Spider da agência americana de cibersegurança CISA descreve atacantes que ligam para centrais de ajuda para redefinir senhas e mover o MFA para seus próprios dispositivos. Uma IA que pode ser convencida a fazer o mesmo é uma versão mais rápida dessa brecha.
A eesel funciona assim dentro do Zendesk, Freshdesk, HubSpot e outros helpdesks: chama apenas o endpoint de redefinição que você permite, retém ações arriscadas para aprovação e nunca vê suas chaves de API. A XAP, que opera portais de estudantes para estados e faculdades dos EUA, deixa seu agente da eesel cuidar das redefinições de senha do portal no Freshdesk enquanto as exclusões de conta ficam com a equipe, e uma pessoa envia cada resposta.
Por que os tickets de recuperação de conta são tão difíceis de automatizar?
Porque são o único tipo de ticket em que ser prestativo e ser seguro puxam em direções opostas. O cliente está bloqueado, muitas vezes estressado, e quer a conta de volta agora. O atacante escreve exatamente a mesma mensagem.
Eles também são muito volume. Bron Gondwana, do provedor de e-mail Fastmail, deu um número no Hacker News:
"In 2016 before we had automated account recovery, lost password was in the top 3 categories of ticket every single week! Every member of the support team dealt with multiple account-loss tickets per day, both forgotten password or stolen account."
Esse par, senha esquecida e conta roubada na mesma fila, é todo o problema. Eu trabalho na fila de suporte da eesel todos os dias, e "não consigo entrar" é uma daquelas mensagens em que a resposta que parece mais gentil às vezes é a que você não pode enviar. Uma pessoa sente a hesitação. Um chatbot feito para resolver tickets fecha alegremente a questão para quem estiver do outro lado.
O outro lado é o quanto os clientes se cansam de fluxos de recuperação ruins. Um usuário do Hacker News resumiu a frustração com backups de MFA e centrais de suporte de uma vez:
"Plus a ton of vendors allow customer support to trivially turn off MFA via social-engineering, so what is the point?"
Então o trabalho não é "automatizar a recuperação de conta". É automatizar as partes em que um palpite errado não custa nada e desacelerar as partes em que um palpite errado entrega a conta a alguém. A boa notícia é que a maior parte do volume está no primeiro grupo. Se você só lida com redefinições de senha, meu post sobre IA para solicitações de redefinição de senha cobre esse tipo de ticket em mais detalhes. Este guia cobre toda a fila de recuperação.
Qual é o único teste que uma ação de recuperação da IA precisa passar?
Pergunte: se a pessoa neste chat for um atacante, essa ação ainda ajuda apenas o verdadeiro dono? Se sim, a IA pode executá-la. Se não, uma pessoa decide.
O teste parece simples e separa quase toda ação de recuperação com clareza:
| Ação que o cliente pede | Ainda ajuda apenas o verdadeiro dono? | Quem executa |
|---|---|---|
| Enviar o link de redefinição padrão | Sim, vai para o endereço cadastrado | IA, sozinha |
| Explicar por que a conta está bloqueada e quando será desbloqueada | Sim, é informação, não acesso | IA, sozinha |
| Orientar o uso de um código de recuperação salvo | Sim, só o dono tem o código | IA, sozinha |
| Reenviar um código para um endereço de recuperação já cadastrado | Sim | IA, sozinha |
| Trocar o e-mail ou o número de telefone da conta | Não, o novo endereço pode ser de qualquer um | Uma pessoa, após verificações |
| Redefinir ou remover o 2FA | Não, tira a segunda trava | Uma pessoa, após verificações |
| Dizer ao cliente se um e-mail tem conta | Não, revela quem são seus clientes | Ninguém, nunca |
| Colar um link de redefinição ou código no chat | Não, o chat é o canal não confiável | Ninguém, nunca |
As duas últimas linhas vêm direto da OWASP Forgot Password Cheat Sheet, a referência da comunidade de segurança para fluxos de redefinição. Ela diz para retornar uma mensagem consistente tanto para contas existentes quanto inexistentes, então uma resposta como "se esse e-mail tiver uma conta, um link de redefinição está a caminho" é a correta mesmo quando a IA consegue ver que a conta existe.
A tabela também diz o que conectar. Um agente de IA que só tem um botão "enviar e-mail de redefinição" não pode ser convencido a executar as linhas perigosas, porque não tem botão para elas. Isso é uma garantia muito mais forte do que uma instrução pedindo cuidado. Instruções podem ser contestadas. Uma permissão ausente, não. Volto a isso na seção de configuração.
Quais solicitações de recuperação de conta a IA pode tratar?
Ordene-as pelo que dá errado se a IA for enganada. Eu começaria toda equipe com três faixas:
Faixa 1: a IA resolve. Senhas esquecidas, bloqueios após tentativas falhas e clientes que ainda têm um código de recuperação ou um segundo dispositivo. A solução viaja por algo que o dono já controla. A IA dispara a redefinição, explica o bloqueio ou orienta o uso do código e depois fecha o ticket. É aqui que está a maior parte do seu volume e onde uma IA devolve mais horas. É também a faixa para rodar 24/7, porque ninguém bloqueado num sábado quer esperar até segunda.
Faixa 2: a IA prepara, uma pessoa decide. Um telefone 2FA perdido sem códigos de recuperação, sem acesso ao e-mail cadastrado ou um novo número de telefone. Não sobrou nenhum canal que comprove a posse, então alguém precisa verificar. A IA ainda faz a maior parte do trabalho: lê a conta, lista quais opções de recuperação existem, abre o caso, redige o pedido de documento e escreve uma nota interna para que o agente que assumir comece com os fatos. Tem o mesmo formato de uma transferência para uma pessoa em reembolsos, só que com uma regra mais rígida sobre quem aperta o botão.
Faixa 3: somente a equipe de segurança. "Alguém mudou minha senha", um pedido para remover o 2FA ou qualquer solicitação sobre um login de administrador ou proprietário da conta. O papel da IA aqui é rapidez e silêncio: marcar como urgente, encaminhar, dizer ao cliente o que acontece a seguir e não enviar nada para nenhum endereço que tenha mudado recentemente.
Um caso de cliente mostra por que a faixa 1 precisa de contexto, não apenas de uma palavra-chave. A MentorShow, uma empresa francesa de aprendizado online, faz a eesel ler cada ticket do HubSpot junto com o registro do membro, incluindo status da assinatura e data de renovação. As instruções deles têm uma linha que eu copiaria para qualquer configuração: um problema de login de alguém sem assinatura ativa não é um problema de login. Esse ticket precisa de uma resposta de cobrança, e um link de redefinição só faria o membro andar em círculos.
O que os padrões de segurança dizem sobre recuperação de conta?
As duas referências a que a maioria das equipes de segurança recorre para essa questão são a NIST SP 800-63B-4, as diretrizes de identidade digital do governo dos EUA, e a OWASP. Foram escritas para engenheiros que constroem sistemas de login, mas a maioria das regras se traduz diretamente no que um agente de suporte, humano ou IA, deve e não deve fazer.
| O que o padrão diz | O que isso significa em um ticket de suporte |
|---|---|
| O NIST lista quatro métodos de recuperação: códigos de recuperação salvos, códigos emitidos enviados a um endereço de recuperação, contatos de recuperação e repetição da comprovação de identidade | Seu agente deve verificar quais a conta tem antes de prometer qualquer coisa |
| Recuperar uma conta com 2FA exige dois códigos de recuperação de métodos diferentes, um código mais outro fator funcional ou comprovação de identidade repetida (NIST) | "Diga sua data de nascimento" não é uma das opções. Um caso de telefone perdido sem nada cadastrado vai para uma pessoa |
Um código de recuperação emitido dura no máximo 10 minutos por SMS ou voz e 24 horas por e-mail (NIST) | Diga aos clientes por quanto tempo o link vale e que peçam um novo em vez de responder a um e-mail antigo |
| Um novo endereço de recuperação deve ser confirmado com um código antes de ser usado (NIST) | Nunca trate como do cliente um e-mail digitado no chat |
| Toda recuperação de conta envia uma notificação aos endereços cadastrados, com uma forma de dizer "não fui eu" (NIST) | O endereço antigo fica sabendo de cada recuperação, então o verdadeiro dono pode barrar uma falsa |
As tentativas falhas em um autenticador são limitadas a 100 antes de ele ser desativado (NIST) | Bloqueios são propositais. Explique-os; não procure um desvio |
| Retornar a mesma mensagem exista ou não a conta (OWASP) | A IA nunca confirma "sim, esse e-mail é de um cliente" |
| Não conectar o usuário automaticamente após uma redefinição e oferecer encerrar outras sessões (OWASP) | Após uma invasão, uma nova senha sozinha pode não deixar o atacante de fora |
| Perguntas de segurança não devem ser a única verificação de redefinição (OWASP) | Respostas como aniversário ou nome de um bicho de estimação costumam ser encontradas online |
Essa regra de notificação é a que as equipes de suporte mais esquecem, e é a proteção mais barata que você tem. O NIST diz que as notificações de recuperação vão para todos os endereços de notificação da conta, e que o aviso deve incluir instruções claras e dados de contato caso o destinatário não tenha pedido. Se sua IA dispara uma recuperação, garanta que seu sistema envie esse aviso também ao endereço antigo. Se alguém estiver sequestrando a conta, o dono descobre em minutos, não quando tentar entrar da próxima vez.
A OWASP também faz um ponto que muda como você trata tickets de "acho que fui hackeado". Ela diz que uma redefinição de senha sozinha pode não restaurar o controle de uma conta comprometida, porque o atacante pode ainda ter uma sessão ativa ou ter alterado os dados de recuperação. Por isso os casos de invasão ficam na faixa 3, onde alguém pode encerrar todas as sessões e verificar o que mudou, e não na faixa 1 com um alegre link de redefinição.
Por que a IA não deve trocar e-mails nem redefinir o 2FA por conta própria?
Porque esses são exatamente os pedidos que os atacantes levam às centrais de suporte, e um modelo que lê um único chat não consegue distingui-los de um cliente real.
O alerta da CISA sobre o Scattered Spider, um grupo por trás de várias grandes violações, lista os movimentos. O grupo se passava por funcionários "to convince IT and/or helpdesk staff to provide sensitive information, reset the employee's password, and transfer the employee's MFA to a device they control". O alerta acrescenta que essas ligações costumam vir em várias conversas: primeiro descobrem o que a central de ajuda pergunta, depois voltam com as respostas. A lição de casa deles vem de redes sociais, vazamentos de dados e fontes abertas, e é exatamente por isso que "confirme seu endereço e data de nascimento" é uma verificação fraca.
A Okta viu o mesmo padrão. Em seu relatório de segurança de 2023, a Okta disse que vários clientes dos EUA relataram ligações tentando convencer a equipe da central de serviço a redefinir todos os fatores de MFA de suas contas de administrador mais poderosas. Os conselhos da Okta incluem verificações de identidade mais fortes na central de ajuda, limitar as funções da central para que não possam tocar em contas de administrador e alertar sempre que todos os fatores de MFA de um usuário forem redefinidos.
Agora imagine o mesmo ataque contra um agente de IA. Ele não se cansa, responde na hora e um atacante pode tentar cinquenta formulações em uma hora. Se o agente tiver uma ação "remover MFA" ligada, uma dessas formulações pode funcionar. Se ele não tiver essa ação, nenhuma funcionará. Essa é a regra que eu escreveria na configuração de qualquer agente: a IA pode iniciar uma recuperação, mas não pode concluir uma arriscada.
Trocas de e-mail merecem um aviso próprio. Um comentarista do Hacker News que operou um site de alto tráfego listou o que você evita ao não permitir trocas de e-mail:
"Email change is one of the most abused recovery vectors in account takeover (ATO)."
Você provavelmente não pode proibir trocas de e-mail, mas pode garantir que uma IA nunca faça uma a partir de um pedido de chat. Se suas preocupações com alucinação de IA são sobre respostas erradas, esta é a preocupação maior: uma ação com cara de certa feita para a pessoa errada.
Como a IA deve conversar com seu sistema de login?
Por um único endpoint restrito que seja seguro por design, não por acesso de administrador ao seu banco de dados de usuários.
A maioria dos provedores de identidade já tem a chamada de que você precisa, e é a chata: enviar o e-mail padrão de redefinição para o endereço cadastrado. Conferi a documentação de quatro comuns:
| Sistema de login | A chamada segura para dar a uma IA | A chamada arriscada para manter longe dela |
|---|---|---|
| Amazon Cognito | AdminResetUserPassword, que envia um código de redefinição do mesmo modo que o "esqueci a senha" do próprio usuário | AdminSetUserPassword, que define uma senha diretamente |
| Firebase Authentication | Gerar um link de redefinição de senha e enviá-lo por e-mail ao endereço existente do usuário | Definir o e-mail ou a senha pelo SDK de administrador sob solicitação |
| Auth0 | Disparar o e-mail padrão de troca de senha | Excluir a inscrição de MFA de um usuário pela Management API, que a Auth0 descreve como o mesmo que remover o registro de MFA dele |
| Okta | Recuperação de autoatendimento iniciada pelo usuário | Redefinir todos os fatores, o pedido exato do relatório de incidente da Okta de 2023 |
Um detalhe que vale conhecer no Cognito: a documentação diz que as mensagens de recuperação só vão para usuários com e-mail ou telefone verificado. Se nenhum estiver confirmado, um administrador precisa intervir. É um caso natural da faixa 2, e sua IA deve dizer isso claramente em vez de tentar de novo.
Se seu próprio app tem um botão "esqueci a senha", a opção mais limpa costuma ser expor a mesma coisa como um pequeno endpoint interno: recebe um e-mail, envia o e-mail normal de redefinição se a conta existir e sempre retorna a mesma resposta. Sua IA chama esse. Ela não pode fazer nada que sua página pública de login já não permita a qualquer pessoa.
Como configurar a IA para recuperação de conta no seu helpdesk
Esta é a ordem em que eu faria. Os passos 1 a 3 valem a pena mesmo que você nunca deixe a IA executar uma ação.
Passo 1: conte o que você realmente recebe
Antes de escrever uma regra, marque um mês de tickets por tipo de recuperação: senha esquecida, bloqueado, 2FA perdido, e-mail perdido, telefone novo, suspeita de invasão e "na verdade não é um problema de login". A marcação de tickets com IA pode fazer isso retroativamente sobre tickets passados. A mistura decide todo o resto. Uma fila com 90% de senhas esquecidas precisa de um endpoint e de uma boa resposta. Uma fila cheia de 2FA perdido precisa antes de um processo melhor de verificação de identidade.
Passo 2: escreva as faixas nas instruções
Coloque as três faixas nas instruções do agente em palavras simples, com exemplos do que os clientes realmente escrevem: "não consigo entrar", "telefone novo, autenticador perdido", "não uso mais esse e-mail", "alguém mudou minha senha". Acrescente também as regras rígidas: nunca confirmar se uma conta existe, nunca colar um link ou código no chat, nunca alterar dados de contato sob solicitação. Na eesel, as instruções são texto simples que você edita, e o agente pode endurecê-las quando você o corrige no chat, como explicam os documentos de instruções.
Passo 3: dê a ele o contexto da conta
Conecte o que disser à IA quem é essa pessoa: seu sistema de assinaturas ou cobrança, seu CRM, o registro de cliente do seu helpdesk. Esta é a lição da MentorShow. Metade dos tickets de "não consigo entrar" são planos expirados, produto errado ou um portal que você nem opera. A XAP encontrou o mesmo: alguns estudantes que não conseguem entrar estão no portal próprio de uma faculdade, que a XAP não opera, então a resposta certa é um encaminhamento, não uma redefinição.
Passo 4: conecte um endpoint seguro
Dê ao agente a única chamada de redefinição da seção acima, e nada mais que toque o login. Na eesel isso é o Network Access: você permite um domínio, adiciona o cabeçalho de autenticação nas configurações e o agente pode chamá-lo. Solicitações a qualquer outro domínio são recusadas.
O que importa para a recuperação é a linha no topo dessa tela: as credenciais são armazenadas como cabeçalhos e não são mostradas à IA. A chave que pode disparar redefinições nunca fica em um prompt, então não pode ser arrancada do agente na conversa. Seus desenvolvedores também podem configurar isso por um terminal. A CLI da eesel executa o mesmo agente e workspace do painel, então um engenheiro, um script ou um agente de código como Claude Code ou Cursor pode ligar o endpoint, editar as instruções de recuperação e testar o agente sem abrir o navegador.
Passo 5: faça toda ação do helpdesk que toca a identidade exigir aprovação
Cada ação que um agente da eesel pode executar é configurada por agente para rodar sozinha, perguntar primeiro ou ficar desativada. Os documentos de ações e aprovações recomendam começar supervisionado, com respostas e tudo o que for irreversível sob aprovação.
Para a recuperação, eu deixaria a marcação e as notas internas rodando sozinhas desde o primeiro dia e colocaria as respostas públicas sob aprovação na primeira ou segunda semana. Você também pode reter um tipo de caso mesmo com as respostas ativadas: uma instrução como "pergunte antes de responder qualquer coisa sobre 2FA ou troca de e-mail" faz o agente parar só nesses casos.
Passo 6: encaminhe as faixas 2 e 3 a pessoas nomeadas
A faixa 2 vai para quem pode executar sua verificação de identidade, em geral um agente sênior ou o nível 2. A faixa 3 vai para a segurança, por nome, com uma marca de urgente e um SLA curto. Uma IA pode encaminhar por marca instantaneamente; ela não consegue corrigir uma regra de encaminhamento que aponta para uma caixa compartilhada que ninguém monitora nos fins de semana. Se seu time de nível 2 for pequeno, faça a IA escrever a nota interna para que ele comece com os fatos da conta.
Passo 7: teste nos seus tickets de login antigos
Rode o agente sobre os tickets de recuperação que você já tratou antes que ele toque em um ao vivo. Ele enviou links de redefinição só na faixa 1? Alguma vez confirmou que um e-mail tinha conta? Percebeu a invasão escondida dentro de uma reclamação de cobrança irritada? Uma simulação em tickets passados responde isso numa tarde, e é o passo que eu nunca pularia nesse tipo de ticket.
Em qual faixa vai este ticket?
Escolha um tipo de solicitação para ver quem a trata, o que a IA faz e a regra por trás.
Como medir se está funcionando?
Acompanhe rapidez e segurança lado a lado. Uma configuração de recuperação rápida mas que de vez em quando entrega uma conta é pior do que não ter IA.
- Parcela dos tickets de recuperação fechados pela IA. Deve ser aproximadamente sua parcela da faixa 1 do passo 1. Se for muito maior, a IA está fechando tickets que não deveria.
- Tempo até a primeira resposta na faixa 1. Clientes bloqueados sentem cada minuto. Este é o número que mais deve cair.
- Tempo de resposta da faixa 3. Uma invasão parada seis horas numa fila é a falha que acaba numa manchete. Acompanhe nos seus relatórios de SLA.
- Respostas de "não fui eu" às notificações de recuperação. Cada uma é uma recuperação que alguém não pediu. Leia todas.
- Contatos repetidos em 7 dias. Se o mesmo cliente volta, o link de redefinição não chegou ou a resposta não tratou o problema real.
O guia de relatórios de suporte com IA mostra como montá-los a partir de tickets marcados.
Erros comuns com IA e recuperação de conta
Estes são os que eu vigiaria no primeiro mês:
- Deixar a IA confirmar que a conta existe. "Encontrei sua conta, enviando um link agora" parece útil e diz a um atacante quais e-mails são clientes. Use a mesma resposta nos dois casos.
- Tratar dados do chat como prova. Nome, endereço, últimos quatro dígitos, data de nascimento: tudo isso está no vazamento de dados de alguém. A CISA observa que os atacantes reúnem exatamente isso antes de ligar.
- Colar um link ou código na conversa. O chat é o único canal em que você não pode confiar num caso de recuperação. Os códigos vão para o endereço cadastrado.
- Dar à IA chaves de API de administrador "para garantir no futuro". Se a chave pode remover o MFA, presuma que um dia alguém convencerá o agente a tentar. Dê a ele a única chamada de que precisa.
- Pular a notificação. Toda recuperação deve avisar o endereço antigo. É o alarme de invasão mais barato que você vai configurar.
- Esquecer o outro login. A fila da XAP mostrou: às vezes o portal que o estudante não consegue acessar não é seu. Um encaminhamento vale mais que um link de redefinição.
Se quiser ver o panorama de como uma implantação assim vai de supervisionada a autônoma, o post sobre o cronograma de implementação explica o controle.
Experimente a eesel para tickets de recuperação de conta
A eesel entra no seu helpdesk como um colega de IA para o suporte. Nos tickets de login, ela lê cada um com o contexto da conta do cliente, dispara apenas a chamada de redefinição que você permite, responde do mesmo jeito exista ou não a conta e retém mudanças de 2FA, trocas de e-mail e qualquer coisa que pareça invasão para sua equipe. Funciona no Zendesk, no HubSpot e nos outros principais helpdesks, e no Freshdesk pela integração com o Freshdesk.
As aprovações chegam onde sua equipe já trabalha: o painel, uma conversa no Slack ou um link na nota do helpdesk, e cada aprovação registra quem decidiu e quando. Suas chaves de API ficam nas configurações, nunca à vista da IA, e a eesel nunca usa seus dados para treinar os modelos subjacentes, segundo seu Trust Center. Uma lacuna honesta: a auditoria SOC 2 Type II da eesel ainda está em andamento, então, se sua equipe de segurança precisa do relatório em mãos hoje, pergunte primeiro o status atual; minha lista de verificação de segurança de fornecedores explica o que pedir em vez disso.
A XAP é um bom modelo para começar pequeno. Um filtro na frente do seu agente da eesel deixa passar apenas casos de encaminhamento e redefinições de senha do portal, nada vai a um estudante sem que uma pessoa envie, e as exclusões de conta ficam com a equipe. Comece por aí, meça por um mês e depois abra a faixa 1. Você pode experimentar a eesel grátis por 7 dias com 100 créditos.