Um único comentário invisível em um pull request do Azure DevOps pode transformar o agente de codificação com IA de um revisor contra ele, levando-o a projetos aos quais o atacante não tem permissão de acesso e vazando silenciosamente o que encontrar.
A falha está no servidor MCP oficial do Azure DevOps, da Microsoft, e funciona porque uma de suas ferramentas retorna descrições de pull request sem a proteção contra prompt injection que a empresa já havia aplicado a outras.
A empresa de segurança ofensiva Manifold Security detalhou o bug de "deputado confundido" nesta semana.
A Microsoft distribui o servidor para que agentes de IA possam ler e operar o Azure DevOps em nome de um usuário, incluindo pull requests, pipelines, wikis e itens de trabalho, tudo com as permissões do próprio usuário.
Esse é o cerne do problema: conteúdo escrito por outras pessoas pode virar instrução para o agente.
As descrições de PR no Azure DevOps aceitam Markdown, o que permite comentários em HTML.
Na interface web, um comentário em HTML (<!-- ...
-->) não aparece, então um revisor que percorre a descrição vê uma mudança aparentemente comum.
A API REST devolve esse conteúdo literalmente, e o servidor entrega esse texto diretamente ao agente.
Essa divisão entre o que o humano vê e o que o modelo recebe é o mecanismo de entrega.
O atacante não fala com o agente, mas planta instruções em um conteúdo que sabe que ele vai ler depois.
Quando o revisor pede ao agente para analisar o PR, o texto oculto pode reescrever o objetivo do agente.
Como ele está operando com as credenciais do revisor, pode agir em projetos que o atacante não consegue acessar.
Segundo a Manifold, esse acesso alcança código-fonte, segredos e itens de trabalho, não apenas a página da wiki que a prova de conceito exfiltrou.
A empresa afirma que a escalada é o caso típico, já que revisores costumam ter acesso mais amplo do que quem abriu o pull request.
O atacante não ganha nada diretamente; ele toma emprestado o acesso do revisor por meio de um texto que o revisor nunca vê.
O caminho do pull request passou sem a proteção
O que eleva o caso acima de um alerta genérico de prompt injection é o fato de a Microsoft já ter enviado uma defesa para isso.
Ao analisar o código-fonte do servidor, a Manifold encontrou o uso de spotlighting, uma técnica presente na própria orientação da Microsoft sobre prompt injection indireta.
Ela envolve encapsular conteúdo não confiável em delimitadores para que o modelo consiga distinguir dados das instruções que deve seguir.
A empresa adicionou isso no PR #1062, em que as ferramentas de página da wiki e de logs de compilação passam suas saídas por uma função auxiliar compartilhada, createExternalContentResponse.
A ferramenta que retorna um pull request, repo_get_pull_request_by_id, nunca chama essa função.
Assim, ela devolve a descrição sem qualquer tratamento, exatamente a superfície que um atacante escreve para explorar.
Confirmou-se que o mesmo caminho continua sem proteção no código-fonte atual até 21 de julho.
Na prova de conceito da Manifold, executada em uma compilação local da versão v2.7.0, um colaborador de um projeto abre um PR com aparência normal, mas o comentário oculto carrega o payload.
Quando o agente inicia a revisão, o rastro de ferramentas executa uma sequência: aciona um pipeline em outro projeto, lê uma página confidencial da wiki que o atacante não pode abrir e publica essa página de volta como comentário no PR, onde o atacante consegue ler.
Um único comentário oculto conduziu toda a sequência, e cada chamada usada ali estava dentro das permissões do agente.
O problema, escreveram os pesquisadores, era "a sequência e a intenção, conduzidas por texto que um humano nunca viu".
A equipe reproduziu o ataque tanto com o Copilot CLI quanto com o Claude Code, o que mostra que ele não está preso a um único agente.
Ainda assim, a cadeia depende de pré-requisitos: texto de PR escrito pelo atacante, um fluxo de trabalho que o entregue a um agente, um revisor com acesso superior ao do atacante e um agente autorizado a executar ferramentas sem pedir confirmação.
A Manifold confirmou que testou esse último ponto com uma configuração de aprovação automática, sem prompts por ferramenta, justamente o tipo de verificação que poderia fazer um revisor notar uma execução estranha de pipeline em outro projeto antes que ela aconteça.
Um token amplo somado a essa postura é onde o risco se concentra.
A demonstração parte do pressuposto de que alguém inicia a revisão, mas a Manifold observa para onde as equipes estão indo: revisão automática, triagem e resumos disparados por gatilhos, sem uma pessoa acionando cada execução ou lendo cada resultado.
Nesse cenário, a descrição plantada dispara sozinha, e o vazamento se prolonga antes de alguém perceber.
O padrão não é novo.
Em maio de 2025, a Invariant Labs mostrou a mesma classe de ataque contra o servidor MCP do GitHub, usando um issue público para levar um agente a ler um repositório privado e vazá-lo por meio de um pull request.
Depois disso, a mesma técnica passou a aparecer em fluxos automatizados de agentes no GitHub.
Esse caso foi um dos exemplos citados por Simon Willison ao batizar a tríade letal: um agente com acesso a dados privados, exposição a conteúdo não confiável e um meio de enviar dados para fora.
Qualquer agente que reúna os três elementos pode ser virado contra o próprio dono por um único trecho de texto, e a maioria dos agentes realmente úteis reúne esses três.
Um porta-voz da Microsoft agradeceu à Manifold por relatar o comportamento sob divulgação coordenada e chamou o caso de "uma classe conhecida de risco de IA", que orienta o trabalho contínuo da empresa em suas proteções.
A Microsoft não informou se mudará o código nem se atribuirá um CVE.
A empresa afirmou que o ataque exige que o atacante já tenha permissão de escrita em um projeto e que um segundo usuário invoque uma ferramenta de IA sobre o conteúdo, além de recomendar que clientes limitem o acesso aos projetos e "revisem as mudanças propostas antes de pedir que uma ferramenta de IA aja sobre elas".
O problema é que, neste caso, o payload fica invisível na interface que o humano analisa.
Até 21 de julho, não havia uma versão corrigida, e não encontrou-se um CVE atribuído à falha em bases públicas.
A versão mais recente, v2.8.0, foi lançada em 24 de junho.
Nenhum relatório público mostra a técnica em uso fora dos próprios testes da Manifold.
A Manifold testou apenas o servidor local baseado em PAT, mas disse que a causa raiz está "no código do servidor, não no transporte".
Por essa lógica, o servidor remoto hospedado também estaria exposto, mas a Manifold não o testou, e a Microsoft não comentou o ponto.
O spotlighting eleva a barreira, mas não encerra a prompt injection por si só.
As defesas continuam sendo as conhecidas: dar ao agente tokens com menor privilégio possível e limitá-lo ao projeto em análise.
Carregar apenas os domínios MCP necessários para a tarefa também ajuda.
No servidor local, isso é restringido com a flag -d.
Também faz sentido manter execuções de pipeline, leitura de wiki e publicação de comentários fora de um conjunto de ferramentas de revisão de código que não tem utilidade para isso.
Para verificar se a cadeia já foi acionada, procure nos rastros de ferramentas do agente por execuções de pipeline em outros projetos, leituras de wiki ou comentários publicados durante a revisão, e inspecione descrições de PR abertas em busca de comentários HTML ocultos.
Um revisor humano que não consegue ver o payload não é um controle de segurança.
A proteção só funciona onde alguém se lembra de aplicá-la.
Ela envolve conteúdo não confiável uma resposta por vez, então a defesa é tão forte quanto o caminho menos coberto.
Um wrapper ausente em uma única função é quase invisível de fora.
Em uma superfície de ferramentas que continua crescendo, lacunas assim surgem mais rápido do que qualquer equipe imagina conseguir auditar.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...