O worm de IA no Word muda a segurança corporativa

O caso mais importante da semana em IA não é um modelo novo: é a demonstração de que um documento do Word pode carregar instruções ocultas, fazer o Copilot alterar outro arquivo e ainda copiar o ataque para frente. Isso importa porque transforma prompt injection em risco de integridade documental, com impacto direto em relatórios, contratos, análises financeiras e fluxos internos que empresas já tratam como confiáveis.

Em 28 de julho de 2026, o pesquisador Håkon Måløy publicou Context Collapse, Part 3 - AI Worming through Word, análise feita em divulgação coordenada com a Microsoft Security Response Center. Segundo o relato, o processo durou 144 dias e começou em 6 de março de 2026. O ponto central: instruções controladas por um atacante, escondidas em um documento externo, podem ser lidas pelo Copilot para Word como se fossem parte legítima da tarefa do usuário.

O que aconteceu no Copilot para Word?

O cenário descrito é simples e desconfortável. Um funcionário recebe ou baixa um documento aparentemente comum, por exemplo uma análise de mercado. Dentro dele há instruções escondidas, como texto branco sobre fundo branco ou fonte muito pequena. Para o usuário, aquilo pode ser invisível. Para o modelo, não: ao montar o contexto, o Copilot processa o texto sem depender da aparência visual original.

No exemplo do pesquisador, o Copilot para Word foi induzido a alterar números de relatórios financeiros e copiar o payload adiante. Ao ser reutilizado como fonte, o novo arquivo virava o próximo vetor. A linha do tempo também pesa: a Microsoft teria aplicado uma mitigação em 4 de abril de 2026 e outra em 14 de julho de 2026, incluindo upgrade do modelo subjacente, mas o autor afirma ter reproduzido o comportamento em 15 de julho usando GPT-5.6, descrito por ele como o modelo mais recente disponível no teste.

Esse tipo de ataque é uma variação de XPIA, ou Cross-Domain Prompt Injection Attack. A instrução maliciosa não vem do usuário diretamente, mas de outro domínio de confiança: documento, e-mail, página, memória, base RAG ou ferramenta externa. O OWASP coloca prompt injection como risco central em aplicações com LLMs no LLM01:2025, justamente porque o modelo recebe instruções e dados dentro da mesma janela de contexto.

Por que isso importa mais que uma resposta errada?

Quando uma IA erra em um chat isolado, o dano costuma ser local: alguém revisa, descarta ou corrige. Em um pacote de produtividade, o assistente participa de fluxos que geram artefatos duráveis: atas, propostas, contratos, relatórios, políticas internas, apresentações e análises de risco. Esses documentos circulam, são versionados, anexados a processos e reutilizados como fonte.

O problema muda de categoria. Não é só “o modelo alucinou”. É “o fluxo de trabalho perdeu separação confiável entre dado e comando”. Para desenvolvedores, isso é falha de arquitetura de aplicação, não defeito cosmético do prompt. Para empresas, é governança da informação.

Algumas consequências práticas:

• Integridade vira prioridade: o risco principal pode ser alterar números, cláusulas, datas ou premissas sem chamar atenção.
• Proveniência passa a ser requisito: documentos gerados por IA precisam registrar fontes, transformações e trechos modificados.
• Confiança interna enfraquece: um arquivo criado por um colaborador pode carregar instruções herdadas de um terceiro.
• Revisão visual não basta: conteúdo invisível para humanos pode continuar disponível para o modelo.
• Mitigação por prompt é frágil: filtros e mensagens de sistema reduzem risco, mas não resolvem a mistura estrutural de instrução e conteúdo.

O que muda para desenvolvedores?

Para quem constrói produtos com LLMs, o aprendizado é direto: trate qualquer conteúdo recuperado, anexado, copiado, raspado ou enviado por terceiros como dado hostil. Isso vale para RAG, agentes com ferramentas, copilotos internos e workflows que escrevem em sistemas de registro.

Um padrão saudável é separar explicitamente papéis e permissões. Documento não deve poder emitir comando. Resultado de busca não deve poder autorizar ação. E-mail não deve poder alterar política de execução. Muitos produtos de IA ignoram essa fronteira porque tudo acaba virando texto dentro do prompt.

input_trust:
  user_request: instruction
  system_policy: instruction
  retrieved_documents: untrusted_data
  email_body: untrusted_data
  generated_draft: quarantined_output

allowed_actions:
  untrusted_data:
    - summarize
    - quote_with_source
    - extract_fields
  blocked:
    - change_policy
    - hide_text
    - call_external_tool
    - write_to_final_document_without_review

Esse exemplo não é solução completa, mas mostra a mentalidade correta: a aplicação precisa carregar metadados de confiança junto com o texto. O modelo pode resumir um documento externo, mas a camada de produto deve impedir que esse documento defina regras, esconda conteúdo, acione ferramentas ou contamine saídas finais sem revisão.

Também vale implementar controles fora do modelo: comparar versões, destacar alterações numéricas, bloquear texto invisível antes da indexação, registrar fontes do contexto e exigir aprovação humana para escrita em documentos finais, tickets, contratos ou registros financeiros.

Como empresas devem reagir agora?

A reação prática não é banir Copilot, ChatGPT Enterprise, Gemini ou qualquer assistente. É parar de tratar documentos internos como automaticamente confiáveis só porque passaram por uma pessoa da empresa. O caso mostra que a cadeia de confiança pode ser contaminada antes do primeiro uso interno e continuar se propagando depois.

Em curto prazo, empresas deveriam revisar três pontos. Primeiro, políticas de uso: documentos externos usados como fonte para IA precisam ser classificados como não confiáveis. Segundo, observabilidade: documentos gerados ou editados por IA devem manter trilha de fontes, trechos alterados e identidade do usuário que aprovou a mudança. Terceiro, arquitetura: sistemas internos com LLMs devem separar contexto, intenção, permissão e escrita final em etapas verificáveis.

O impacto maior é cultural e técnico ao mesmo tempo. A era dos copilotos corporativos obriga engenharia, segurança, jurídico e operações a tratar linguagem natural como superfície de ataque. Isso não torna IA inviável. Torna ingênua a ideia de que basta trocar de modelo e esperar que ele separe usuário de documento malicioso.

Perguntas frequentes

O que é um worm de IA em documentos?

É um ataque em que instruções ocultas dentro de um documento fazem um assistente de IA alterar uma saída e copiar o próprio ataque para novos arquivos, permitindo propagação por fluxos normais de trabalho.

O Copilot para Word foi corrigido?

Segundo a análise publicada em 28 de julho de 2026, a Microsoft aplicou mitigações, mas o pesquisador afirma que a classe de vulnerabilidade ainda era reproduzível no momento da divulgação.

Prompt injection afeta só chatbots?

Não. O risco é maior em copilotos, agentes e sistemas com RAG, porque eles leem documentos, e-mails, páginas e bases externas antes de executar tarefas ou gerar arquivos.

Como reduzir risco de prompt injection em empresas?

Separe dados não confiáveis de instruções, registre fontes, revise alterações feitas por IA, bloqueie conteúdo oculto e limite ações automatizadas com permissões explícitas e auditoria.