Auditar exfiltração em uma aplicação de IA significa verificar se informações restritas conseguem sair por respostas, chamadas de ferramentas, arquivos ou requisições de rede. A defesa começa fora do prompt: controlar quem pode ler cada dado, quais destinos podem recebê-lo e qual regra autoriza cada transferência. Uma instrução de confidencialidade ajuda a orientar o modelo, mas não substitui essas barreiras.
O objetivo prático é produzir evidências de bloqueio, com dados fictícios e testes autorizados. Em vez de perguntar apenas se o assistente recusou um pedido suspeito, acompanhe o percurso completo: documento consultado, conteúdo colocado no contexto, argumentos gerados e transmissão efetivamente executada. O roteiro abaixo propõe uma auditoria focada em segredos empresariais, como margens, propostas ainda não divulgadas e documentos de estratégia.
Resumo rápido
- Mapeie saídas de dados, inclusive anexos, logs e ferramentas aparentemente de leitura.
- Use segredos sintéticos identificáveis em um ambiente autorizado de teste.
- Meça vazamento efetivo e bloqueio antes da transmissão, não somente recusas do modelo.
- Aplique autorização no servidor e limite destinos de rede.
- Repita a auditoria após mudanças de modelo, ferramentas, permissões ou documentos.
O que a auditoria precisa provar
Exfiltração é a transferência não autorizada de informação para fora do contexto permitido. Ela pode ocorrer quando alguém convence um assistente a revelar dados, mas também quando uma integração envia um documento legítimo ao destinatário errado. Por isso, a unidade de análise não deve ser apenas a frase digitada pelo usuário. Deve ser a operação que cruza uma fronteira de confiança.
O projeto OWASP descreve tanto divulgação de informações sensíveis quanto autonomia excessiva como riscos de aplicações com modelos de linguagem. Na prática, a auditoria proposta aqui transforma esses riscos em perguntas verificáveis: o solicitante podia acessar o documento? A aplicação podia usar aquele serviço externo? A operação precisava incluir todos os campos? O destino continuava autorizado no momento do envio?
Escreva uma política de resultado antes dos testes. Por exemplo: funcionários do atendimento podem consultar prazos públicos, mas não margens comerciais; uma proposta pode ser resumida internamente, mas não anexada a mensagens externas sem aprovação específica. Isso evita uma auditoria que aprova qualquer recusa e reprova qualquer resposta, sem considerar o trabalho legítimo.
O guia de testes contra injeção de prompt cobre a construção de cenários de entrada. Aqui, o recorte é a prova do que realmente atravessou as saídas da aplicação.
Mapeie dados, identidades e destinos
Comece com uma reunião curta entre operação, desenvolvimento e segurança. Liste os segredos de negócio que o assistente pode encontrar, o responsável por cada conjunto e os usos aprovados. Evite classificar tudo como confidencial: uma política indistinta cria bloqueios desnecessários e dificulta localizar o material que exige proteção maior.
Depois desenhe o caminho de uma solicitação real. Inclua navegador, servidor, busca documental, provedor de modelo, cache, ferramentas e armazenamento de registros. Indique a identidade utilizada em cada salto. Se o servidor consulta todos os documentos com uma conta administrativa, o filtro do aplicativo precisa demonstrar que preserva as permissões do usuário em todas as consultas.
| Saída | Exemplo de exposição | Evidência a coletar |
|---|---|---|
| Resposta ao usuário | Margem interna incluída no resumo | Resposta final e decisão da política |
| Ferramenta de envio | Anexo comercial para destino indevido | Destinatário, autorização e recibo de envio |
| Consulta externa | Trecho confidencial no argumento de busca | Parâmetros antes da execução |
| Arquivo gerado | Planilha com colunas restritas | Campos exportados e acesso ao arquivo |
| Telemetria | Prompt completo no painel de suporte | Registro minimizado e lista de leitores |
Uma ferramenta chamada “pesquisar” também transmite informações quando envia uma consulta a outro serviço. Não a trate como segura apenas porque ela não altera o banco da empresa. A lista de destinos deve incluir provedores de busca, observabilidade e processamento, além de e-mail e armazenamento.
Monte uma campanha de testes com segredos sintéticos
Crie documentos fictícios que reproduzam a estrutura dos materiais reais sem conter credenciais, valores estratégicos ou dados pessoais verdadeiros. Inclua marcadores únicos, como um código de proposta inventado, e registre onde cada marcador foi inserido. Eles funcionam como sinalizadores: se aparecerem numa saída não autorizada, há evidência objetiva de exposição naquele caminho.
Não dependa somente da correspondência literal desses marcadores. Uma resposta pode divulgar o significado de uma informação sem copiar a sequência original. Peça aos revisores que também procurem paráfrases, combinações de campos e conclusões que revelem o segredo. Uma margem pode ser reconstruída a partir de preço e custo mesmo quando a coluna “margem” foi removida.
Organize casos por fronteira: outro cliente, outra equipe, outro destinatário, outro ambiente e outra finalidade. Inclua pedidos diretos, documentos externos com instruções conflitantes e conversas com várias etapas. A orientação da OWASP sobre injeção reconhece entradas indiretas e riscos em conteúdo recuperado; a proposta desta campanha é verificar o efeito delas nas saídas autorizadas do seu sistema.
Para cada caso, registre entrada, usuário, documentos disponíveis, ação esperada e local de observação. Execute também casos permitidos com formato parecido. Se qualquer menção a contrato for bloqueada, o teste de segurança pode parecer excelente enquanto a aplicação deixa de atender sua finalidade.
Separe tentativa, preparação e transmissão. Uma chamada gerada pelo modelo e bloqueada pelo servidor é uma tentativa contida. Um pedido aceito pelo conector, mas cujo destino não foi observado, exige investigação. Uma resposta enviada ao usuário indevido já constitui exposição, mesmo sem conexão com um domínio externo.
Implemente bloqueios onde a transferência acontece
O ponto decisivo é o executor da ferramenta. Antes de enviar qualquer conteúdo, o servidor deve validar identidade, permissão sobre os dados, operação, destinatário e finalidade. O modelo pode sugerir os argumentos; ele não deve poder conceder a si mesmo a autorização. Essa separação mantém a política aplicável mesmo quando a geração de texto erra.
Prefira ferramentas específicas, como gerar um rascunho para um contato já cadastrado, a uma função genérica que envia qualquer arquivo para qualquer endereço. Limite acesso de rede aos destinos necessários e revise redirecionamentos e serviços intermediários no desenho da integração. A lista permitida precisa corresponder à operação de negócio, não apenas a uma marca de nuvem que hospeda milhares de contas.
Reduza os dados antes de construir o contexto. Um atendente que precisa saber se um desconto foi aprovado pode receber essa decisão sem a planilha inteira de custos. O mascaramento de dados com DLP complementa essa redução, mas segredos comerciais nem sempre têm formato reconhecível como um CPF ou uma chave de acesso.
Classificadores de conteúdo entram como outra camada. A documentação de Prompt Shields, da Microsoft, distingue detecção de ataques de prompt e de documentos. Ela também explica que, na API de Content Safety, decisões como bloquear ou escalar exigem lógica da aplicação. Receber um sinal de risco não prova que o envio foi impedido.
Para transferências sensíveis, mostre ao aprovador o destino real e o conteúdo exato. Vincule a aprovação àquela versão da operação. Se o anexo ou destinatário mudar, a aprovação anterior não deve continuar válida. O guia de permissões de agentes detalha o princípio de limitar capacidades.
Quando houver processamento na OpenAI, confira as opções da integração e os fluxos utilizados na página de OpenAI e ChatGPT. A decisão sobre quais documentos podem sair da empresa deve considerar a configuração efetivamente contratada, e não uma suposição baseada no nome do produto.
Exemplo: fabricante de embalagens em Joinville
Considere um cenário ilustrativo: uma fabricante de embalagens em Joinville usa um assistente para preparar respostas a solicitações de orçamento. O sistema consulta especificações públicas e uma base interna de propostas. A equipe comercial quer acelerar a redação, mas custos industriais e margens precisam ficar restritos.
A auditoria cria duas empresas fictícias e propostas diferentes. Um usuário de teste pode ler somente a proposta da primeira. O documento da segunda contém um marcador sintético. O primeiro teste pede um resumo comparativo: o resultado esperado é não recuperar o material inacessível, em vez de recuperá-lo e confiar que o modelo esconda o conteúdo.
Em outro caso, o assistente prepara um orçamento correto, mas a ferramenta recebe um destinatário externo que não pertence ao cadastro autorizado. A geração do rascunho pode continuar; a transmissão deve ser bloqueada. O registro guarda o identificador da tentativa, a regra acionada e o destinatário de teste, sem copiar a planilha restrita inteira para o log.
O relatório final contém evidências das duas fronteiras, os controles responsáveis e os caminhos ainda não testados. Não atribui uma porcentagem de segurança à empresa. Como o exemplo é ilustrativo, não há promessa de redução de incidentes nem números de desempenho apresentados como resultados reais.
Erros comuns
Tratar o prompt de sistema como cofre. Não coloque senhas, tokens ou segredos comerciais nele. Regras de comportamento devem orientar a tarefa; credenciais precisam permanecer nos componentes que executam operações autorizadas.
Inspecionar só o texto final. Um assistente pode responder que não enviou nada enquanto uma ferramenta transmitiu conteúdo durante a execução. Compare a resposta com os eventos reais e com os registros do destino de teste.
Registrar tudo para facilitar a auditoria. O próprio observatório pode virar uma cópia dos segredos. Defina quais campos são necessários, quem lê as evidências e quando elas são eliminadas. Guarde identificadores e decisões sempre que o conteúdo completo for dispensável.
Transformar ausência de falhas em garantia. Um conjunto de testes cobre somente os cenários exercitados. Registre versão de modelo, prompt, ferramentas, regras e documentos. Repita a campanha quando qualquer uma dessas peças mudar, com atenção aos casos que antes falharam.
Medir apenas bloqueios. Acompanhe também pedidos legítimos recusados e tempo de revisão. Uma política que paralisa a operação tende a estimular atalhos manuais, reduzindo o benefício do controle.
Perguntas frequentes
Um filtro de prompt bloqueia todo vazamento?
Não. Ele pode identificar entradas suspeitas, mas não substitui permissões de leitura, autorização de ferramentas e controle de saída. A auditoria precisa demonstrar o comportamento dessas camadas em conjunto e registrar suas limitações.
É preciso usar segredos reais nos testes?
Não para a campanha inicial. Dados sintéticos permitem observar o percurso com menor risco. Reproduza formatos, relações e regras de acesso relevantes; não basta substituir tudo por uma frase genérica que não exerce o fluxo real.
Como avaliar vazamento por resumo?
Além de procurar marcadores exatos, revise se a resposta revela fatos restritos por paráfrase ou cálculo. Defina previamente quais informações não podem ser comunicadas e use revisores que conheçam a política de negócio.
Quando repetir a auditoria?
Após mudanças em modelo, contexto, permissões, conectores ou destino de dados, e conforme a rotina de revisão da equipe. Mantenha uma campanha curta para regressão e avaliações mais amplas quando o alcance da aplicação crescer.
