“Prepare uma proposta para o cliente e encaminhe para revisão.”
O pedido não contém CPF, senha nem documento confidencial. Uma inspeção daquele texto, isoladamente, não encontraria o segredo comercial que será exposto ao final da tarefa.
Imagine este cenário fictício: durante a execução, o agente consulta o CRM, recupera uma planilha interna de margens e incorpora à proposta o limite de desconto reservado à negociação. Depois, salva o resultado em uma pasta com acesso externo, acreditando que aquele é o espaço correto para revisão.
Nenhum funcionário anexou a planilha ao prompt. A informação sensível entrou no processo por uma consulta feita pelo próprio sistema. O risco surgiu na combinação entre acesso, síntese e destino.
Um controle de saída bem posicionado poderia bloquear essa exposição. Mas, se a proteção estivesse limitada ao prompt inicial ou ao upload de arquivos no navegador, o restante da tarefa poderia acontecer fora da sua cobertura.
Quando a IA consulta, combina e usa dados para executar tarefas, a proteção precisa acompanhar toda a sequência de trabalho. Essa é a discussão que precisamos fazer sobre DLP na arquitetura de trabalho com agentes.
O que estamos chamando de DLP tradicional
Data Loss Prevention, ou DLP, reúne mecanismos para identificar informações sensíveis e aplicar políticas ao seu uso e compartilhamento. Isso pode incluir alertar, bloquear uma operação ou orientar o usuário.
Seria impreciso dizer que todo DLP se resume a expressões regulares, assinaturas ou bloqueio de arquivos. Existem soluções com correspondência exata de dados, identificação de documentos e classificadores treináveis. A documentação do Microsoft Purview descreve essas capacidades.
Também existem controles para texto colado ou digitado em prompts de aplicações de IA. Sua cobertura depende de condições como navegador, dispositivo, aplicação, licenciamento e configuração. Portanto, colar dados em um chat não é necessariamente uma operação invisível ao DLP. A documentação de proteção de aplicações de IA da Microsoft apresenta exemplos desses controles.
Neste artigo, “tradicional” descreve uma implantação concentrada em determinados canais e eventos, como envio de e-mail, upload, cópia de arquivo ou submissão de texto, sem cobertura demonstrada da tarefa completa do agente.
O problema aparece quando a organização presume que esses pontos de inspeção acompanham automaticamente tudo o que a IA fará depois.
A conversa é apenas o início do trabalho
No artigo IA sem mistério: como ChatGPT, RAG, agentes e MCP se conectam, explicamos como uma aplicação pode recuperar documentos, disponibilizar ferramentas e coordenar etapas.
Para segurança de dados, essa composição importa porque a solicitação inicial pode desencadear um fluxo como este:
Solicitação → recuperação de dados → montagem do contexto → geração de conteúdo → chamada de ferramenta → destino.
Cada etapa pode envolver outra aplicação, identidade ou regra de acesso. O navegador do funcionário pode ser apenas a interface de entrada de um processo executado em serviços de backend.
No exemplo da proposta, o usuário inicia a tarefa, um serviço consulta o CRM, outro recupera documentos e uma ferramenta grava o resultado. Precisamos saber quais credenciais cada componente usa e quais políticas são aplicadas em cada transição.
O fluxo pode continuar dentro de aplicações corporativas aprovadas e ainda assim expor informação a pessoas que não deveriam recebê-la. Um destino autorizado para documentos comerciais não está automaticamente autorizado a receber toda informação interna usada na preparação deles.
Cinco situações em que a cobertura pode falhar
1. A informação sensível aparece depois do prompt
Uma solicitação inofensiva pode levar à recuperação de contratos, dados financeiros ou registros de clientes. Inspecionar a entrada do usuário não informa quais dados serão acrescentados ao contexto durante a execução.
No nosso cenário, a planilha de margens chega depois. O ponto de controle precisa alcançar a recuperação e o uso desse conteúdo, além de avaliar a saída produzida.
2. O conteúdo muda de forma
O agente pode transformar uma planilha em um parágrafo, resumir um contrato ou reunir conclusões de várias fontes. O arquivo original não precisa sair para que uma informação confidencial seja revelada.
Uma frase como “podemos aceitar uma margem mínima de 12% nesta negociação” pode expor a estratégia comercial sem reproduzir a planilha da qual foi derivada. Nesse exemplo fictício, o percentual ganha sensibilidade pelo contexto e pela finalidade.
Detectores baseados em correspondência com o conteúdo original podem perder eficácia diante de certas transformações. Classificadores mais avançados podem ajudar, mas essa capacidade precisa ser testada com os dados e as políticas da organização.
3. A operação passa por um canal sem inspeção
Uma política aplicada no navegador não cobre, por consequência, todas as chamadas feitas por um serviço em nuvem. O mesmo vale para integrações diretas, ferramentas expostas por servidores MCP e processos agendados.
O protocolo ou o nome da tecnologia não determina a proteção. O que importa é onde a operação ocorre, qual componente a observa e se esse componente consegue aplicar uma decisão antes da exposição.
Se a gravação da proposta acontece por API, é necessário verificar a cobertura dessa API e do destino. A existência de DLP no endpoint do funcionário não responde essa pergunta.
4. O risco depende de informações combinadas
Em um cenário hipotético, uma consulta retorna o nome de um projeto, outra identifica a empresa envolvida e uma terceira informa a data da negociação. A combinação pode revelar uma aquisição ainda confidencial.
Uma avaliação limitada a cada fragmento pode não reconhecer o significado do conjunto. A inspeção precisa considerar o contexto relevante, respeitando também limites de retenção e acesso à própria telemetria.
Esse risco não exige que o modelo aprenda permanentemente as informações. Basta que elas estejam disponíveis durante o processamento ou sejam recuperadas pela aplicação.
5. A consequência envolve uma ação
O agente pode alterar o compartilhamento de uma pasta, publicar um documento ou modificar um registro. Uma chamada para conceder acesso pode nem carregar o conteúdo confidencial, embora mude quem consegue consultá-lo.
Inspeção de conteúdo e autorização da ação precisam trabalhar juntas. A OWASP, ao tratar de Excessive Agency, recomenda limitar funcionalidades, permissões e autonomia, além de exigir intervenção humana quando apropriado.
Detecção, cobertura e autorização são problemas diferentes
Tratar qualquer incidente como “o DLP falhou” dificulta descobrir o que precisa mudar.
Há uma falha de detecção quando o controle observa a informação, mas não reconhece sua sensibilidade. Há uma lacuna de cobertura quando a operação não passa por um ponto capaz de inspecioná-la. Há um problema de autorização quando uma identidade ou ferramenta recebe poderes além do necessário.
Esses problemas podem coexistir. Melhorar um classificador não fecha uma API sem inspeção. Adicionar um gateway não corrige, por si só, permissões excessivas na origem. Reduzir acessos também não dispensa a análise do conteúdo enviado a um destinatário externo.
Antes de comprar outra camada de proteção, vale reconstruir o fluxo e localizar a lacuna. Essa análise ajuda a definir qual controle deve impedir a operação e qual deve produzir evidência para investigação.
Acesso permitido também pode estar excessivo
Um agente pode respeitar as permissões técnicas e ainda alcançar informação desnecessária para a tarefa.
Na elaboração da proposta, a pergunta começa antes da geração: por que a identidade usada pelo assistente comercial consegue recuperar a planilha reservada à diretoria?
Em sistemas RAG, as permissões precisam ser preservadas na recuperação. Porém, uma busca que respeita uma permissão ampla demais continua entregando acesso amplo demais. Esse é um problema de exposição na origem.
O risco também pode surgir de índices ou cópias de documentos cujo acesso não acompanha alterações na fonte. Por isso, a revisão precisa considerar como a solução propaga permissões, atualizações e revogações.
A IA torna esse tema mais relevante ao facilitar a localização e a combinação de materiais dispersos. Dados que antes eram pouco consultados podem se tornar parte recorrente de respostas e decisões.
Essa discussão se conecta à governança de identidades de agentes: precisamos identificar o responsável, a finalidade e a autoridade de cada componente que atua sobre os dados.
Inspeção semântica ajuda, mas precisa de limites
Reconhecer uma estratégia de negociação pode exigir análise do significado do texto. Técnicas de classificação contextual podem complementar regras determinísticas e outros mecanismos de DLP.
Ainda assim, entender o assunto de uma mensagem não basta para decidir se determinada pessoa pode recebê-la. A decisão depende de identidade, finalidade, destinatário, política e sensibilidade dos dados.
Um componente baseado em modelo também precisa ser avaliado quanto a falsos positivos, falsos negativos e resistência a manipulações. Conteúdo vindo de documentos ou ferramentas pode conter instruções destinadas a influenciar o comportamento do sistema, em uma tentativa de prompt injection.
Por isso, instruções de segurança escritas em um prompt não substituem as restrições aplicadas pelo serviço que executa a ação. Se a ferramenta permite compartilhar uma pasta com qualquer destinatário, pedir ao modelo que “tenha cuidado” deixa uma autoridade importante sem limite técnico.
Termos como “DLP semântico” e “Agentic DLP” devem ser traduzidos em capacidades verificáveis: quais operações a solução observa, que contexto utiliza, onde bloqueia e como demonstra o resultado.
Como distribuir a proteção ao longo da tarefa
Uma arquitetura mais completa combina controles sobre a postura dos dados, o acesso, o conteúdo e a execução.
| Momento | Pergunta que precisa ser respondida | Capacidades envolvidas |
|---|---|---|
| Antes da consulta | Quais dados sensíveis estão expostos além do necessário? | Descoberta, classificação e análise de exposição, apoiadas por DSPM. |
| Na recuperação | Essa identidade pode acessar esses documentos e registros? | Autorização, governança de identidades e aplicação das permissões da fonte. |
| Na montagem do contexto | A tarefa precisa de todas essas informações? | Minimização, seleção de fontes e tratamento de conteúdo não confiável. |
| Na resposta | O resultado contém informação restrita para esse destinatário? | Classificação e DLP de saída nos canais cobertos. |
| Na execução | A ferramenta, a operação e o destino estão autorizados? | Privilégio mínimo, restrições de ferramentas e aprovação conforme o impacto. |
| Após a ação | Conseguimos reconstruir o ocorrido e interromper novos acessos? | Auditoria, monitoramento, resposta e revogação de credenciais. |
Essas capacidades podem estar reunidas em um produto ou distribuídas entre vários. A validação deve considerar o comportamento efetivo da integração.
No cenário da proposta, seria possível impedir a recuperação da planilha, excluir informações desnecessárias do contexto, detectar conteúdo confidencial no resultado ou bloquear a gravação em uma pasta externa. Cada controle reduz uma parte do risco; sua combinação torna a proteção menos dependente de uma única decisão.
Um teste prático para a sua arquitetura
Escolha uma tarefa real executada com IA e teste o fluxo em um ambiente controlado, usando dados fictícios representativos. Acompanhe desde a solicitação até o resultado final.
Verifique se a organização consegue responder:
- Quais fontes foram consultadas e com qual identidade?
- Que informações entraram no contexto e foram incorporadas à resposta?
- Quais ferramentas foram acionadas e quais destinos receberam o resultado?
- Em que etapas uma política poderia bloquear a exposição antes de ocorrer?
- O que acontece se o controle de inspeção estiver indisponível?
- Como interromper a execução e revogar os acessos utilizados?
Inclua variações: um documento restrito, um resumo que preserve um segredo comercial fictício, um destino externo e uma tentativa de alterar permissões. Observe também se tarefas legítimas continuam funcionando.
O objetivo é medir a cobertura e os limites da arquitetura. Um bloqueio no navegador comprova aquela proteção específica; o restante da tarefa precisa de evidências próprias.
Onde o DSPM entra
O DSPM contribui para entender quais dados sensíveis estão disponíveis, como estão expostos e quais acessos precisam ser reduzidos. Esse trabalho ajuda a corrigir riscos antes que uma aplicação de IA recupere a informação.
O DLP continua importante para aplicar políticas sobre o uso e o compartilhamento de dados nos pontos cobertos. A governança de identidades limita quem pode agir, enquanto os controles da aplicação restringem ferramentas, operações e destinos.
Na arquitetura de trabalho com IA, a tarefa pode atravessar todos esses controles. A proteção precisa acompanhar esse percurso com responsabilidades claras e evidências de funcionamento.
O assessment gratuito do DSPM Brasil ajuda a identificar lacunas de maturidade em segurança de dados, incluindo acesso, fluxo e uso por IA. Ele oferece um ponto de partida para priorizar melhorias; a validação de cada agente exige também testar sua arquitetura e seus controles específicos.
Fontes
Referências consultadas em 23/09/2026:
