Vulnerabilidade no Microsoft Copilot altera dados em arquivos do Word

Vulnerabilidade no Microsoft Copilot altera dados em arquivos do Word

Uma vulnerabilidade no Microsoft Copilot revelou uma nova dimensão dos ataques de injeção de prompt indireta, nos quais instruções maliciosas são inseridas em conteúdos aparentemente legítimos para influenciar o comportamento de um assistente de inteligência artificial. No caso analisado pelo pesquisador Håkon Måløy, comandos ocultos em documentos do Word podem ser interpretados pelo Microsoft 365 Copilot, levando à alteração de informações e, em determinadas condições, à reprodução dessas instruções em novos arquivos.

O problema é especialmente relevante em ambientes corporativos porque o Copilot não trabalha apenas com aquilo que o usuário digita diretamente. O serviço combina modelos de linguagem, aplicativos do Microsoft 365 e informações disponíveis ao usuário no ambiente corporativo. Recursos associados ao Work IQ também ampliam a capacidade de encontrar e relacionar arquivos e outros conteúdos relevantes para uma tarefa.

Na prática, isso cria um novo problema de proveniência da informação: o usuário pode acreditar que está fornecendo apenas um documento para análise, enquanto o modelo também recebe instruções escondidas dentro desse conteúdo. O caso mostra por que documentos externos, compartilhados ou provenientes de fontes não confiáveis precisam ser tratados como entrada potencialmente hostil quando utilizados por assistentes de IA.

Como funciona a vulnerabilidade no Microsoft Copilot para Word

O conceito central é conhecido como XPIA (Cross-Prompt Injection Attack), ou ataque de injeção cruzada de prompt. Diferentemente de um ataque convencional, no qual o próprio usuário fornece uma instrução maliciosa ao modelo, a XPIA utiliza uma fonte externa de conteúdo para introduzir comandos no contexto da IA.

O problema investigado por Måløy explora justamente uma característica fundamental dos sistemas baseados em linguagem: para compreender um documento, o modelo precisa processar o conteúdo textual presente nele.

Isso cria uma diferença importante entre a experiência humana e a interpretação feita pela inteligência artificial.

Texto invisível para o usuário, mas legível para a IA

Um documento do Word pode conter trechos formatados para praticamente desaparecer da experiência visual, como texto com cor semelhante ao fundo ou tamanho extremamente reduzido. Para uma pessoa que abre o arquivo normalmente, aquele conteúdo pode parecer inexistente.

Entretanto, quando o documento é processado pelo Copilot, a representação textual utilizada pelo sistema pode não preservar a mesma experiência visual oferecida pela interface do Word.

Em determinadas etapas do processamento, características de formatação como cor e tamanho da fonte deixam de funcionar como uma barreira efetiva. O conteúdo textual pode ser extraído e disponibilizado ao modelo sem que a distinção entre “texto visível” e “texto escondido” tenha o mesmo significado que possui para o usuário.

Essa diferença é crucial.

Para o usuário, existe uma página com um relatório aparentemente normal. Para o modelo, pode existir uma sequência muito maior de tokens contendo tanto o relatório quanto instruções adicionais.

É nesse ponto que uma injeção de prompt no Copilot pode ultrapassar a fronteira entre dados e instruções.

A questão não é simplesmente que o modelo “enxerga texto branco”. O problema arquitetural é mais profundo: a IA pode receber conteúdo textual sem compreender automaticamente que determinadas partes foram deliberadamente ocultadas para uma pessoa.

Esse tipo de abordagem aproveita uma limitação conhecida dos sistemas de IA generativa: modelos de linguagem trabalham essencialmente com conteúdo textual e não possuem, por padrão, a mesma percepção visual e contextual que um ser humano tem ao abrir um documento.

0hy4bHdB vulnerabilidade microsoft copilot word injecao prompt
Imagem: TheHackerNews

A propagação silenciosa entre documentos

O aspecto mais preocupante da descoberta é a possibilidade de persistência da instrução maliciosa.

No cenário demonstrado, a instrução incorporada ao documento pode influenciar a geração ou edição realizada pelo Copilot. O modelo pode, por exemplo, modificar informações presentes no documento e, simultaneamente, reproduzir a instrução escondida no arquivo de saída.

Isso transforma um documento contaminado em uma espécie de veículo de propagação.

O fluxo pode ser entendido conceitualmente da seguinte maneira:

documento contaminado → Copilot processa o conteúdo → saída é modificada → instrução oculta é reproduzida → novo documento é criado → novo arquivo pode contaminar outra interação.

Essa característica diferencia o problema de uma simples resposta incorreta gerada por IA.

Uma alucinação normalmente termina quando a resposta é descartada. Uma instrução persistente pode ser transportada para outro arquivo, fazendo com que o conteúdo malicioso acompanhe o ciclo normal de criação e edição de documentos.

Em um ambiente empresarial, isso pode produzir uma cadeia difícil de rastrear. Um relatório recebido de uma fonte externa pode influenciar uma análise. A análise pode gerar um novo documento. Esse novo documento pode ser posteriormente utilizado por outro funcionário ou por outro fluxo automatizado.

A partir daí, determinar qual foi a origem da instrução que alterou o resultado pode se tornar muito mais complicado.

É justamente essa perda de rastreabilidade que torna a questão de proveniência tão importante na segurança de aplicações baseadas em IA.

O papel do Work IQ e do OneDrive

O risco ganha outra dimensão quando considerado dentro da arquitetura moderna do Microsoft 365 Copilot.

O Copilot pode utilizar informações às quais o usuário possui acesso no ambiente do Microsoft 365, incluindo documentos e outros conteúdos corporativos. O Work IQ amplia esse contexto ao permitir que o sistema compreenda informações relacionadas ao trabalho e identifique fontes relevantes para determinadas tarefas.

Isso significa que o Copilot pode deixar de ser simplesmente uma ferramenta que “resume o arquivo aberto”.

Dependendo do recurso utilizado e das permissões existentes, a IA pode buscar contexto adicional no ambiente de trabalho. Arquivos no OneDrive e no SharePoint, por exemplo, podem participar da construção de uma resposta ou análise.

Esse modelo é extremamente útil para produtividade, mas cria uma superfície de ataque igualmente mais complexa.

Se um documento malicioso conseguir influenciar a interpretação do Copilot, a ameaça deixa de estar limitada ao arquivo original. O impacto potencial passa a depender também de quais dados e ferramentas estão disponíveis para aquela interação.

É importante destacar que isso não significa que qualquer documento contaminado possa automaticamente acessar todos os arquivos de uma organização. As permissões do Microsoft 365 continuam sendo uma barreira fundamental.

O problema está em outro lugar: um modelo pode ser manipulado para tratar dados não confiáveis como instruções confiáveis, e quanto maior for o contexto disponível à IA, maior pode ser a consequência de uma decisão incorreta.

Por que a vulnerabilidade no Microsoft Copilot desafia as mitigações tradicionais

A Microsoft já emprega diversas camadas para combater injeções de prompt e ataques XPIA. Essas proteções procuram identificar conteúdos potencialmente maliciosos antes que eles influenciem o comportamento do modelo.

Essas medidas são importantes, mas existe um dilema estrutural.

Para bloquear uma instrução maliciosa escondida em um documento, o sistema precisa primeiro identificar que aquele conteúdo é uma instrução maliciosa.

E para fazer essa identificação, precisa processar o conteúdo.

É justamente aí que surge o chamado problema de fronteira de confiança.

Um filtro pode reconhecer determinadas frases, padrões ou comportamentos conhecidos. Um atacante, porém, pode modificar a forma de apresentação da instrução, alterar seu contexto ou criar uma formulação que não corresponda aos padrões previamente identificados.

Por isso, bloquear uma lista específica de comandos não elimina necessariamente a classe de ataque.

O desafio também não é exclusivo da Microsoft. Injeção de prompt é uma limitação estrutural dos sistemas que combinam linguagem natural com execução de tarefas, principalmente quando conteúdo externo é incorporado ao contexto de um modelo.

Trocar o modelo de linguagem ou ajustar uma proteção específica pode reduzir uma determinada técnica, mas não necessariamente elimina o problema fundamental.

A segurança precisa existir antes, durante e depois do processamento do modelo.

O que a vulnerabilidade no Microsoft Copilot significa para empresas

Para departamentos de TI, o principal aprendizado é que documentos não devem ser considerados automaticamente confiáveis apenas porque são arquivos do Office.

Um documento recebido por email, baixado da internet, obtido de um fornecedor ou compartilhado externamente pode conter conteúdo criado especificamente para influenciar uma ferramenta de IA.

Isso exige uma mudança de mentalidade.

Durante décadas, controles de segurança se concentraram em malware, macros, scripts, executáveis e links. Com a expansão da IA generativa, texto também pode funcionar como uma superfície de ataque.

Organizações que utilizam Copilot em processos financeiros, jurídicos, administrativos ou executivos devem considerar controles adicionais.

Entre as medidas mais importantes estão:

  • Tratar documentos externos como conteúdo não confiável antes de submetê-los a sistemas de IA.
  • Revisar documentos gerados pelo Copilot antes de incorporá-los a processos críticos.
  • Monitorar alterações inesperadas em números, conclusões, nomes e informações sensíveis.
  • Manter permissões do Microsoft 365 no princípio do menor privilégio, reduzindo o impacto potencial de uma manipulação.
  • Utilizar mecanismos de detecção de XPIA disponíveis nos produtos de segurança da Microsoft.
  • Investigar eventos relacionados a interações do Copilot quando houver comportamento anômalo.
  • Evitar decisões totalmente automatizadas baseadas em uma única resposta produzida por IA.
  • Educar usuários corporativos para compreender que conteúdo processado por uma IA também pode carregar instruções maliciosas.

O ponto mais importante é não transformar o Copilot no único mecanismo responsável pela própria segurança.

Instruções de segurança dentro do modelo não devem substituir controles determinísticos externos, validação de dados, autorização, auditoria e revisão humana.

A segurança do Microsoft 365 Copilot depende de mais do que o modelo

A descoberta de Håkon Måløy é relevante porque demonstra uma evolução importante na forma como devemos pensar sobre segurança de IA.

O problema não está apenas em fazer um modelo obedecer a uma instrução errada. Está em permitir que uma instrução escondida em um objeto aparentemente passivo consiga viajar junto com o conteúdo, influenciar uma operação e potencialmente aparecer novamente em um novo artefato.

Esse comportamento aproxima a injeção de prompt de conceitos conhecidos na segurança tradicional, como persistência e propagação.

A diferença é que, nesse caso, o mecanismo de propagação pode ser um fluxo legítimo de produtividade: abrir um documento, resumir seu conteúdo, editar um relatório e criar uma nova versão.

Para empresas que adotam IA em escala, essa distinção é fundamental.

O documento não é apenas informação. Para um sistema de IA, ele também pode conter instruções.

E enquanto os modelos continuarem tendo dificuldades para separar perfeitamente dados de comandos, a segurança do Microsoft 365 Copilot precisará depender de uma combinação de classificação, isolamento, controle de acesso, monitoramento, validação e supervisão humana.

A questão que fica para administradores e equipes de segurança é direta: até que ponto uma empresa está disposta a confiar em um assistente de IA para manipular documentos corporativos críticos sem uma camada independente de verificação?

A descoberta reforça que a adoção de IA em ambientes empresariais não deve ser acompanhada apenas por métricas de produtividade. Confiabilidade, proveniência e resistência à manipulação precisam fazer parte da arquitetura de segurança desde o início.