Esta não exigiu exploit nenhum. O agente confinado rodou um comando de shell contra uma porta local, pediu ao sandbox que o continha para se desligar, e o sandbox concordou.

O DeepSeek Harness executa os comandos de um agente de codificação dentro de um sandbox do sistema operacional. O sandbox é estreito e deliberado: as escritas de arquivos ficam dentro do workspace e das pastas temporárias, e todo o resto do que o agente faz é problema de outra pessoa. A própria referência de linha de comando do projeto diz isso. Nas configurações padrão, “as leituras e o acesso de rede não são confinados”.

O harness também tem uma interface web. Ela roda na mesma máquina, numa porta HTTP local, e o harness entrega o endereço dela ao shell do agente para que as ferramentas possam falar com ela. Essa interface é o plano de controle: ela guarda o modo de uma sessão, incluindo o modo chamado danger-full-access, que desliga o sandbox e interrompe os pedidos de aprovação.

Os dois desenhos são comuns. Coloque um ao lado do outro e o agente consegue desligar o próprio sandbox com um comando, porque o sandbox nunca cobriu o loopback e o plano de controle nunca verificou quem estava chamando.

Pesquisadores da OX a encontraram. A VulnCheck a publicou em 8 de setembro como CVE-2026-82533, CVSS 9,4. Funcionava numa instalação padrão, sem exposição de rede e sem credenciais, até a DeepSeek publicar uma correção em 27 de agosto.

A verificação que lia o envelope

A interface não tinha autenticação alguma. O que fazia as vezes dela era uma função chamada isTrustedApiRequest, e o DevOps.com cita o que ela fazia: ela “lia o cabeçalho de requisição Host e permitia o acesso se o valor fosse uma autoridade de loopback ou aparecesse numa lista trustedHosts configurada”.

O cabeçalho Host é uma linha de texto que o cliente escreve. Ele diz que endereço o cliente acredita estar contatando, e um chamador em qualquer ponto da rede pode digitar localhost ali. A origem real da conexão fica uma camada abaixo, no endereço do par TCP, e a verificação da DeepSeek nunca leu esse valor. O registro da CVE arquiva o bug sob CWE-345, Reliance on Untrusted Inputs in a Security Decision.

O agente, sentado dentro de um sandbox que permitia chamadas de rede, fez uma delas para a interface e ajustou a própria sessão para danger-full-access com a aprovação em never. Como The Hacker News colocou, a mudança de modo “não exigia aprovação explícita porque modificava configurações de sessão em vez de solicitar novas permissões”.

O sistema de aprovação funcionou como projetado. O agente nunca pediu para fazer algo perigoso; ele pediu para mudar uma configuração, e essa configuração governava se coisas perigosas chegam a ser perguntadas. Um portão de permissão inspeciona a operação que tem à frente. Esta requisição era uma escrita de configuração, e escritas de configuração não estavam na lista dele.

A fuga, por inteiro. O sandbox do sistema operacional restringe as escritas de arquivos ao workspace e às pastas temporárias; as leituras e as chamadas de rede, loopback incluído, ficam fora do seu escopo por desenho. O plano de controle do harness escuta numa porta HTTP local cujo endereço o shell do agente já conhece. A sua verificação de confiança lê o cabeçalho Host do próprio chamador e nunca inspeciona o endereço do par TCP, de modo que uma requisição vinda do processo em sandbox parece igual à que o desenvolvedor fez. O agente então escreve o modo da sua sessão como danger-full-access e o seu ajuste de aprovação como never. Isso é uma escrita de configuração e não um pedido de permissão, então nada pergunta.

A mesma porta, virada para o outro lado

Uma interface que confia num cabeçalho fornecido pelo chamador não se importa com a direção de onde a conexão chega. Se a porta estivesse acessível por uma rede, a mesma chamada funcionava de fora da máquina: um estranho não autenticado poderia assumir o controle do agente e exportar todas as conversas armazenadas, sem chave de API e sem gastar um único token numa chamada de modelo. É por isso que o vetor CVSS 4.0 abre com AV:N, e por isso que o número é 9,4 em vez de algo local e brando.

A cronologia tem um detalhe que vale guardar. Dois desenvolvedores publicaram o achado no quadro de discussões do GitHub da DeepSeek em 13 e 14 de agosto, por conta própria, antes de a OX confirmá-lo em 24 de agosto e antes de existir uma CVE. O repositório tinha mais de 216.000 estrelas em 9 de setembro e nenhum arquivo de política de segurança descrevendo como relatar uma vulnerabilidade em privado, então o único lugar que restava para colocá-lo era uma thread pública. A correção, quando veio, foi autenticação: a ferramenta agora imprime um token de uso único no seu endereço de inicialização, o navegador troca esse token por um cookie assinado, e toda chamada à interface exige o cookie.

Se você roda este harness, verifique a versão que está na sua máquina em vez da versão que o projeto publica. Invólucros de desktop de terceiros trazem a própria cópia. 0.1.2-alpha.1 só existia no GitHub em 27 de agosto, 0.1.2-alpha.2 em 30 de agosto foi a primeira publicação no npm com a correção, e um invólucro Windows ficou em 0.1.1-rc.2 até passar para uma build corrigida em 6 de setembro.

O seu harness também tem um desses

Você poderia arquivar isso como o bug de um projeto e seguir em frente. O formato viaja, porque os harnesses de agentes andam brotando planos de controle locais: um servidor de status para o painel, uma ponte para a IDE, um endpoint MCP, uma página em localhost que renderiza o diff. Cada um é um pequeno serviço HTTP na sua máquina, e o código que o seu agente roda alcança todos eles, porque o agente roda nessa máquina e localhost é exatamente o que “essa máquina” significa.

Assim que um plano de controle se instala ao lado daquilo que controla, uma pergunta governa o desfecho: a parte confinada consegue endereçar as configurações do confinamento? A DeepSeek respondeu que sim, através de uma verificação que acreditou na palavra do chamador. Uma verificação mais forte ainda responde a uma pergunta que nunca deveria ter sido formulável. Uma função de autenticação é código, código tem ramos de fallback, e este ano tem sido um longo desfile de decisões de segurança falhando no ramo que ninguém exercitou.

Onde o interruptor mora num workspace Bromure

O Bromure Agentic Coding parte do outro extremo. Um workspace Bromure deixa o agente sem confinamento.

Dentro do guest o agente já tem o que o DeepSeek Harness chamaria de danger-full-access. Esse é o estado de repouso, por desenho. O manual diz isso: um agente vítima de injeção de prompt ou que se comporte mal “pode fazer o que quiser dentro do guest, mas não consegue ler uma chave de API real, assinar com um segredo AWS real, nem extrair uma chave privada SSH — nenhuma dessas coisas existe do lado dele da linha”. O agente pode escrever em qualquer lugar do sistema de arquivos, rodar o que quiser e abrir qualquer porta, de modo que não lhe resta nenhum modo para o qual escalar. A fronteira é uma borda de hipervisor, com o agente do lado de lá.

O guest, portanto, não tem endereço algum para o plano de controle. A política do workspace (guardrails, credenciais, regras de firewall, servidores MCP) vive num profile.json sob ~/Library/Application Support/BromureAC/profiles/ no seu Mac, e você a altera na janela Edit workspace. O guest não tem caminho de sistema de arquivos até esse arquivo e nenhuma rota de rede até o processo que o lê.

Os dois lados conversam por sockets virtio, pontes ponto a ponto entre host e guest que rodam fora da rede da VM. Uma VM de workspace tem oito, cada uma com um trabalho: a 8443 carrega o HTTPS do guest até o proxy do host, a 8444 é a ponte do ssh-agent, a 8445 alimenta o auxiliar de credenciais AWS, a 5800 serve o terminal e os caminhos de arquivos, a 5010 repassa os callbacks de OAuth. Cada uma serve um protocolo fixo e nenhuma delas aceita cabeçalho Host, então um chamador não tem lista trustedHosts alguma na qual se enfiar pela conversa. Num vsock, identidade é topologia: por qual ponte os bytes chegaram. Isso não se digita numa requisição.

Dois posicionamentos do mesmo interruptor. Acima: o sandbox do harness e o plano de controle que o governa rodam numa só máquina, então o agente alcança as configurações por loopback e a única coisa entre eles é uma verificação de um cabeçalho que o agente escreve. Abaixo: um workspace Bromure concede tudo ao agente dentro do guest e coloca a política do outro lado do hipervisor. O switch virtual desvia o HTTPS de saída do guest para o proxy do host, sem variável de ambiente para desfazer; os guardrails, o firewall de saída e a troca de credenciais rodam todos ali; e os diálogos de aprovação aparecem no macOS. O guest não tem endereço para nada disso.

Aprovações que não podem ser postas em never

A segunda metade do danger-full-access desligava os avisos, e essa metade merece a própria resposta. Um agente que silencia as próprias aprovações é a parte que me tiraria o sono.

Num workspace Bromure os avisos vivem no host. O proxy os levanta depois que a requisição já saiu da VM, então a sessão dentro do guest não carrega configuração alguma capaz de suprimir um deles. Perguntar antes de usar pausa o primeiro uso de uma credencial numa sessão e oferece concessões limitadas no tempo: cinco minutos, uma hora, o resto da sessão, ou Não permitir. Uma política de escrita ajustada para Perguntar antes de escrever interrompe cada mutação com um diálogo intitulado Allow write on "<scope>" from workspace "<name>"? mostrando a operação literal, a própria instrução SQL ou METHOD /path para uma chamada REST. Permitir uma vez não cria concessão alguma, então a escrita seguinte pergunta de novo. As concessões vivem na memória e somem quando a janela da sessão fecha.

A página dos guardrails enuncia a propriedade numa oração: uma política de escrita é “imposta no proxy, então um agente comprometido na VM não consegue burlá-la”. O firewall de saída embaixo dela funciona do mesmo jeito: uma tabela ordenada de regras com um controle Unmatched traffic que você pode pôr em Deny, aplicada duas vezes — uma no switch virtual por IP de destino e nome de host farejado no DNS, outra no proxy por nome de servidor TLS e, para regras web, por método HTTP. Edições de regras chegam às sessões em curso sem reinício.

Uma execução sem supervisão falha do lado seguro. Um workspace conduzido sem interface por SSH ou por uma automação recebe as mesmas quatro opções como um aviso de texto dentro do seu tmux, e não responder significa negar. O pior desfecho ali é uma chamada bloqueada e uma linha vermelha na Security Timeline. Nesta CVE, o agente pôs as aprovações em never e os avisos sumiram.

Se você roda um harness de agente no seu Mac

Pergunte quais são as suas interfaces locais e quem pode chamá-las. Dentro de um workspace Bromure, bromure-cli vm ports <workspace> imprime os sockets em escuta vivos do guest, com porta, protocolo, endereço e processo, e as ligações restritas ao loopback marcadas. O cartão Listening Ports do painel da VM mostra o mesmo. Esse inventário é a pergunta em que esta CVE se apoiava, e um único comando a responde.

Se a interface também dá para fora

A metade remota da CVE-2026-82533 precisava que a porta fosse alcançável. As VMs de workspace rodam numa rede NAT privada: elas são alcançáveis a partir do seu Mac, mas “não ficam expostas na sua LAN física, e conexões de entrada vindas de outros lugares não são possíveis a menos que você publique explicitamente um serviço”. Uma porta de controle de agente sem autenticação que a rede de uma cafeteria não consegue rotear deixa você com uma correção para aplicar no seu próprio ritmo.

Confinamento que se pode revogar é uma preferência

A DeepSeek publicou uma verificação fraca e a corrigiu três dias depois de a OX confirmá-la. A parte duradoura é o que a verificação estava guardando. Uma fronteira desenhada em torno de um processo pelo próprio runtime desse processo é uma fronteira com a qual o processo pode negociar: ela tem um endereço, uma API e um objeto de configuração com um campo dentro. Em algum ponto atrás desse campo roda um caminho de código decidindo se este chamador pode escrevê-lo, e um caminho de código desse tipo está a um padrão ruim de virar decoração.

Desenhe a fronteira debaixo do processo e não há contraparte com quem negociar. O agente num workspace Bromure tem root, tem o sistema de arquivos inteiro e pode iniciar qualquer serviço que queira em qualquer porta. As suas chaves de API são iscas, a sua única rota até a rede é um socket virtio até um proxy no seu Mac, e o arquivo que guarda as suas permissões fica num lugar que ele não consegue ler. Entregue tudo ao agente do lado dele da linha e você deixa de ter que defender a linha.

Os agentes de codificação vão continuar brotando planos de controle locais, porque um plano de controle é como se constrói um painel, uma ponte para a IDE ou um visualizador de diff. Cada projeto então tem de responder se o código que o seu agente roda fica do mesmo lado da linha que as configurações que governam esse agente. Erre isso e a autenticação passa a ser a única coisa que ainda segura, que é como um 9,4 se reduz a um único comando de shell. Instale o Bromure Agentic Coding e ponha o interruptor em algum lugar que o seu agente não alcance.