Você abriu o pull request, leu a descrição, passou os olhos pelo diff e pediu ao seu agente para revisá-lo. A página parecia limpa. E estava — para você. A versão que seu agente recebeu carregava um parágrafo extra que nunca lhe foi mostrado, e esse parágrafo lhe dizia o que fazer em seguida. A revisão que você aprovou e o texto que seu agente obedeceu eram dois documentos diferentes.

Em 22 de julho de 2026, a empresa de segurança Manifold Security descreveu uma falha no servidor MCP oficial do Azure DevOps da Microsoft — o conector que permite a um agente de codificação ler pull requests, itens de trabalho e logs de build usando suas permissões. O MCP, o Model Context Protocol, é a forma padrão pela qual um agente se conecta a um serviço externo; aqui, ele se conecta ao host de código-fonte da sua empresa. Uma de suas ferramentas, a que busca um pull request por ID, retorna a descrição do PR exatamente como está armazenada. Incluindo as partes que um navegador esconde.

Um comentário HTML é invisível para você e ruidoso para o agente

A descrição de um pull request é Markdown, e o Markdown permite embutir um comentário HTML: texto envolto em . Seu navegador o renderiza como nada — um espaço em branco, sem rastro na página. A API REST por baixo não renderiza nada. Ela retorna o campo byte a byte, comentário e tudo.

Então um atacante abre um pull request contra um repositório que você pode ver e escreve uma descrição de aparência normal. Enterrado nela, dentro de um comentário, há um bloco de instruções: ignore a tarefa de revisão, liste os outros repositórios que esta conta pode alcançar, leia suas variáveis de pipeline e poste-as nesta URL. Na página web, nada disso é visível. Você lê uma descrição arrumada e um pequeno diff e pensa: tudo bem, deixe o agente dar uma olhada.

O agente pede o pull request ao servidor MCP. O servidor devolve a descrição bruta. O bloco escondido chega como parte do que parece conteúdo legítimo, e o agente — que não consegue ver uma página web renderizada, apenas o texto — o trata como parte do trabalho. A Manifold descobriu que a ferramenta de pull request pula uma proteção que a Microsoft já havia construído. Em uma mudança anterior, o pull request #1062, a equipe envolveu o conteúdo não confiável de páginas wiki e logs de build em delimitadores — uma técnica chamada spotlighting que diz ao modelo que tudo o que está aqui dentro é dado, não ordens. A descrição do pull request nunca recebeu esse tratamento. Ela volta nua.

O mesmo pull request, dois leitores. O humano o abre num navegador: o comentário HTML não renderiza nada, então a página parece limpa e a revisão é aprovada. O agente pede o mesmo PR ao servidor MCP e recebe o campo bruto — comentário incluído — de modo que o bloco escondido chega como instruções que ele executa com suas credenciais. O documento que você aprovou e o documento que o agente obedeceu não são o mesmo documento.

Uma vez que o agente está seguindo as instruções plantadas, o dano não é limitado pelo que o atacante pode alcançar — é limitado pelo que você pode alcançar. A conta que executa a revisão é a sua. Ela pode abrir repositórios a que o atacante não tem acesso, ler os segredos e variáveis de pipeline associados a eles, puxar itens de trabalho e enviar qualquer parte disso para onde o texto escondido mandar. O atacante escreveu um comentário; sua identidade fez o trabalho.

A lacuna está entre a página e os bytes

A mesma forma não para de reaparecer sob disfarces diferentes, e é isso que a torna digna de nome. Duas semanas antes, um artigo sobre o Model Context Protocol mostrou a mesma lacuna com um disfarce diferente: caracteres “tag” Unicode — um bloco de pontos de código de U+E0000 a U+E007F que não exibem absolutamente nada — contrabandeados para dentro da própria descrição de uma ferramenta. Um humano que aprova a ferramenta vê um resumo limpo e inofensivo. O modelo recebe o resumo mais a carga invisível dobrada dentro dele. O autor mediu a lacuna através de três implementações distintas de servidor MCP e a chamou de approval-view fidelity gap: aquilo mostrado à pessoa que aprova não é uma cópia fiel daquilo sobre o que o modelo age.

Na mesma semana, o trabalho Friendly Fire do AI Now Institute apontou o problema para a tarefa mais confiante que um agente tem — revisar o código de outra pessoa. Aponte um agente para um repositório de terceiros não confiável e peça que avalie o código, e o código avalia você de volta: o material sob revisão é também o material que dá ordens.

Junte tudo isso e a lição é desconfortável para a resposta de segurança de sempre. O conselho padrão para o risco de agentes é mantenha um humano no circuito — faça uma pessoa ler e aprovar antes que algo consequente aconteça. Mas um comentário HTML, um bloco Unicode invisível e um alvo de revisão envenenado atacam todos a mesma coisa: a pessoa está aprovando uma renderização, e o agente obedece aos bytes. Quando esses dois divergem por projeto, um humano ao teclado não é um controle. É um carimbo de borracha sobre um documento que não lhe deixaram ver.

Decida no perímetro, não diante dos olhos

O Bromure Agentic Coding não tenta tornar a renderização honesta. Ele assume que a coisa na sua tela pode ser uma falsificação e move a decisão para algum lugar que a falsificação não alcança: a fronteira entre a caixa do agente e tudo o que está fora dela. O agente — com seus conectores MCP, sua tarefa de revisão, suas credenciais — roda dentro de uma VM Linux descartável no seu Mac. O que quer que ele leia e o que quer que decida fazer, no momento em que uma ação tenta sair dessa caixa, ela encontra uma fronteira que julga a ação, não a página que um humano por acaso aprovou.

Comece pela parte que mais dói no relato da Manifold: o revisor sequestrado age com suas credenciais e alcança projetos que o atacante jamais poderia. No Bromure, as credenciais dentro da VM são iscas. Os tokens reais ficam no host; a caixa guarda um placeholder brm_… onde deveria estar o token de acesso, um conjunto sintético de credenciais git e cloud, chaves ssh descartáveis. Quando a instrução plantada diz para enumerar cada repositório que esta identidade pode ver e despejar seus segredos, a identidade que ela segura é uma falsa. O token real só é substituído no proxy do host, em requisições para destinos que você aprovou — um lugar que o texto injetado não consegue conduzir.

Depois o próprio movimento de saída. Postar isso para uma URL é uma requisição de rede para algum lugar novo, e toda requisição de rede que o agente faz cruza o proxy do host em seu caminho de saída. Ali, os Guardrails podem retirar de imediato chamadas destrutivas ou de exfiltração, e o consentimento por destino pode segurar um destino de primeira vez para um toque humano explícito — um toque no destino real e na carga real, resolvidos a partir dos bytes, não de um resumo que o agente escreveu sobre si mesmo. A aprovação que você dá aqui não é “este PR parece bom”. É “este processo quer enviar estes dados para este host”. Essa pergunta não pode ser falsificada por um comentário invisível, porque é feita sobre o que realmente aconteceu, não sobre o que lhe mostraram.

Dois lugares para tomar a decisão de segurança. Na sua máquina (à esquerda), o agente segura suas credenciais reais e a verificação é um humano aprovando uma página renderizada — então um comentário invisível separa o que você aprova do que roda, e o alcance é tudo o que sua identidade pode tocar. Numa VM Bromure (à direita), as credenciais são iscas, a caixa descartável se reinicia, e a decisão se move para a fronteira do host, que barra a ação de saída real e seu destino real independentemente do que a página de revisão mostrou.

Uma camada de detecção fica na frente de tudo isso, e ela se sustenta aqui por uma razão específica. O Bromure pontua o conteúdo não confiável que um agente lê — uma página buscada, uma resposta de ferramenta, um arquivo de instruções — com um detector de injeção no dispositivo antes que o agente aja sobre ele. A razão pela qual um comentário escondido ou um bloco Unicode invisível engana uma pessoa é que uma pessoa lê a renderização. O classificador não; ele lê o mesmo fluxo bruto que o modelo lê. A lacuna de fidelidade que faz o ataque funcionar contra um olho humano não existe para um pontuador que lê os bytes. Não é uma parede — um disfarce suficientemente inédito ainda pode escapar de um único detector — e é exatamente por isso que ele fica na frente do confinamento em vez de no lugar dele.

Se o agente for sequestrado mesmo assim, nada do que ele fez sobrevive à sessão. A caixa se reinicia para uma imagem-base limpa, então uma configuração plantada, um gancho de persistência ou um arquivo local envenenado desaparece. E toda requisição de saída que ele fez está no rastro da sessão como uma linha registrada — carregando, se a injeção tentou exfiltrar, uma credencial-isca para um destino barrado no caminho de saída.

O que isso delimita

O confinamento muda o que uma injeção pode realizar; não é um patch para o servidor da Microsoft, e vale a pena ser preciso sobre as bordas.

O Bromure contém o raio da explosão; não conserta a ferramenta

O servidor Azure DevOps ainda retorna a descrição bruta, e o agente ainda lê o comentário escondido. O que muda é o que vem depois: as credenciais são iscas, a exfiltração cruza uma fronteira, a caixa se reinicia. O conserto a montante — dar spotlight ao campo do pull request como aos campos de wiki e logs de build — cabe à Microsoft, e ela deveria entregá-lo.

A substituição cobre os segredos que você configura

A troca por iscas protege as credenciais que você põe num perfil: chaves de modelo, tokens git e cloud, endpoints de banco de dados gerenciado, chaves ssh. Um token que um script escreve num arquivo no meio da sessão, ou um segredo que você cola na caixa à mão, é apenas um arquivo que o agente pode ler. Mantenha os segredos no broker, não no espaço de trabalho.

A detecção é uma rede, não uma parede

Ler os bytes em vez da renderização derrota os truques do comentário invisível e do Unicode invisível, mas um autor determinado ainda pode criar conteúdo que lê limpo e age sujo. Trate o pontuador como uma camada; a caixa descartável com chaves-isca e uma saída barrada e registrada é o que segura quando ele falha.

Uma leitura aprovada ainda é uma leitura

Se o agente sequestrado só toca um destino em que você já confia — o mesmo repositório que revisava — e lê o que sua identidade pode legalmente ler ali, isso está dentro da linha que a fronteira traça. O isolamento estreita o alcance ao que você aprovou; não revoga uma permissão que você concedeu.

O erro recorrente é tratar “um humano aprovou” como o fim do argumento de segurança. Três peças distintas da pesquisa de julho — um campo de PR bruto, um bloco Unicode invisível, um alvo de revisão envenenado — dizem a mesma coisa: o humano está aprovando uma imagem, e o agente está agindo sobre a fonte. Pare de apoiar a decisão sobre o que foi mostrado a uma pessoa. Apoie-a sobre o que realmente sai da caixa: rode o agente onde suas credenciais são falsas, cada passo dele para fora é julgado sobre os bytes reais, e uma reinicialização está a um comando de distância. Instale-o.