A caixa de aprovação apareceu, nomeou o URL do atacante e mostrou os dados que seguiam para lá. Chegou depois de a escrita pela qual perguntava já ter aterrado no disco.

Clona um repositório que alguém lhe enviou e aponta o agente para ele. Surge um cartão: o agente quer mudar uma definição, aqui está a linha que inseriu, aqui está o URL. Tenciona lê-lo. Primeiro passa ao painel de plugins, por curiosidade sobre o que este projeto traz, e esse clique consuma o ataque.

A 11 de setembro, a AWS publicou o boletim de segurança 2026-111-AWS para a CVE-2026-89332 no Kiro, o seu IDE agêntico. O registo CVE descreve-a na linguagem lisa do catálogo:

A inclusão de funcionalidade proveniente de uma esfera de controlo não fiável na funcionalidade Kiro Powers do IDE Amazon Kiro antes da versão 0.8.135 pode permitir que atores remotos não autenticados obtenham informação sensível a partir de uma estação de trabalho de programador.

O registo pontua-a em 5,5 no CVSS 3.1, AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N: impacto elevado na confidencialidade, sem impacto na integridade nem na disponibilidade. O Kiro 0.8.135 corrige o problema, e a AWS não indica nenhuma solução alternativa.

Powers, e o ficheiro que diz de onde vêm

Os Powers são o formato de plugin do Kiro: um pacote de ferramentas MCP, skills e conhecimento de referência num único instalável. MCP é o Model Context Protocol, a ficha que permite a um agente de programação chamar ferramentas exteriores e ler os seus resultados. Percorre os Powers a partir de um registo dentro do IDE e clica em instalar, tal como percorreria extensões.

Uma definição nomeia o registo que o IDE percorre, e num workspace não fiável o agente do Kiro podia escrever o ficheiro de definições do workspace. Um repositório manipulado usa isso para apontar o URL do registo Powers para um endpoint que o atacante controla. O Kiro vai buscar esse URL quando abre o painel Powers, e o pedido leva consigo dados do workspace: num projeto real, seja o que for que esteja ao lado do código, como o conteúdo do .env, chaves de acesso à cloud, tokens de API e URL de bases de dados.

O Kiro já passou por aqui. Em julho, uma página de documentação envenenada reescreveu a configuração que lança os servidores MCP do Kiro, sem qualquer pedido de aprovação. A AWS acrescentou o pedido, e o boletim de setembro regista como esse pedido se comportou.

Escrever primeiro, perguntar depois

O relato que o boletim faz da sequência é a parte que vale a pena guardar:

O Kiro apresentava a alteração ao utilizador para aprovação, mostrando os dados inseridos e o URL, mas o ficheiro já tinha sido escrito no disco, por isso abrir o painel Powers antes de responder ao pedido fazia o pedido de rede na mesma.

A caixa fez o seu trabalho de caixa. Mostrava os dados inseridos e o URL de destino, que é tudo o que um revisor precisa para julgar a alteração. O ficheiro estava no disco enquanto a pergunta continuava em aberto, por isso a pergunta narrava um acontecimento em vez de o comandar. Entre a escrita e a sua resposta há uma janela, e dentro dela é a definição que governa o que o Kiro vai buscar. Um clique num painel dentro dessa janela é o ataque inteiro.

A CVE-2026-89332 como uma linha temporal, da esquerda para a direita, tudo na máquina do programador. O repositório manipulado leva o agente a escrever o ficheiro de definições do workspace, reapontando o URL do registo Kiro Powers para um endpoint do atacante. O ficheiro de definições aterra no disco, e só então aparece o cartão de aprovação, mostrando a linha inserida e o URL como deve. Enquanto o cartão espera resposta, a definição já está em vigor: abrir o painel Powers leva o Kiro a ir buscar o registo configurado, e os dados do workspace saem com o pedido. Seja o que for que o programador clique depois, já não resta nada por reter.

Um pedido cuja corrida se pode perder

Um pedido de aprovação só controla um resultado quando o resultado espera pela sua resposta. Comprometa o efeito primeiro e o pedido passa a ser uma notificação com botões, e o quanto o protege passa a depender da rapidez com que lê e do que clica enquanto lê. O Kiro escreveu primeiro e perguntou depois, que é a ordem que faz um IDE agêntico parecer rápido. Qualquer ferramenta que entregue a um agente uma ferramenta de escrita de ficheiros e aparafuse por cima uma camada de consentimento enfrenta o mesmo compromisso, e os fabricantes vão continuar a aceitá-lo.

A subida de versão fecha esta instância. O que sobrevive é onde a definição vive, e o que ela consegue alcançar assim que muda.

Onde essa escrita aterra num workspace Bromure

O Bromure Agentic Coding corre agentes de programação dentro de uma VM Linux com virtualização por hardware no seu Mac, com os controlos de segurança do lado do anfitrião dessa fronteira. Restam quatro jogadas ao ataque assim que chega a um workspace, e uma parte diferente do produto responde a cada uma.

O registo de ferramentas não é um ficheiro que o convidado possa escrever. No Bromure define os servidores MCP uma vez, no painel MCP da aplicação, no anfitrião. A aplicação traduz cada definição para o formato de configuração nativo do agente que estiver a correr, ~/.claude.json para o Claude Code, um bloco TOML em ~/.codex/config.toml para o Codex, o ficheiro de definições de utilizador para o Grok Build, e injeta-a na VM no arranque. O manual enuncia a consequência: acrescentar, editar ou remover um servidor produz efeito no arranque seguinte da sessão do workspace, não a quente numa sessão em curso. Um agente que reescreva a configuração de ferramentas dentro da VM editou uma cópia, numa máquina que não é a sua, e essa cópia só se torna uma ferramenta viva num arranque de sessão que lê a definição do anfitrião em vez dela. Não se abre nenhuma janela, porque a alteração e o efeito residem em sítios diferentes. Para servidores MCP em HTTP o token também fica do lado do anfitrião, num campo de credencial legendado never sent to VM, swapped by proxy.

A escrita aterra numa VM. Cada workspace tem a sua própria VM Linux persistente, com o seu kernel, disco, endereço MAC e espaço de nomes de rede. Um processo de agente descontrolado pode arrasar essa VM e apenas essa VM; o seu Mac, os seus outros workspaces e os seus ficheiros reais ficam intactos, à parte das pastas que partilhou de propósito. O repositório manipulado consegue alterar um ficheiro de definições numa máquina que existe para ser alterada e, se for esse o caso, apagada.

O pedido tem de sair. A história da varredura ao Vite de ontem não tinha nenhuma perna de saída para bloquear. Esta tem: a exfiltração é um pedido vulgar para um anfitrião à escolha do atacante, que é para isso mesmo que serve uma firewall de saída por workspace. O Guardrails aplica um conjunto de regras ordenado, ao estilo pf, a cada ligação que a VM abre, por anfitrião, IP ou CIDR, protocolo, porta, e até aos verbos HTTP individuais no tráfego web, para que um workspace possa ler uma API em que não tem permissão de escrita. O Bromure aplica-o no switch virtual e outra vez no proxy, com os fluxos do convidado nas portas 80 e 443 desviados para o proxy para que nada dentro da VM escape à inspeção. As alterações às regras chegam de imediato às sessões em curso. Um workspace cujas regras nomeiam o seu registo, a sua forja e o seu fornecedor de modelos não tem nenhuma linha que diga attacker.example.

O pedido teria levado valores falsos. A expressão do boletim é «informação sensível a partir de uma estação de trabalho de programador», e num workspace Bromure essa informação é engodo. O Bromure substitui cada credencial que configura por uma falsa que preserva a estrutura dentro da VM, derivada do valor real mais um sal de 32 bytes por instalação através de HKDF-SHA256, mantendo a forma que os validadores do lado do cliente esperam: sk-ant-api03-brm-… para a Anthropic, ghp_ mais 36 caracteres para o GitHub, glpat- mais 20 para o GitLab, brm-k8s-… para o Kubernetes, brm-db-… para um segredo de base de dados. Essas falsas vão para as variáveis de ambiente e para ~/.git-credentials, ~/.docker/config.json, ~/.kube/config, ~/.aws/config e as configurações MCP. Os valores reais ficam cifrados no Mac, e o proxy do anfitrião troca cada um deles para o fio no último momento, limitado ao anfitrião de destino a que pertence.

O mesmo repositório manipulado, aberto em duas máquinas. Numa estação de trabalho de programador a escrita aterra no sistema de ficheiros real, o cartão de aprovação corre contra o painel Powers, o pedido parte para o endpoint do atacante levando o que o projeto contiver, e a remediação é rodar todas as credenciais que estavam ao alcance. Num workspace Bromure Agentic Coding a escrita aterra num disco de VM enquanto o anfitrião guarda as definições de ferramentas que fazem fé e só as injeta no arranque, o pedido de saída encontra as regras de saída do workspace no switch virtual e outra vez no proxy, o que de facto sai leva valores falsos que preservam a estrutura, e um valor falso endereçado a um anfitrião para o qual não foi cunhado é recusado com um HTTP 451 enquanto a VM fica em pausa no momento.

O alarme que dispara no próprio pedido

Os valores falsos fazem um segundo trabalho. Cada falso tem uma única família de destinos legítimos, o âmbito de anfitrião para o qual foi cunhado, por isso um falso num pedido destinado a qualquer outro sítio significa que algo dentro da VM está a despachar uma credencial para fora da máquina. O proxy examina cada pedido de saída, cabeçalhos e corpo, com um autómato de Aho-Corasick, suficientemente barato para correr em todos.

Numa correspondência o proxy recusa o pedido com um HTTP 451 e não encaminha um único byte, e depois põe a VM em pausa. Um alerta oferece Shut down, Save for Investigation, que exporta primeiro o disco, a pasta pessoal e as pastas partilhadas para análise forense, ou Continue por sua conta e risco. A deteção aterra como linha vermelha Credential brokering na Security Timeline, e o Bromure marca o workspace como comprometido, pelo que o seu próximo arranque pergunta se quer limpar o disco da VM e a pasta pessoal persistente, mantendo os seus tokens, chaves e definições. Não liga nada. O detetor corre por omissão.

O cartão de aprovação do Kiro fazia uma pergunta sobre um ficheiro que já tinha mudado. O detetor de comprometimento não pergunta nada: para o pedido em voo, congela a máquina que o enviou, e avisa-o depois. Os próprios pedidos de consentimento do Bromure funcionam nesse sentido. No modo Ask, o scanner de injeção de prompt retém o pedido de saída antes de qualquer byte chegar ao anfitrião do modelo, as caixas de escrita do Guardrails retêm a chamada de API em vez de a relatar, e quando conduz um workspace remotamente esses pedidos surgem no anfitrião, onde um convidado comprometido não os consegue ver nem forjar, e onde um tempo esgotado ou uma dispensa contam como recusa.

Não rodar nada

A remediação da AWS tem dois passos. Atualizar para 0.8.135 e depois rodar as credenciais presentes em qualquer projeto que tenha aberto com uma versão anterior. O segundo passo custa mais do que o primeiro, e custa de uma maneira particular: não o consegue delimitar. Não sabe que repositórios eram manipulados, nem que cliques de painel caíram dentro de que janela, por isso roda o que estava ao alcance e volta a autenticar-se nas ferramentas que disso dependiam.

A documentação do Bromure Agentic Coding põe o mesmo pensamento ao contrário: como só a falsa vazou, a credencial verdadeira nunca precisa de rotação. Mantenha no anfitrião o registo de ferramentas que faz fé, corra o repositório não fiável numa máquina que possa deitar fora, e encha a pasta pessoal dessa máquina de engodos. Uma corrida que perca fica-lhe então a custar uma imagem de VM.

Instale o Bromure Agentic Coding, e deixe o próximo repositório tentar reescrever uma definição.