A armadilha da confiança nos agentes autónomos e o que fazer antes que seja tarde

Duas equipes de pesquisa mostraram esta semana que os agentes autônomos auto-alojados podem ser comprometidos com técnicas que parecem inofensivas: Imperva demonstrou que OpenClaw executava instruções escondidas em contatos compartilhados, vCards e pines de localização, e Varonis provou que um agente bem configurado pode ser persuadido por e-mails credíveis para filtrar chaves e dados sensíveis. O vetor não foi uma exploração críptica do modelo, mas a maneira como o agente confia na informação que lhe chega e a entrega ao LLM sem marcar como não confiável.

O achado técnico de Imperva revela uma falha na "plomeria" do OpenClaw: ao serializar objetos de mensagens o agente insere campos como o nome de contato ou o rótulo de localização diretamente no prompt, usando um formato que permite incluir caracteres legais (como os sinais de menor/maior) para camuflar instruções. O resultado prático foi que, em seus testes com Gemini 3.1 Pro, o modelo descargou e executou um script hospedado pelos pesquisadores. O OpenClaw corrigiu esse comportamento na versão 2026.4.23 movendo esses campos para um canal de metadados marcado como não confiável; se a ferramenta for usada, atualizar a essa versão é a ação mínima e imediata. Para entender melhores práticas sobre inseguranças de LLM e agentes, convém rever o trabalho comunitário em segurança de modelos, por exemplo no projeto OWASP de segurança LLM https://owasp.org/www-project-llm-security/.

Varonis, por sua vez, abordou o problema pela via social: construiu um agente chamado Pinchy, alimentou-o com uma caixa de dados de negócios e executou campanhas de phishing dirigidas ao agente em Gemini 3.1 Pro e OpenAI Codex GPT-5.4. Os testes mostraram que um e-mail aparentemente legítimo - urgente ou rotineiro - bastava para que o agente, apesar de ter normas para verificar remetentes, reenviara chaves AWS e exportações de clientes. A conclusão é clara: os agentes são excelentes analisando URLs e portais técnicos suspeitos, mas são muito mais frágeis frente a pretextos sociais que exploram sua inclinação a ajudar. Varonis levanta controles arquitetônicos: políticas como código aplicadas pelo sistema, portas de saída para e-mails salientes para endereços novos, controle do nível de confiança por conector e bloqueio de ações de alto risco até confirmação humana.

Esses incidentes não só expõem bugs pontuais; mostram uma tensão fundamental no desenho de agentes: para que sejam úteis devem ler dados privados e, ao mesmo tempo, decidir com autonomia. Simon Willison descreveu isto como uma "trifecta letal": leitura de dados privados, ingestão de conteúdo não confiável e capacidade de enviar dados fora. O OpenClaw tem as três capacidades, e o vetor de ataque pode vir tanto de um arquivo mal formado como de um e-mail perfeitamente escrito por um atacante. Essa classe de risco transcende adesivos e exige mudanças de arquitetura e processo.

A superfície de ataque também se refletiu em erros de implementação relatados por analistas: extensões para Slack, Discord, Matrix, Zalo e Teams resolveriam listas brancas por nomes modificáveis em vez de identificadores estáveis, permitindo que um atacante renombrasse suplantase a uma conta permitida. OpenClaw publicou arranjos para esses casos, mas a lição é sistémica: as decisões sobre identidade e confiança devem basear-se em identificadores imutáveis e auditáveis verificáveis.

Desde a regulamentação, o impacto já chegou: a autoridade holandesa de proteção de dados (Autoriteit Persoonsgegevens) recomendou não executar o OpenClaw em sistemas que contenham dados sensíveis, por risco de fuga e tomada de controlo de contas. Esse pronunciamento sublinha que o risco não é apenas técnico, mas também legal e de cumprimento; as organizações devem avaliar agentes como pontos de possível violação de dados e responsabilidades de controlador. Para mais informações sobre marcos regulatórios e privacidade, a web da Autoriteit Persoonsgegevens pode servir como referência institucional https://autoriteitpersoonsgegevens.nl/en.

O que devem fazer os equipamentos de segurança e os responsáveis pelo produto agora mesmo? Primeiro, Aplicar adesivos e mitigações publicadas(por exemplo, a actualização 2026.4.23 do OpenClaw). Segundo, tratar o agente como um empregado Junhor com acesso a sistemas: impor políticas como código que o agente não possa exceder, exigir confirmação humana para ações críticas e registrar e revisar exaustivamente qualquer atividade de saída. Terceiro, segmentar permissões por conector: um canal de correio externo não deve implicar acesso livre ao CRM nem a segredos enquanto não se verifique a confiança da origem. Quarto, limitar memória por defeito e considerar mecanismos de "ephemeral context" para minimizar rastros persistentes de instruções maliciosas. Além disso, colocar portas de saída que impeçam envios para endereços externos desconhecidos sem autorização e aplicar controlos de egress em rede para bloquear descargas executáveis não aprovadas.

Também fazem falta de controlos organizacionais: políticas de threat modeling para agentes, formação específica sobre engenharia social dirigida contra agentes (não apenas contra humanos), revisões de auditoria que correlacionem ações do agente com triggers humanos, e regras de detecção em SIEM/EDR que busquem padrões de exfiltração via integrações. A adoção de listas brancas baseadas em IDs imutávels e a separação de funções (princípio de menor privilégio) reduzem o risco de escalada por renome ou suplantação.

Finalmente, há uma reflexão estratégica: as correcções atuais —metadatos não confiáveis, validação de remetentes, limitação de capacidades — amortecimento de ataques concretos, mas não resolvem a contradição de fundo. Um agente útil deve confiar até certo ponto em entradas externas; qualquer projeto que busque máxima autonomia e máxima utilidade estará em tensão com os objetivos de segurança e privacidade. A resposta a longo prazo passará por modelos de confiança composta: políticas forçadas pela infraestrutura, gates humanos para atos críticos, e uma mentalidade de "delegação limitada" em que o agente complementa trabalho humano, não o substitui sem supervisão. Para leituras adicionais e guias práticas sobre ameaças a agentes e modelos, blogs técnicos de empresas que investigam essas áreas oferecem análise contínuas; é recomendável seguir fontes especializadas como publicações de pesquisa em segurança de provedores e consultorias de cibersegurança, por exemplo, as seções de pesquisa de Imperva e Varonis https://www.imperva.com/blog/ e https://www.varonis.com/blog/.

Em resumo: adesivos e mitigar já, mas, sobretudo, repensar como se integra um agente no perímetro de confiança da organização. Sem mudanças arquitetônicos e operacionais, uma mensagem inocente ou um contato compartilhado podem se tornar a porta de entrada para comprometer não só o agente, mas os sistemas e os dados que gerencia.