Seu bot de suporte com IA agora é sua maior superfície de ataque: proteja-o

Se o seu bot de suporte com IA pode redefinir uma conta, trocar um e-mail ou emitir reembolsos, ele é, na prática, sua nova conta root. E sim, atacantes já começaram a fazer engenharia social em fluxos de suporte com LLM para conquistar exatamente esses poderes. Incidentes recentes em que chatbots de suporte foram ludibriados a conceder acesso deveriam encerrar o debate: colocar um modelo de linguagem na frente da recuperação de conta sem gates de capacidade não é automação; é delegar autoridade a um sistema probabilístico treinado para ser prestativo.

Este post é um blueprint direto e prático para CTOs: como lançar um suporte movido a IA que não pode ser induzido a comprometer seus clientes. Trataremos o LLM como uma UI não confiável, vincularemos toda ação sensível a provas criptográficas e faremos da política o único caminho para qualquer efeito sobre o estado. As metas são simples e mensuráveis: zero tomadas de conta irreversíveis (ATOs) via suporte, atrito adicional inferior a 30 segundos para fluxos de alto risco e evidências auditáveis para cada ação privilegiada.

O padrão de incidente que você deve assumir que vai te atingir

Aqui está o modo de falha comum que continuamos vendo em relatórios e exercícios de red team:

1. O atacante engaja o agente de suporte com IA, alega perda urgente da conta (telefone roubado, e-mail comprometido, conta de influencer sob ataque, etc.).
2. O agente foi treinado para ser prestativo, então ele busca sinais que pareçam prova de identidade (e-mail antigo, dígitos parciais do cartão, dados públicos) e então aciona um caminho de recuperação via chamadas de ferramenta/função.
3. Gates de capacidade fracos ou ausentes permitem que o agente inicie trocas de e-mail ou redefinições de MFA usando sinais ambíguos ou facilmente falsificáveis (SMS, e-mail, perguntas baseadas em conhecimento).
4. Resultado: tomada de conta irreversível, evidência forense mínima de quem autorizou o quê e por quê.

Se sua stack permite que o LLM chame diretamente endpoints sensíveis assim que ele “se sentir confiante”, você está a um prompt de uma manchete de violação.

Primeiro princípio: o LLM é uma UI não confiável, não um ator

O modelo de linguagem nunca deve ter acesso direto a APIs privilegiadas. Pense nele como um shell acionado por voz que só pode solicitar capacidades a um motor de políticas. Todo efeito colateral deve ser:

• Expressável explicitamente por uma capacidade tipada (não texto livre).
• Vinculado ao sujeito verificado (usuário, dispositivo, sessão).
• Limitado no tempo e no contexto (uso único, TTL em segundos, escopo proporcional ao risco).
• Auditável com um log à prova de adulteração de intenção, evidência e aprovação.

O framework de design: cinco gates que o atacante deve atravessar

1) Escopo: mantenha o bot “faminto” por PII

Privar o agente de dados sensíveis por padrão. Geração aumentada por recuperação (RAG) nunca deve trazer PII bruta para o contexto do LLM a menos que um check de política a autorize. Estruture suas ferramentas de modo que o agente possa fazer perguntas de sim/não ou de divulgação mínima a um “oráculo de PII”, em vez de ingerir registros completos.

• Faça: exponha ferramentas como “verificar se os 2 últimos dígitos do telefone de recuperação coincidem com X”, retornando apenas um booleano.
• Não faça: expor ao LLM, em qualquer momento, ferramentas do tipo “obter perfil completo do cliente”.

Isso reduz vazamento e diminui a chance de o modelo usar sinais fracos como prova.

2) DSL de capacidades, não endpoints brutos

Substitua chamadas de função em texto livre por uma DSL de capacidades estreita e assinada. Em vez de tool: update_email(new_email), defina tool: request_email_change(user_id, reason), que retorna uma ação pendente que exige confirmação criptográfica fora de banda. O agente propõe; seu motor de políticas dispõe.

Padrão a copiar: tokens de capacidade com caveats (macaroons). Cada ação sensível requer um token emitido por um serviço de políticas que atesta:

• Sujeito: user_id 12345, session_id abc
• Contexto: ip_hash X, device_binding Y, risk_score ≤ 30
• Ação: change_email para o candidato Z
• Restrições: uso único, TTL de 60s, nonce de replay N

Sem esse token, o serviço de ação não pode mutar estado — não importa o que o bot diga. Veja macaroons como inspiração, ou use concessões de capacidade estruturadas assinadas pela sua chave de política.

3) Vinculação de identidade e reautenticação recente

Fluxos de alto risco exigem prova de presença, não memórias. Você deve impor:

• WebAuthn/passkeys como a reautenticação primária para usuários com dispositivo presente. Sem passkey, sem recuperação instantânea.
• Autenticação step-up via push no dispositivo no seu app móvel com texto da transação (por exemplo: “Aprovar troca de e-mail para alice+new@domain.com”).
• Confiança no dispositivo: vincule a recuperação a um dispositivo existente e atestado quando disponível. Se todos os dispositivos forem perdidos, eleve o risco e desacelere.

OTPs por SMS e e-mail são sinais fracos; trate-os como insumos para a pontuação de risco, não como um passe livre.

4) Fora de banda, criptograficamente atrelado à intenção

Qualquer recuperação que altere identificadores (e-mail, telefone), desabilite o MFA ou adicione um novo método de recuperação deve ser confirmada fora de banda por um desafio assinado que incorpore os parâmetros exatos da transação. Assim, mesmo que um atacante induza o bot a iniciar um fluxo, o desafio visível ao usuário ainda exige que o dispositivo da vítima aprove a mudança específica.

Regras práticas:

• Confirmações de saída devem exibir os detalhes da transação com precisão (novo e-mail, último IP visto, geolocalização, timestamp).
• Os desafios expiram rapidamente (≤ 5 minutos) e são vinculados por nonce ao token de capacidade.
• Se não existir canal confiável, imponha um período de resfriamento (por exemplo, 24–72 horas) e revisão manual.

5) Humano no loop onde importa

Você não automatizará 100% da recuperação de contas com segurança. Mantenha uma fila nearshore com equipe para fluxos de alto risco. Como regra, qualquer coisa que simultaneamente altere um identificador e desabilite um fator requer uma pessoa. O LLM pode coletar contexto e redigir a resposta, mas um humano deve clicar em “aprovar”. Com analistas baseados no Brazil você ainda obtém 6–8 horas de sobreposição com os fusos dos EUA e 20–30% de custo menor em relação a equipes nos EUA, sem empurrar esse trabalho para turnos da madrugada.

Blueprint de arquitetura que você consegue lançar neste trimestre

Componentes

• Orquestrador de LLM: conduz a conversa, planeja ações, mas não pode chamar APIs privilegiadas diretamente.
• Motor de políticas: codifica regras como código (por exemplo, OPA/Rego ou similar). Apenas este serviço emite tokens de capacidade para ferramentas sensíveis.
• Serviço de risco: calcula uma pontuação de risco por requisição (sinais abaixo). A política o consulta.
• Serviços de ação: realizam mutações somente quando chamados com um token de capacidade válido.
• Confirmador fora de banda: push no app móvel ou cerimônia WebAuthn que assina a intenção.
• Ledger de evidências: log imutável (armazenamento WORM) de quem solicitou, quem aprovou, qual token, qual risco.

Sinais de risco que realmente fazem diferença

• Proveniência da sessão: primeira vs. sessão de retorno, idade do cookie, estabilidade da impressão digital TLS.
• Reputação do dispositivo: vinculação a dispositivo atestado, sinais de jailbreak/root, detecção de emulador.
• Geovelocidade: distância e tempo desde o último login bom; mudanças súbitas de país.
• Qualidade da rede: qualidade do ASN, IP residencial vs. datacenter, relatos recentes de abuso.
• Linguagem e comportamento: desalinhamento entre a linguagem histórica do usuário e a interação atual; padrões de digitação acelerada e copiar/colar.
• Contexto da conta: idade, gasto, tentativas prévias de recuperação, status de admin, alcance como criador.

Produza uma pontuação de risco contínua de 0–100. Defina limiares claros na política: abaixo de 20 = autoatendimento + passkey; 20–60 = step-up + fora de banda; acima de 60 = revisão humana e período de resfriamento. Calibre com seus próprios dados, não com tabelas genéricas.

Tokens de capacidade: faça da política o único caminho para efeitos no estado

Para cada ferramenta sensível que o agente possa invocar, exija um token de capacidade assinado e de uso único. Detalhes de implementação que evitam problemas:

• Separação do emissor: apenas o motor de políticas tem a chave privada para assinar tokens. Serviços de ação não aceitam credenciais bearer do agente ou do cliente web.
• Caveats: incorpore user_id, session_id, limite de risco, ação e parâmetros exatos, bindings de IP/dispositivo, TTL ≤ 60 segundos, nonce.
• Uma vez e pronto: tokens são consumidos no primeiro uso, independentemente de sucesso; novas tentativas exigem nova decisão de política.
• À prova de replay: armazene nonces por 10–15 minutos em um KV store rápido para detectar repetições.

Use caveats no estilo macaroons ou JWTs assinados com claims estruturadas — o ponto é o mesmo: o LLM nunca detém poder de uso geral, apenas bilhetes de capacidade estreitamente escopados.

Confirmações fora de banda que se sustentam na justiça

Confirmações devem ser criptograficamente vinculadas à transação exata. Boas opções:

• Desafio assinado via WebAuthn em uma sessão de navegador autenticada.
• Push no app com material de chave único do dispositivo armazenado na Secure Enclave/TPM e atestação remota.

Armazene o desafio assinado, o texto exibido e um hash da conversa no seu ledger de evidências. Se reguladores ou autores de ações vierem bater à porta, você pode apresentar um trilho completo e imutável de intenção e aprovação.

Higiene de prompts e de ferramentas

• Prompts de sistema nunca devem instruir o modelo a contornar a política por empatia. Remova quaisquer variantes de “se você estiver confiante”. Confiança é traço de UI, não sinal de segurança.
• Decodificação restrita para invocação de ferramentas: chamadas de ferramenta devem ser JSON com um schema verificado; rejeite qualquer desvio.
• Minimização de dados: mantenha janelas de contexto enxutas; passe IDs, não blobs; recupere sob demanda via ferramentas aprovadas pela política.

Trade-offs que você deve explicitar ao seu CEO

• Atrito vs. segurança: espere 15–30 segundos a mais para fluxos de alto risco. Isso é mais barato que uma manchete e uma ação coletiva.
• Teto de automação: você limitará recuperações autônomas a 70–90% dependendo da sua base de usuários e adoção de passkeys. O restante vai para a fila humana.
• Investimento em mobile: confirmações fora de banda exigem bom suporte no app móvel. Se você é apenas web, priorize passkeys neste trimestre.
• A escolha do modelo mal importa quando comparada a política e design de capacidades. A diferença entre modelos é polimento de UX; a diferença entre designs é ter ou não ter violação.

O que medir: segurança é métrica de produto

• ATO irreversível via suporte: meta 0 por 100.000 sessões de suporte/mês.
• Taxa de falso-negativo em fluxos arriscados capturados pela revisão humana: meta ≥ 90% das solicitações realmente maliciosas desviadas.
• Latência mediana adicionada para recuperações arriscadas: meta ≤ 30s.
• Volume de revisão humana: acompanhe como % do total; use para dimensionar sua equipe nearshore. Uma razão inicial é 1 analista por 10–20k MAU para apps de consumo; em B2B é menor, mas com consequências maiores.
• Mau uso de tokens: qualquer token de capacidade rejeitado por violação de caveats deve acionar o on-call. Se esse número for diferente de zero, investigue buracos de política.

Faça red team do seu bot como um atacante

Não espere a internet testar seus trilhos de proteção. Construa uma “pista de jailbreak” interna e execute cada revisão de modelo/prompt por ela. Use transcrições adversariais curadas que tentem:

• Disparar redefinições com narrativas simpáticas e senso de urgência.
• Explorar prompts em línguas não inglesas ou palavras-código.
• Pedir ao bot para resumir ou reformatar segredos (tentando puxar PII para o contexto).
• Coagir o bot a contatar a “segurança” em um endereço controlado pelo atacante.

Publique as taxas de aprovação/reprovação para sua liderança e inclua-as nos critérios de release. Considere copiar padrões de orientações acadêmicas sobre segurança de agentes e uso de ferramentas; os pesos exatos do modelo importam menos do que a disciplina de testes e de política.

Um plano 30–60–90 dias que não morre em comitê

Dias 0–30: estancar o sangramento

• Remova acesso direto, a partir das ferramentas do seu LLM, a qualquer endpoint que altere identificadores ou desabilite o MFA.
• Introduza um serviço de políticas que deve assinar tokens de capacidade para ferramentas sensíveis; deixe o resto em stub.
• Lance a confirmação fora de banda mínima viável para trocas de e-mail via push no app ou WebAuthn.
• Comece a registrar toda tentativa de ação sensível e o hash da conversa em um storage WORM.

Dias 31–60: eleve a barra

• Implemente um serviço de pontuação de risco e defina limiares de política para habilitação de ferramentas.
• Restrinja a invocação de ferramentas a um schema JSON estrito com verificação de assinatura; rejeite chamadas malformadas.
• Acione períodos de resfriamento para fluxos de alto risco quando não houver dispositivo confiável disponível.
• Equipe uma fila de revisão nearshore no horário comercial; meça desvio e latência de decisão.

Dias 61–90: torne isso entediante

• Endureça tokens de capacidade com bindings de dispositivo/IP, TTL de 60 segundos e nonces de uso único.
• Expanda fora de banda para todas as trocas de identificador e redefinições de MFA; capriche no texto da transação.
• Codifique a política em OPA/Rego (ou no engine escolhido) e coloque-a sob code review e CI, como código de app.
• Automatize testes de regressão de red team e exija notas de corte para toda mudança de prompt/modelo.

Por que o nearshore no Brazil ajuda aqui

Quando você aceita que 10–30% dos fluxos devem ser revisados por humanos, sua unit economics depende de staffing e sobreposição. O Brazil lhe dá 6–8 horas de sobreposição com os fusos dos EUA, analistas sêniores confortáveis em inglês e português/espanhol e 20–30% de economia de custo vs. contratação nos EUA. Mais importante: você mantém a tomada de decisão privilegiada em fusos domésticos — sem escalonamentos às 2 da manhã, sem “carimbo” offshore.

Em resumo

Você não vai sair dessa com prompt. A resposta certa é arquitetural: tokens de capacidade emitidos por política, limitados no tempo e no contexto; confirmações fora de banda criptograficamente atreladas à intenção exata; e um motor de risco que estrangula ou desvia fluxos suspeitos para humanos. O LLM é uma interface brilhante para coletar contexto e explicar decisões, mas até que ele possa portar uma credencial de segurança, ele nunca deve ser quem puxa a alavanca.

Pontos-chave

• Trate o LLM como uma UI não confiável; ele deve propor, não dispor.
• Use tokens de capacidade assinados, de uso único, com caveats estritos para toda ação sensível.
• Vincule a recuperação à prova de presença (passkeys, push in-app), não a memórias ou somente e-mail/SMS.
• Construa um motor de risco e defina limiares de política que controlem a habilitação de ferramentas.
• Espere 10–30% de humano no loop para fluxos de alto risco; use nearshore para manter custos e latência sob controle.
• Registre intenções, tokens, aprovações e hashes de conversa em um ledger de evidências WORM.
• Automatize testes adversariais e torne-os parte dos critérios de release para prompts/modelos.