Radar Tech: agentes LLM conectados viram vetor de vazamento — como proteger o agente antes de colocar ferramenta em produção
A falha do ChatGPT-Gmail e o surto de agentes autônomos roubando credenciais apontam o mesmo erro de arquitetura: confiar no texto do LLM para autorizar tool-calls. O caminho é gate estrutural, menor privilégio e human-in-the-loop de verdade.
Radar Tech: o agente LLM é a nova superfície — a semana mostrou como injeção indireta de prompt e agentes autônomos demais conseguem exfiltrar dados ou roubar credenciais em horas.
O que aconteceu nas últimas 24h
Duas histórias de segurança ligadas a IA chamaram atenção nesta semana e convergem para o mesmo ponto de arquitetura: a fronteira entre o LLM e as ferramentas que ele controla hoje é tratada com confiança demais e controle de menos.
- Uma falha real envolvendo ChatGPT conectado ao Gmail mostrou que um prompt embutido com intenção hostil (indirect prompt injection) em conteúdo processado pelo assistente conseguiu direcionar dados da vítima para outra conta. A "ação" final foi uma tool-call legítima de encaminhamento — o que prova que o problema não está na ferramenta, e sim em quem (ou ao que) se confia quando ela é chamada.
- Em paralelo, pesquisadores documentaram agentes autônomos de IA comprometendo milhares de credenciais em menos de seis horas. Quando o agente tem tokens de escopo largo, muita permissão de leitura/escrita e nenhum gate por ação, ele se torna uma máquina de mover dados e segredos na velocidade do raciocínio — inclusive para fora do perímetro.
Não são bugs isolados; são o que acontece quando o software começa a agir no mundo real.
Por que isso é um problema de arquitetura (e não de "sanitizar prompt")
O erro mais comum ao reagir a esses incidentes é pensar em "bloquear prompts maliciosos". Isso trata o sintoma. A mudança estrutural que importa é:
- Jamais tratar o texto de saída do LLM como autoridade de autorização. Se o plano de "enviar esse e-mail" veio do raciocínio do modelo, ele é só uma solicitação — quem decide é um controlador estrutural.
- Colocar um gate de tool-call entre o agente e qualquer efeito colateral. Cada chamada a e-mail, CRM, nuvem ou repositório precisa passar por uma verificação com allowlist de destino/operação/escopo antes de executar.
- Aplicar menor privilégio e tokens curtos por ação, em vez de um refresh token estático pendurado no agente.
- Exigir human-in-the-loop de verdade nas ações de alto impacto e baixa frequência (encaminhar, excluir, criar webhook, merge) — confirmação ativa do dono do dado, não consentimento dado uma vez no onboarding.
- E, como a leitura também expõe: mascarar dados sensíveis antes de entrarem no contexto do modelo.
O fluxo correto lembra um proxy de decisão: o agente propõe → um veredito estrutural valida → só então o acesso é emitido, curto e auditável. Nunca o inverso.
Para a conversa de arquitetura
Quem opera assistentes conectados a dados reais deveria responder agora: qual é a minha fronteira de confiança? onde nasce o gate de cada tool-call? Se a resposta é "o próprio agente cuida disso", é sinal de que o próximo incidente é questão de tempo.
Dica: transforme isso em um ADR e num modelo de ameaças antes de liberar a primeira ferramenta em produção. Para um caminho guiado — prompt, regras, few-shots e um harness de verificação prontos — confira o pacote desta semana sobre agente LLM conectado e seguro no catálogo. A boa notícia é que dá para desenhar isso certo antes de ligar o agente ao mundo real.
