EMBRACE revela falhas nos limites de segurança de navegadores em assistentes de programação com IA
EMBRACE lembra que um navegador integrado não herda automaticamente os limites de segurança de um navegador independente.
Além de ASPM
AppSec orientada por provas para equipes que desenvolvem com IA
A Plexicus usa AI Swarm Pentest para explorar caminhos autorizados da aplicação, validar o que é explorável e dar às equipes evidências para priorizar a remediação.
Explorar AI Swarm PentestAssistentes de programação com IA combinam cada vez mais navegador, agente, arquivos do projeto e execução de comandos em um único fluxo de desktop. Em 29 de outubro de 2026, a Forever Security publicou o EMBRACE, um estudo de cinco ferramentas: Cursor, GitHub Copilot, OpenAI Codex, Visual Studio Code e Claude Desktop. Os pesquisadores descrevem três tipos diferentes de falha. A principal lição trata de limites de confiança: quando um navegador integrado recebe acesso ou autoridade adicionais, as suposições conhecidas sobre a segurança do navegador podem deixar de valer.
São demonstrações controladas relatadas pelos pesquisadores. Elas não provam que todos os usuários foram comprometidos nem que os cinco produtos tenham a mesma falha. Ainda assim, o caso ajuda equipes a incluir ferramentas de programação com IA no modelo de ameaças das estações dos desenvolvedores.
O que os pesquisadores do EMBRACE relataram
O relatório principal agrupa os resultados em três efeitos. O artigo técnico detalha mecanismos e testes. A tabela resume o relato sem tratar os produtos como equivalentes.
| Assistente analisado | Tipo de falha relatado | O que os pesquisadores demonstraram | Status informado no relatório de 29 de outubro |
|---|---|---|---|
| Cursor | O conteúdo de uma página podia influenciar o agente e chegar à execução de comandos no host | Uma página preparada forneceu instruções ocultas por meio da integração do navegador. O agente pediu um comando; segundo os pesquisadores, tentou novamente depois que o sandbox bloqueou a primeira tentativa. O comportamento dependia do modelo. | Os pesquisadores dizem que o Cursor corrigiu a falha silenciosamente em 1º de outubro. |
| GitHub Copilot | Falsificação do endereço mostrado pelo navegador | Uma página podia informar um endereço diferente para a prévia, confundindo usuário e agente sobre a origem real. | Os pesquisadores dizem que uma versão posterior, 1.1.29, corrigiu a falha antes que enviassem um relato. |
| Codex, Claude Desktop e VS Code | Acesso a arquivos locais além do escopo previsto do projeto | Segundo os pesquisadores, uma prévia local podia ler arquivos fora do projeto. O artigo técnico descreve caminhos diferentes no Codex e no Claude Desktop e VS Code. | Os pesquisadores dizem que os casos do Codex e do VS Code ainda estavam abertos quando o relatório foi publicado. |
Esses status vêm da cronologia de divulgação dos pesquisadores. Não são uma confirmação independente do estado atual de cada versão do fornecedor. Consulte os avisos e lançamentos atuais antes de decidir sobre um incidente ou atualização.
Por que um recurso pode cruzar vários limites de segurança
Um navegador comum foi projetado para separar conteúdo da web da máquina local. Um ambiente de programação com IA pode adicionar recursos para que o assistente inspecione páginas, visualize projetos locais ou aja com base no que vê. Isso cria relações de confiança entre pelo menos quatro componentes:
- A página ou arquivo local, que pode conter conteúdo controlado por um invasor.
- O navegador integrado, que renderiza esse conteúdo e expõe contexto para o aplicativo.
- O assistente, que interpreta o contexto e pode solicitar ferramentas ou ações.
- A máquina do desenvolvedor, que guarda arquivos, credenciais e comandos.
A documentação do navegador integrado do VS Code descreve recursos como pré-visualização de páginas, ferramentas de navegador para agentes e alguns controles de permissão e armazenamento. Esse contexto ajuda a explicar por que essas integrações existem, mas não valida as vulnerabilidades do EMBRACE. Essas alegações vêm da pesquisa da Forever Security.
Os três resultados mostram por que uma revisão não deve parar na pergunta se o modelo seguiu uma instrução. Uma página pode alcançar uma ponte privilegiada, fazer o aplicativo informar uma origem falsa ou explorar uma diferença entre verificações da página principal e o trabalho de um processo em segundo plano. No caso dos arquivos locais, o relatório diz que o assistente não precisou tomar uma decisão errada para que a falha de limite importasse.
O que muda para equipes de AppSec
EMBRACE não é um resultado de análise de código-fonte. A pesquisa trata das propriedades de segurança dos softwares executados nas estações dos desenvolvedores. Um pipeline seguro continua importante, mas a revisão de código não consegue impor a integridade da origem do navegador nem o isolamento do sistema de arquivos de uma IDE.
Trate esses temas como camadas de controle diferentes. Para risco no código, as equipes podem usar Deep Code Analysis e um fluxo de remediação revisado. Para os endpoints, é preciso manter um inventário atualizado das ferramentas de desenvolvimento com IA, de seus navegadores integrados e das permissões concedidas. Um controle que analisa o repositório não impede, por si só, que um aplicativo de desktop cruze um limite da estação.
Para equipes que já adotam desenvolvimento com assistência de IA, nossos guias de segurança em vibe coding e de governança de ferramentas de IA cobrem controles relacionados. O fluxo Proof-Driven AppSec vincula achados de código a evidências e correções revisáveis.
Lista prática de revisão
Use o relatório como ponto de partida para uma revisão específica por produto, não como um veredito geral para toda instalação:
- Inventarie o aplicativo e a versão exata. Inclua prévias dentro de editores e assistentes de desktop, não apenas navegadores independentes.
- Separe a origem real da página do contexto exibido. Confirme que o aplicativo deriva a origem do estado real de navegação, sem confiar em um rótulo enviado pela página.
- Teste os limites de arquivos locais. Prévias não devem ler além de um espaço de trabalho autorizado, inclusive em processos em segundo plano.
- Limite ações do agente de forma independente. O conteúdo do navegador não deve virar autorização silenciosa para executar comandos. Aprovações, política do sandbox e escopo de execução precisam ser impostos fora do raciocínio do modelo.
- Reduza exposição e caminhos de saída. Aplique privilégio mínimo e controles de saída adequados para que uma prévia não alcance segredos ou serviços sem relação.
- Acompanhe o status do fornecedor. O relatório data suas afirmações de correção. Confira avisos e versões atuais antes de classificar uma compilação como vulnerável ou corrigida.
Um clique ou tecla não é um limite robusto quando é solicitado por uma ferramenta que o usuário já considera confiável. Pode ser parte da defesa, mas deve vir junto da validação de origem, acesso limitado a arquivos e controles de execução efetivos.
A lição mais ampla
EMBRACE não mostra que assistentes de programação com IA sejam inerentemente inseguros. Mostra que adicionar um agente a um componente de segurança maduro altera o modelo de ameaças. Isolamento do navegador, confiança no projeto, aprovação de comandos e permissões da estação precisam ser testados em conjunto, pois a integração pode conectá-los de formas diferentes dos componentes originais.
A Plexicus se concentra em análise de segurança de aplicações e fluxos de remediação. Esses controles atuam em outra camada que o isolamento de navegadores de desktop. As equipes devem avaliar ambos, sem esperar que um substitua o outro. Se você estiver mapeando controles para desenvolvimento assistido por IA, fale com a Plexicus sobre a parte de segurança de aplicações.
Fontes
- EMBRACE: navegadores integrados em cinco assistentes de desktop, Forever Security, 29 de outubro de 2026.
- Visão técnica do EMBRACE, Forever Security, 29 de outubro de 2026.
- Documentação do navegador integrado, Microsoft, consultada em 30 de outubro de 2026.
