Imagine que uma pessoa da área financeira receba uma análise de mercado de uma fonte externa. O arquivo parece normal. Ela usa o documento como referência no Copilot para criar o relatório trimestral da empresa.
O relatório produzido também parece normal — mas alguns números foram alterados silenciosamente. Além disso, instruções invisíveis presentes no documento externo foram copiadas para o novo arquivo. Quando esse relatório interno é usado como fonte para outro documento, as instruções voltam a atuar e são propagadas novamente.
O arquivo que chegou de fora deixou de ser necessário. O novo vetor agora é um documento criado dentro da própria organização, por um usuário legítimo, em um fluxo de trabalho cotidiano.
Esse foi o cenário demonstrado pelo pesquisador Håkon Måløy em uma divulgação técnica publicada em 28 de julho de 2026. Ele chamou o comportamento de um document-borne AI worm: um “worm de IA” capaz de se propagar entre documentos usados pelo Copilot no Word.
O caso não deve ser tratado como notícia de uma epidemia digital. A publicação descreve uma prova de conceito coordenada com o Microsoft Security Response Center, não apresenta evidência de exploração ativa e não atribui um CVE ao cenário. Ainda assim, ela expõe uma questão que vai muito além de uma vulnerabilidade pontual:
Quando a IA transforma documentos em novos documentos, como provar que a informação continua íntegra, de onde ela veio e quais outros arquivos herdaram o conteúdo?
Essa é uma pergunta de DSPM.
O que a pesquisa demonstrou
O ataque começa com uma forma de prompt injection indireta. Em vez de alguém digitar uma instrução maliciosa diretamente no chat, o comando fica escondido em um conteúdo que a IA precisa processar — neste caso, um documento do Word.
No cenário publicado, as instruções foram ocultadas com recursos de formatação, como texto branco sobre fundo branco e fonte pequena. Para o usuário, o conteúdo era praticamente invisível. Para o Copilot, que precisava extrair o texto do documento para utilizá-lo como contexto, as instruções continuavam legíveis.
O fluxo demonstrado teve duas etapas:
- Entrada e manipulação: um documento controlado pelo atacante era incluído entre as fontes utilizadas pelo Copilot no Word. As instruções ocultas influenciavam a geração e faziam a ferramenta alterar informações do documento resultante.
- Propagação: as mesmas instruções eram copiadas para o arquivo produzido. Quando esse novo documento era utilizado em outra sessão, o comportamento se repetia mesmo sem a presença do arquivo malicioso original.
Segundo a pesquisa, o primeiro documento poderia chegar por SharePoint, Teams, Outlook ou qualquer outro mecanismo de compartilhamento. Dependendo da experiência do Copilot em uso, a pessoa precisaria anexá-lo ao prompt ou a própria ferramenta poderia encontrá-lo no OneDrive ao buscar fontes consideradas relevantes.
No exemplo apresentado, números de relatórios financeiros foram alterados e as instruções foram copiadas para os documentos derivados. Isso não significa que qualquer arquivo provoque o comportamento automaticamente. O ataque depende de o documento contaminado entrar no contexto do Copilot e de as instruções conseguirem influenciar o modelo.
O ponto crítico: depois da primeira propagação, o próximo vetor pode ser um documento interno aparentemente legítimo. A confiança concedida à origem do arquivo passa a esconder a origem real das instruções que influenciaram seu conteúdo.
O que foi mitigado — e o que permaneceu em discussão
A cronologia importa para não transformar uma pesquisa séria em alarmismo.
O relatório inicial foi enviado ao MSRC em 6 de março de 2026. A divulgação pública ocorreu em 28 de julho, depois de um período coordenado de 144 dias e duas extensões. Durante esse intervalo, a Microsoft implantou diferentes mitigações.
De acordo com Måløy, os payloads originalmente enviados foram mitigados. As correções elevaram a dificuldade do ataque e exigiram novas formulações para reproduzir o comportamento. Entretanto, o pesquisador afirma que conseguiu reproduzir novamente a cadeia completa com payloads modificados em 15 e 28 de julho, mesmo com as mitigações disponíveis.
A distinção correta é esta:
- payload específico: a formulação concreta usada em um teste pode ser bloqueada;
- classe de ataque: conteúdo não confiável continua dividindo o contexto computacional com a intenção do usuário e pode tentar influenciar o comportamento do modelo;
- redução de exposição: controles operacionais e técnicos diminuem probabilidade e impacto, mas não equivalem necessariamente a eliminar a classe arquitetural.
Na data da publicação, o pesquisador afirmou não conhecer uma remediação do lado do cliente que resolvesse completamente o problema mais amplo. Isso é uma afirmação do autor da pesquisa sobre o estado de seus testes, não uma declaração de que nenhuma proteção funciona ou de que todos os ambientes estejam vulneráveis da mesma maneira.
EchoLeak perguntava “quem pode ler?”. Este caso pergunta “podemos confiar?”
Nos casos EchoLeak e SearchLeak, o risco central era a possibilidade de explorar o contexto do Copilot para expor informações sem depender de um clique tradicional. O debate estava fortemente ligado à confidencialidade: quais dados poderiam ser localizados, recuperados e enviados para fora.
O “worm de IA” acrescenta outros elementos da segurança da informação:
| Dimensão | Pergunta tradicional | Pergunta trazida pela IA |
|---|---|---|
| Confidencialidade | Quem consegue acessar o documento? | Quais dados a IA consegue recuperar e combinar? |
| Integridade | O arquivo foi alterado por alguém? | A IA modificou significado, números ou decisões sem evidência clara? |
| Proveniência | Quem criou o documento? | Quais fontes e instruções participaram da geração? |
| Linhagem | Onde está a versão anterior? | Quais documentos derivados herdaram aquele conteúdo? |
| Resposta | Qual máquina ou conta foi comprometida? | Quais artefatos gerados precisam ser encontrados, revisados ou isolados? |
Permissões continuam essenciais. Se o Copilot consegue encontrar uma quantidade excessiva de documentos, o conjunto potencial de entradas não confiáveis e o raio de impacto aumentam. Por isso, corrigir acesso amplo no Microsoft 365 continua sendo parte da resposta.
Mas least privilege sozinho não prova que um documento autorizado é confiável. Um usuário pode ter permissão legítima para ler um arquivo que contém uma instrução maliciosa. O problema está na fronteira entre dado a ser analisado e comando a ser executado.
Por que isso é um problema de DSPM
Uma estratégia de DSPM precisa acompanhar o dado durante todo o seu ciclo: descoberta, classificação, acesso, movimentação, uso por IA e resposta a incidentes. Quando a IA cria um novo artefato a partir de vários documentos, o fluxo deixa de ser apenas “usuário abriu arquivo”.
Ele se parece mais com:
documento externo → repositório corporativo → contexto da IA → documento gerado → compartilhamento → nova geração
Cada domínio responde a uma parte diferente do problema.
Data Discovery: localizar fontes e derivados
Não é possível investigar propagação se a organização não sabe onde estão seus documentos, quais repositórios alimentam a IA e quais cópias foram criadas. A descoberta precisa considerar SharePoint, OneDrive, Teams, e-mail e repositórios conectados.
Data Classification: preservar o contexto de sensibilidade
Se um relatório confidencial é utilizado para gerar um resumo, o documento derivado não deveria nascer sem classificação. A política precisa definir quando rótulos e restrições acompanham o conteúdo transformado — inclusive quando somente parte da fonte aparece no resultado.
Data Access Governance: limitar o universo disponível
O Copilot respeita as permissões existentes, mas ambientes superexpostos permitem que ele alcance muito mais conteúdo do que o necessário. Revisar permissões, links, convidados e grupos amplos reduz o universo que pode ser recuperado e reutilizado.
Data Flow Mapping: registrar a linhagem
O mapa de fluxo precisa mostrar mais do que origem e destino de uma transferência. Em processos assistidos por IA, ele deveria responder:
- quais documentos foram usados como fonte;
- qual aplicação ou agente processou o conteúdo;
- qual identidade iniciou ou autorizou a ação;
- qual novo artefato foi produzido;
- onde o resultado foi armazenado e compartilhado;
- quais processos posteriores reutilizaram esse resultado.
Sem essa cadeia, um documento contaminado pode ser encontrado, mas seus descendentes permanecem invisíveis.
AI Data Risk: tratar conteúdo como parte da superfície de ataque
Documentos, páginas, e-mails e respostas de ferramentas não são apenas conhecimento para o modelo. Eles também podem carregar texto capaz de disputar o controle da tarefa. A OWASP recomenda tratar todas as entradas externas como não confiáveis, aplicar menor privilégio, validar saídas, proteger memória e contexto e exigir aprovação para ações de alto impacto.
Isso se torna ainda mais importante quando agentes de IA possuem identidade corporativa, ferramentas e permissão para escrever, enviar ou publicar documentos sem uma revisão humana a cada etapa.
Detection & Response: investigar a cadeia, não somente o arquivo inicial
Uma resposta tradicional poderia remover o documento de entrada e encerrar o caso. Se as instruções já foram copiadas para artefatos derivados, isso não basta.
A investigação precisa partir do possível documento contaminado e percorrer versões, fontes, documentos gerados, compartilhamentos e reutilizações. Também precisa registrar as decisões: quais arquivos foram isolados, quais números ou afirmações foram validados novamente e quem aprovou o retorno ao fluxo normal.
O que as organizações podem fazer agora
Não existe um botão único capaz de resolver uma classe de ataque que explora a mistura entre instruções e dados. Ainda assim, algumas medidas reduzem a exposição e tornam a investigação possível.
1. Trate fontes externas como entradas não confiáveis
Crie uma distinção operacional entre documentos internos controlados, documentos recebidos de terceiros e conteúdo obtido da internet. Para processos de alto impacto, não permita que uma fonte externa entre diretamente no fluxo de geração sem triagem.
Essa classificação não deve depender apenas do remetente. Um parceiro legítimo pode repassar um documento já afetado sem saber.
2. Defina revisão humana pelo impacto da decisão
Relatórios financeiros, pareceres jurídicos, comunicações externas, dados regulatórios e decisões sobre pessoas exigem revisão independente. A pessoa que aprova deve verificar números e afirmações contra as fontes, não apenas ler se o texto “parece correto”.
Revisão humana genérica pode se transformar em clique automático. O controle precisa dizer o que comparar, qual evidência guardar e quem possui autoridade para aprovar.
3. Registre fontes e alterações realizadas pela IA
Sempre que a plataforma permitir, preserve referências utilizadas, versões, identidade, data, ferramenta, modelo ou experiência aplicada e alterações aceitas. Metadados de proveniência não impedem prompt injection, mas reduzem o tempo necessário para reconstruir a cadeia.
Onde a plataforma não oferece rastreabilidade suficiente, trate isso como risco explícito do processo e limite o uso em decisões críticas.
4. Reduza descoberta e acesso desnecessários
Remova grupos amplos, links antigos, convidados sem justificativa e permissões herdadas indevidamente. O objetivo não é esconder tudo da IA; é garantir que cada identidade — humana ou agente — tenha acesso apenas ao conteúdo necessário para sua função.
5. Monitore comportamentos e saídas anômalas
Defina sinais que merecem investigação: alterações inesperadas em números, inclusão de texto oculto, mudanças de formatação incomuns, documentos derivados sem fonte conhecida, criação automatizada em volume e compartilhamentos fora do padrão.
Nenhum sinal isolado prova um ataque. O valor está em combinar evento, identidade, origem, classificação e sequência de geração.
6. Inclua documentos derivados no plano de resposta
O playbook deve prever busca por artefatos descendentes, validação do conteúdo, contenção de compartilhamento, comunicação aos usuários afetados e critérios de liberação. Se o documento apoiou uma decisão financeira, jurídica ou operacional, a resposta também precisa avaliar o impacto da decisão tomada.
A pergunta prática: se hoje um relatório fosse identificado como manipulado pela IA, sua equipe conseguiria descobrir quais documentos posteriores usaram aquele relatório como fonte?
Checklist para CISO, DPO e Microsoft 365
- Sabemos quais repositórios e conectores podem fornecer contexto ao Copilot e aos agentes?
- Documentos externos recebem tratamento diferente antes de entrar em processos críticos?
- Conseguimos identificar as fontes utilizadas na geração de um documento?
- Classificação e proteção acompanham o conteúdo derivado?
- Alterações feitas pela IA permanecem rastreáveis depois que o usuário aceita o resultado?
- Agentes e assistentes possuem apenas as permissões necessárias para ler e escrever?
- Processos financeiros, jurídicos e regulatórios exigem validação independente das fontes?
- Monitoramos texto oculto, mudanças numéricas e geração fora do padrão?
- O plano de resposta inclui busca e isolamento de documentos derivados?
- Testamos prompt injection indireta com documentos, e-mails e páginas controladas?
Se várias respostas forem “não”, a organização pode até controlar quem abre cada arquivo, mas ainda não controla adequadamente como a IA transforma e propaga as informações contidas neles.
Conclusão
O “worm de IA” demonstrado no Word não é importante apenas porque instruções ocultas conseguiram influenciar o Copilot. Ele é importante porque transforma documentos produzidos em fluxos legítimos em possíveis portadores de um risco herdado.
Esse cenário quebra uma premissa comum: a de que um arquivo interno, criado por uma pessoa conhecida e armazenado em um repositório autorizado, é confiável por definição.
Na era da IA, uma estratégia de segurança de dados precisa responder a três perguntas:
- De onde essa informação veio?
- O que a IA modificou?
- Quais outros documentos herdaram o resultado?
DSPM não pode se limitar a localizar dados sensíveis e corrigir permissões. Precisa conectar acesso, contexto de IA, classificação, fluxo, integridade e resposta. O ativo protegido não é somente o arquivo original: é a cadeia de confiança que sustenta as decisões da organização.
O assessment gratuito do DSPM Brasil ajuda a identificar lacunas em AI Data Risk, Data Flow Mapping, Access Governance e Detection & Response — antes que um fluxo aparentemente produtivo se transforme em uma cadeia impossível de rastrear.
Fontes
Fontes consultadas em 03/08/2026:
- Context Collapse, Part 3 — AI Worming through Word, Håkon Måløy, publicado em 28/07/2026 e atualizado em 30/07/2026.
- AI Agent Security Cheat Sheet, OWASP Cheat Sheet Series.
O comportamento descrito pode variar conforme produto, configuração e atualizações posteriores. Antes de tomar decisões técnicas, confirme o estado atual das proteções na documentação do fornecedor e no ambiente da organização.
