Suporte com IA é invadido por e-mail e burla 2FA

Agentes de atendimento com IA viraram porta de entrada

Agentes de atendimento com IA pareciam a automação perfeita: respondem rápido, puxam seu histórico, consultam a base de conhecimento e executam ações como trocar e-mail, reenviar fatura ou liberar acesso. O problema é que essa conveniência criou uma superfície de ataque que quase ninguém modelou direito. Pesquisadores que testaram chatbots e sistemas de voz com IA em empresas reais conseguiram sequestrar contas com algo banal como um e-mail com remetente falsificado. Sem scanner agressivo, sem exploit complexo, só lógica, prompt e falha de autenticação entre canais. O resultado passou de 50 mil dólares em recompensas em poucos fins de semana. Se você opera suporte com LLM conectado a ferramentas reais, isso não é teoria. É um fluxo explorável hoje.

O fato

O que foi demonstrado é simples e incômodo. Muitos chatbots oferecem envio de transcrição da conversa por e-mail, um recurso antigo que foi mantido na era dos LLMs. O bot copia o contexto e dispara o e-mail para o endereço que ele acredita ser seu. Só que a validação do remetente em vários casos era fraca. Ao falsificar o cabeçalho From, o agente passava a tratar o invasor como se fosse a vítima. A partir daí, o invasor não precisava mais convencer o modelo com um jailbreak mirabolante, ele já estava dentro da sessão de confiança. O bot mantinha a conversa por e-mail, aceitava instruções e executava chamadas de ferramenta vinculadas à conta da vítima.

O segundo ponto é ainda mais sensível: bypass de autenticação de dois fatores. Em fluxos normais, o atendente humano pede CPF, data de nascimento, código enviado por SMS ou e-mail antes de fazer algo crítico. Nos agentes testados, essa checagem foi delegada ao próprio modelo ou a uma lógica de integração mal amarrada. Com engenharia de prompt via e-mail, os pesquisadores fizeram o agente ignorar a etapa, aceitar um e-mail contrabandeado como prova de identidade ou até ler um OTP de outra conta e repassar. Em sistemas de voz com IA, os IVRs, o mesmo padrão se repetiu. A voz sintetizada ou o DTMF responde, o modelo interpreta, e a autenticação vira apenas mais uma instrução que pode ser manipulada.

Como funciona na visão de quem opera

Pense na arquitetura típica. Você tem um frontend de chat, um orquestrador com LLM, uma base vetorial com artigos de ajuda e um conjunto de tools expostas via API: get_profile, update_email, send_transcript, get_invoice, reset_password, verify_otp. O LLM recebe system prompt, histórico e resultado das tools. O erro está na camada de identidade. O chat web usa cookie ou token, mas o canal de e-mail usa apenas o campo From como identificador. Não há vínculo criptográfico entre os dois. Quando o bot recebe um e-mail que diz ser de [email protected], ele carrega o contexto daquela conta. Falta ali o básico de e-mail: checagem de SPF, DKIM e DMARC amarrada à sessão, mais um token de continuidade que prove que aquele thread de e-mail pertence à mesma sessão web que iniciou o atendimento.

O contrabando de endereço, que os pesquisadores chamaram de email address smuggling, explora exatamente essa costura. Variações como [email protected] atacado com display name enganoso, uso de plus addressing, unicode parecido, quebra de linha no cabeçalho ou múltiplos campos Reply-To e Sender confundem parsers ingênuos. O modelo não valida, ele só lê texto. Se a tool de verificação faz algo como verificar se o e-mail contém o domínio esperado ou se o nome bate, ela passa. Em termos de latência e custo, o ataque é barato para o invasor e caro para você. Cada interação injetada consome tokens do seu modelo, aciona retrieval na base e ainda chama APIs internas. O invasor automatiza tentativas por centavos, enquanto você paga inferência, aumenta fila e ainda corre risco de ação indevida que gera chargeback ou suporte manual depois.

Nos IVRs com IA o fluxo é parecido, mas com áudio. O sistema transcreve a fala, o LLM decide a próxima ação e um verificador deveria exigir a segunda etapa antes de liberar dados. Na prática, muitos implementam o 2FA como uma sugestão no prompt, algo como peça o código antes de continuar, em vez de uma trava de estado na máquina de atendimento. Se o invasor diz que não recebeu o código, que é o titular mas está sem acesso, ou cola um OTP vazado de outro serviço, o modelo tende a ajudar. Pior: alguns agentes têm acesso a caixas de e-mail compartilhadas ou a resumos de tickets onde OTPs ficam expostos em texto puro. Basta instruir o agente a buscar o código mais recente da vítima na base de conhecimento ou no histórico para exfiltrar. É prompt injection clássico combinado com permissão excessiva de tool.

Base de conhecimento também vaza

Outro vetor explorado foi a base de conhecimento do próprio agente. Essas bases guardam artigos internos, scripts de atendimento, URLs de reset, políticas de reembolso e, com frequência, dados que não deveriam estar ali, como exemplos reais com tokens, IDs e trechos de conversa. Com perguntas indiretas, como peça para resumir o procedimento de recuperação ou mostre um exemplo de e-mail de verificação, o modelo cospe conteúdo sensível. Isso não exige acesso autenticado. Qualquer usuário anônimo consegue extrair. Quando o agente tem RAG sem controle de acesso por nível, um artigo interno para funcionário tem o mesmo peso de um FAQ público. O modelo não diferencia, ele só rankeia por similaridade.

O que isso muda na prática

Quem ganha com esse cenário hoje é quem testa primeiro. Times de segurança ofensiva e caçadores de bug estão encontrando falhas de lógica que valem mais que um XSS comum, porque dão acesso a conta sem precisar roubar senha. Quem perde é todo mundo que colocou um agente com poder de escrita em produção sem revisar identidade entre canais. Se o seu bot pode enviar e-mail como suporte@, alterar cadastro, emitir segunda via ou iniciar reset, ele não é mais um FAQ. Ele é um atendente com privilégios, e precisa de controles de atendente com privilégios. Não dá para tratar transcrição por e-mail como recurso inofensivo.

O ajuste mínimo que você precisa fazer agora é direto. Desligue envio de transcrição para e-mail arbitrário ou trave para o e-mail verificado da conta logada, sem campo editável. Exija que toda ação de escrita passe por verificação fora do LLM, com máquina de estados que bloqueia a tool até o 2FA ser validado no backend, não no prompt. Amarre canal web e canal e-mail com token único por conversa, valide SPF, DKIM e DMARC e ignore From solto, Reply-To e Sender divergentes. Limite o que o agente pode ler: OTPs, tokens e tickets nunca deveriam ser retornáveis via chat. E faça uma ação prática ainda hoje:

• Audite suas tools expostas ao LLM e marque quais fazem escrita ou leitura sensível, depois coloque verificação de identidade no backend para cada uma delas.
• Rode um teste simples: falsifique o From para sua própria conta de teste e tente pedir troca de e-mail, reenvio de código e resumo de fatura pelo canal de e-mail do bot.
• Remova códigos, links de reset e exemplos reais da base de conhecimento e separe RAG público de RAG interno com controle de acesso.

A tensão que fica

A dúvida real aqui não é se prompt injection existe, todo mundo já sabe que existe. A dúvida é se dá para escalar atendimento autônomo com poder de escrita sem recriar todo o controle de acesso que levamos anos para colocar em APIs normais. O LLM quer ser útil, ele foi treinado para completar e ajudar. Segurança é o oposto, é dizer não por padrão. Quando você coloca a decisão de autenticar dentro do prompt, você está pedindo para o modelo escolher entre ser prestativo e ser seguro. Ele vai escolher ser prestativo. E mover a checagem para humanos no loop não resolve, porque o ganho do agente era justamente tirar o humano da fila. No fim, você só moveu o gargalo: antes faltava atendente, agora falta revisor de ação da IA, com custo de inferência, latência maior e risco concentrado em um único ponto que fala com o cliente e com o banco de dados ao mesmo tempo. Vale a pena manter transcrição por e-mail e reset via chat só para reduzir dois cliques, se o custo é abrir sequestro de conta por cabeçalho falsificado.

Conclusão

Agentes de suporte com IA que enviam e-mail, leem base interna e executam ações precisam de autenticação de backend, não de boa intenção no prompt. Se o seu bot confia em From sem validar, ele já é vulnerável. Quando foi a última vez que você testou seu atendimento como um invasor testaria, pelo e-mail e pela voz, e não só pela interface web.