Vazamento de dados por agente de IA: como bloquear a exfiltração

Vazamento de dados por agente de IA: como bloquear a exfiltração

Um agente de IA vaza dados quando consegue ler informação sensível e também tem um caminho para enviá-la a alguém que não deveria recebê-la. Para bloquear a exfiltração, é preciso cortar esse caminho: limitar o que o agente lê, restringir para onde ele consegue se comunicar e validar tudo o que sai, seja resposta, link ou chamada de ferramenta. Prompt bem escrito ajuda, mas não substitui controle de rede e de permissão.

Principais pontos

• O risco aparece quando três coisas coexistem: acesso a dado privado, contato com conteúdo não confiável e um canal de saída.
• As rotas mais comuns são ferramentas com acesso à internet, links e imagens montados pelo agente, respostas ao usuário errado e logs ou memória mal protegidos.
• Controle de rede (lista de destinos permitidos) e permissão mínima funcionam mesmo quando o modelo é enganado.
• Validar a saída e exigir aprovação humana para ações que enviam dados para fora reduz o dano de uma falha.
• Comece mapeando quais dados o agente toca e para onde ele pode falar, depois feche o que não é necessário.

O que é exfiltração de dados em um agente de IA?

Exfiltração é a saída não autorizada de informação da empresa para fora do ambiente controlado. Em software tradicional, isso costuma exigir um invasor ou um erro de configuração. Em agentes de IA, existe uma terceira origem: o próprio modelo pode ser induzido, por texto, a fazer o envio.

Isso acontece porque o agente lê instruções e dados no mesmo canal de linguagem. Um e-mail, uma página web, um PDF ou uma mensagem de WhatsApp pode conter um texto que parece uma ordem. Se o agente tem ferramentas, ele pode obedecer. Esse padrão é conhecido como injeção de prompt e aparece entre os riscos listados pelo OWASP Top 10 para aplicações com LLM.

Para quem decide, o ponto prático é este: a pergunta não é só se o modelo é confiável, mas o que ele consegue fazer se for enganado. O desenho do sistema deve assumir que a falha vai acontecer e limitar o estrago.

Por onde os dados saem: as rotas mais comuns

Vale separar as rotas, porque cada uma pede um controle diferente.

• Ferramentas com acesso externo: uma ferramenta de busca, de navegação, de envio de e-mail, de webhook ou de HTTP genérico permite que o agente envie conteúdo para qualquer destino. É a rota mais direta.
• Links e imagens: se a interface renderiza imagens ou links montados pelo modelo, uma URL pode carregar dados na própria query string. Basta a imagem ser carregada para o dado chegar ao servidor de quem escreveu a instrução maliciosa.
• Saídas para a pessoa errada: o agente responde com informação de outro cliente, de outro setor ou de um documento interno que o solicitante não deveria ver. Não há invasor, mas há vazamento.
• Integrações e servidores de terceiros: conectores, plugins e servidores MCP podem registrar ou repassar o que recebem. Por isso vale auditar um servidor MCP antes de instalar.
• Logs, memória e contexto compartilhado: conversas guardadas sem mascaramento, memória que mistura clientes e transcrições enviadas a ferramentas externas ampliam a superfície de exposição.
• Segredos no contexto: chaves de API e tokens colocados no prompt ou em arquivos que o agente lê podem ser repetidos na saída. O tema de guarda e rotação de chaves merece atenção própria.

Nenhuma dessas rotas depende de o modelo ser mal-intencionado. Todas dependem de o sistema ter dado ao agente um caminho aberto.

Como uma instrução escondida vira vazamento?

Um modelo mental útil é verificar a combinação de três condições. Quando as três estão presentes na mesma sessão, o risco é alto.

• O agente acessa dado privado: CRM, planilhas, conversas, documentos internos, dados pessoais.
• O agente processa conteúdo que não vem de você: e-mails recebidos, páginas web, anexos, mensagens de clientes, tickets.
• O agente consegue se comunicar para fora: enviar mensagem, abrir URL, chamar API, gerar link ou imagem.

Se você remove qualquer uma das três, a rota principal se fecha. Um agente que lê dados internos, mas só conversa com a equipe e não abre links, tem risco menor do que um que lê tudo, navega na web e envia e-mails. O guia de prevenção de injeção de prompt da OWASP detalha defesas de entrada e de saída, mas a lógica de separar capacidades é a que mais reduz risco na prática.

Um exemplo comum de desenho ruim: o mesmo agente que responde clientes no WhatsApp também consulta a base completa de pedidos e pode chamar uma ferramenta de webhook livre. Basta uma mensagem bem montada para tentar fazê-lo enviar dados de outros pedidos para um endereço externo.

Controles de rede: fechar a porta de saída

O controle de rede é a camada que continua valendo quando o modelo falha. Ele não depende de o agente entender a ameaça.

• Lista de destinos permitidos (allowlist): o ambiente do agente só consegue falar com domínios e serviços aprovados. Todo o resto é bloqueado por padrão.
• Saída por um ponto único: o tráfego do agente passa por um proxy ou gateway que registra e filtra as chamadas, em vez de cada ferramenta sair por conta própria.
• Ferramentas de navegação isoladas: se o agente precisa ler páginas externas, isso acontece em um ambiente separado, sem acesso a dados internos e sem credenciais.
• Sem rede para o que não precisa: tarefas de leitura e análise de documentos podem rodar sem nenhum acesso externo.
• Resolução e redirecionamentos controlados: validar o domínio final de uma URL, não só o domínio inicial, evita desvios por redirecionamento.

O mesmo princípio vale para ambientes de desenvolvimento assistido por IA. Se sua equipe usa agentes de código, vale ler sobre permissões, sandbox e segredos no Claude Code, que aplicam a lógica de isolar o que o agente alcança.

Controles de permissão e de saída

A rede limita para onde os dados vão. A permissão limita o que o agente consegue ler e fazer. As duas camadas se complementam.

Sobre permissão:

• Mínimo necessário: cada agente recebe só as ferramentas e os campos de dados que o fluxo exige. A orientação de autorização da OWASP reforça menor privilégio e checagem em cada requisição.
• Identidade do solicitante: o agente consulta dados com as permissões da pessoa atendida, não com uma conta de serviço que enxerga tudo.
• Leitura antes de escrita: ferramentas que apenas consultam são bem menos arriscadas do que as que enviam, apagam ou alteram.
• Credenciais fora do contexto: o agente nunca vê a chave; a camada de execução injeta o segredo na chamada.
• Aprovação humana: envio de dados para fora, exportações e mensagens em massa passam por uma pessoa antes de sair.

Sobre saída:

• Não renderizar links e imagens arbitrários: permita apenas domínios aprovados ou exiba o link como texto.
• Filtros de dado sensível: detectar CPF, e-mail, telefone, números de documento e segredos antes de a resposta ser enviada. O tema é tratado em guardrails para agentes de IA.
• Escopo da resposta: o agente só responde sobre o cliente identificado na conversa e se recusa a falar de terceiros.
• Limites de volume: um agente que tenta listar muitos registros de uma vez deve ser interrompido e gerar alerta.

Cenário ilustrativo e plano de implantação

Cenário ilustrativo: uma empresa de serviços coloca um agente no WhatsApp para consultar o status de pedidos. O agente tem acesso à base completa de clientes e uma ferramenta que permite chamar qualquer URL, usada para integrações. Um cliente envia uma mensagem com um texto que pede ao agente para listar os últimos pedidos de outras pessoas e enviar o resultado para um endereço externo. Sem controle, o agente pode tentar cumprir. Com os controles abaixo, a tentativa falha em mais de uma camada: a consulta só retorna dados do número identificado, a ferramenta só chama domínios aprovados e a resposta passa por um filtro antes de sair.

Um plano em passos para chegar a esse desenho:

• Liste os dados que o agente toca: quais sistemas, quais campos, quais envolvem dado pessoal sob a LGPD.
• Liste as ferramentas e o que cada uma consegue enviar para fora, inclusive as que parecem inofensivas, como navegação e geração de links.
• Marque, para cada fluxo, se as três condições (dado privado, conteúdo não confiável, canal de saída) coexistem.
• Remova ou separe uma das três sempre que possível, dividindo o agente em funções com menos poder.
• Aplique allowlist de rede e um ponto único de saída com registro das chamadas.
• Reduza as permissões de leitura ao cliente em atendimento e troque ferramentas genéricas por ferramentas estreitas (por exemplo, consultar status de um pedido, em vez de executar uma consulta livre).
• Coloque filtros na saída e aprovação humana para exportações, envios em massa e qualquer dado fora do escopo.
• Teste com tentativas de injeção em mensagens, documentos e páginas, e registre o que passou.
• Defina alertas e quem responde quando uma chamada bloqueada ou um padrão estranho aparecer.

Como registrar e testar para saber que está funcionando

Controle que ninguém observa vira suposição. Registre cada chamada de ferramenta, o destino, o solicitante e a decisão (permitida, bloqueada, enviada para aprovação). Esse registro serve para investigar incidentes e para ajustar regras. Ao mesmo tempo, os próprios logs contêm dado pessoal, então defina prazo e mascaramento, como discutido em retenção de logs de conversas de IA.

Teste de forma recorrente. Monte um conjunto pequeno de casos adversariais: mensagens que pedem dados de terceiros, documentos com instruções escondidas, páginas com links suspeitos, pedidos de exportação. Rode esse conjunto antes de cada mudança relevante de modelo, de prompt ou de ferramenta. O objetivo não é provar que o sistema é impenetrável, e sim saber quais rotas estão fechadas e perceber quando uma reabre.

Se houver dado pessoal envolvido, envolva quem cuida de privacidade na empresa. A ANPD é a referência oficial para orientações sobre proteção de dados no Brasil, e a decisão de quem é controlador e operador no contrato com fornecedores de IA afeta quem responde quando algo vaza.

Como aplicamos o método: mapear, limitar, pilotar, transferir

Na prática, o trabalho segue quatro etapas. Primeiro, mapear o processo atual e o que o agente vai tocar: dados, sistemas, ferramentas e canais de saída. Depois, limitar dados e ações, com permissões mínimas, rede restrita e aprovação humana nos pontos de maior risco. Em seguida, pilotar um fluxo real, com logs e uma métrica de sucesso combinada, incluindo testes de tentativa de vazamento. Por fim, transferir a operação com documentação e decidir se expande, ajusta ou para.

Essa ordem evita o erro mais frequente: ligar o agente a tudo primeiro e tentar proteger depois. Fechar portas é bem mais barato antes da produção do que depois de um incidente.

Perguntas frequentes

Um prompt que diz para nunca revelar dados basta para evitar vazamento? Não. Instruções no prompt ajudam, mas o modelo pode ser induzido por texto a ignorá-las. A proteção confiável vem de controles fora do modelo, como permissões, lista de destinos de rede e filtros na saída.

O que devo bloquear primeiro? Comece pelo canal de saída: ferramentas com acesso livre à internet, envio de e-mail e webhooks genéricos. Em seguida, reduza o que o agente consegue ler ao mínimo do fluxo e desative a renderização de links e imagens arbitrários.

Agentes que só leem dados internos também correm risco? O risco é menor se não houver canal de saída e se o conteúdo processado for todo confiável. Mesmo assim, ele pode responder à pessoa errada ou expor dados em logs. Por isso o escopo por solicitante e o mascaramento de registros continuam necessários.

Preciso de aprovação humana em tudo? Não, e isso inviabilizaria a automação. Reserve a aprovação para ações que enviam dados para fora, exportam volume ou mexem em dado sensível, e deixe o agente trabalhar sozinho nas consultas de baixo risco, dentro dos limites definidos.

Fontes

• OWASP: Top 10 para aplicações com LLM
• OWASP: prevenção de injeção de prompt
• OWASP: orientação de autorização
• ANPD: Autoridade Nacional de Proteção de Dados