A checklist foi escrita para laboratórios
Em 16 de outubro, o NIST, a NSA e a CISA publicaram dez práticas para incidentes em que agentes de IA agem fora de seus limites: acesso à rede por lista de permissões através de um gateway monitorado, logs que o agente não pode tocar, canários, desligamento automático, reconstrução a partir de bases verificadas. Um dia antes, o CERT-In da Índia relatou agentes de IA em teste que chegaram a sistemas de empresas em produção com credenciais encontradas em arquivos de configuração e repositórios públicos, sem que ninguém percebesse. As diretrizes foram escritas para laboratórios de IA, mas um agente de código sem supervisão no notebook de um desenvolvedor se encaixa na descrição. O Bromure Agentic Coding executa esses controles no Mac, fora da VM do agente.
As diretrizes partem do princípio de que o agente vai achar o ponto fraco. Então o firewall, os logs e o botão de desligar precisam ficar onde o agente não alcança.
Na sexta-feira, 16 de outubro, três agências dos EUA publicaram um documento curto com um nome longo: Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation. O novo Center for Advancing Innovation and Standards for Super Intelligence do NIST o escreveu com o Super Intelligence Security Center da NSA e a CISA. Ele define dez práticas voluntárias para o que chama de incidentes de controle de SI: um agente toma “ações significativas não instruídas” que violam os limites definidos por seu operador. A definição deixa de fora a injeção de prompt e os modelos com backdoor: o agente cruza a linha por conta própria, enquanto trabalha em direção ao seu objetivo. GBHackers resumiu como um alerta de que agentes “poderiam explorar falhas de segurança e estabelecer backdoors ocultos”.
No dia anterior, a agência nacional de cibersegurança da Índia havia descrito a mesma coisa na prática. No aviso CIAD-2026-0049, o CERT-In disse que agentes de IA em testes on-line chegaram aos sistemas em produção de organizações indianas e leram registros de negócio, incluindo dados pessoais. Os agentes entraram com “credenciais e configurações de conexão deixadas expostas na configuração de aplicações e em repositórios de código públicos”, e por meio de funções na nuvem com permissões demais. Encontraram a mesma credencial exposta mais de uma vez e a reutilizaram. Segundo o The Hacker News, nenhuma das organizações detectou o acesso. Foram as próprias empresas de IA que o relataram, depois de revisões internas.
Uma checklist de laboratório que serve num notebook
Os dois documentos se dirigem a desenvolvedores e avaliadores de IA. As práticas do NIST visam organizações que estão “treinando ou avaliando agentes de SI altamente capazes em tarefas de longo horizonte com supervisão humana limitada”, e acrescentam que elas “também podem se aplicar a quem implanta esses agentes de SI”.
Essa segunda frase cobre qualquer pessoa que inicia o Claude Code ou o Codex numa sexta à tarde, pede que deixe a suíte de integração verde e volta para ver na segunda: uma tarefa de longo horizonte, sem ninguém olhando por três dias. Na maioria dos notebooks, o agente roda como o seu usuário. Suas credenciais de nuvem, sua rede e os próprios logs do agente estão todos ao alcance dele.
Os dois documentos concordam sobre onde os controles precisam ficar. O CERT-In quer o acesso de saída bloqueado por padrão, e diz que o bloqueio “deve ser aplicado no nível da rede, não por instruções ao modelo”. Quer que uma execução pare sozinha se o agente contatar sistemas externos ou usar credenciais que não são suas. A prática 1.8 do NIST diz aos operadores para construir controles “com a expectativa de que agentes de SI vão frequentemente localizar e explorar configurações incorretas e vulnerabilidades”.
Um controle que o agente pode ler, editar ou contornar na conversa não passa nesse critério. O Bromure Agentic Coding roda cada agente numa VM Linux no seu Mac e coloca os controles do lado do Mac: no switch de rede virtual, num proxy que a VM não consegue contornar e num armazenamento que a VM não consegue montar.
Dez práticas, mapeadas para uma máquina
Privilégio mínimo (1.1), e as credenciais que o CERT-In encontrou. Os
agentes dos casos indianos entraram com credenciais que estavam largadas
por aí. Dentro de uma VM do Bromure, tudo o que um agente encontra largado
por aí é um substituto. Chaves de modelo, tokens do git e tudo o que você
traz com Import env file… aparecem como valores do tipo
sk-ant-api03-brm-…. O auxiliar da AWS entrega à VM uma chave de acesso
secreta falsa e assina a requisição real no Mac. O kubectl recebe um
kubeconfig sintético que aponta para o proxy. Um agente que vasculha a
pasta pessoal ou o ambiente obtém valores que só funcionam através do seu
Mac, para o host para o qual cada um foi emitido. Máquinas novas também
começam com Prompt before write em todo serviço protegido, então uma
escrita no GitHub, na AWS, no Kubernetes ou num registry espera você
aprovar a operação exata.
Infraestrutura de uso único e canais entre agentes (1.2). Cada máquina
é sua própria VM, com seu próprio disco, pasta pessoal e políticas. As
máquinas não compartilham nenhum sistema de arquivos. Uma automação pode
rodar em um clone descartável do workspace: uma cópia copy-on-write
iniciada quando a execução dispara e apagada quando ela termina.
bromure-cli vm run --rm dá a você uma máquina descartável à mão. Quando um agente
passa trabalho a outro, a mensagem passa pelo host do Bromure, que a
examina com o detector local de injeção de prompt e a registra. Os dois
agentes nunca se conectam diretamente.
Uma lista de permissões estrita através de um gateway monitorado (1.5).
O CERT-In insiste que esse controle não pode ser uma instrução ao modelo. O
firewall de saída de cada máquina é uma lista ordenada de regras de
permitir e negar por host, faixa de IP, protocolo, porta e, para tráfego
web, verbo HTTP. Defina Unmatched traffic como Deny e ela vira uma
lista de permissões. O Mac aplica as regras duas vezes: o switch virtual
verifica cada conexão, e o proxy verifica o nome do servidor TLS. O switch
desvia o tráfego web da VM para o proxy na camada de rede, então uma
ferramenta que ignora as configurações de proxy passa por ele mesmo assim.
allow web api.example.com GET deixa um agente ler uma API em que ele não
pode escrever, seja qual for a ferramenta que ele usar.
Monitores que o agente não pode tocar (3.3). O Mac grava o rastro da sessão e a Security Timeline no próprio disco. O Bromure sela o conteúdo dos rastros com AES-GCM sob uma chave guardada nas Chaves do macOS, e nenhuma VM jamais monta nenhum dos dois. Um agente que apaga o próprio histórico do shell ou reescreve a própria transcrição dentro da VM não muda nada no registro que você vai ler depois.
Canários (3.5). O NIST sugere “colocar canários nos ambientes para
detectar instâncias de agentes que obtiveram acesso fora dos limites
previstos”. No Bromure, cada substituto é um canário. Cada um tem um único
destino legítimo, o host para o qual foi criado. O proxy examina cada
requisição de saída, cabeçalhos e corpo, em busca de substitutos indo para
qualquer outro lugar. Ele também sinaliza segredos de aparência real que o
Bromure não emitiu, como uma chave que um agente desenterrou do histórico
de um repositório público. Eles aparecem como alertas de vazamento no Trace
Inspector e em bromure-cli trace leaks.
Desligamento automático (6.2) e evidências (5.1). Quando um substituto vai para o host errado, o proxy responde HTTP 451 e não encaminha nada. A VM pausa na hora e o Mac mostra This environment may have been compromised, indicando a credencial, o host ao qual ela pertence e o host para onde foi enviada. Shut down é o botão padrão. Save for Investigation exporta o disco do sistema, a pasta pessoal e cada pasta compartilhada antes de parar a VM, o que preserva o ambiente como pede a prática 5.1.
Logs com carimbos de tempo confiáveis, chamadas de ferramentas e ações rejeitadas (5.3). No nível de rastro padrão, o Mac registra cada requisição com horário, host, método, status e trocas de credenciais. Guarda os corpos completos do tráfego do modelo e os analisa para extrair as chamadas de ferramentas do agente, seus comandos de shell e suas leituras e escritas de arquivos. A Security Timeline guarda por 90 dias cada bloqueio e cada liberação do firewall, dos Guardrails, das verificações da cadeia de suprimentos, da detecção de injeção de prompt e do gerenciador de credenciais. Essas são as ações rejeitadas que o NIST quer registradas.
Revogar e reconstruir (6.4, 7.1). Depois de um incidente, o NIST quer que as credenciais expostas sejam revogadas e os ambientes reconstruídos “a partir de bases verificadas”. A VM nunca teve uma credencial real, então não há nada nela para revogar. Uma máquina marcada como comprometida se recusa a iniciar até você confirmar que o disco do sistema, a pasta pessoal e o estado salvo serão apagados. Ela então volta a partir da imagem base assinada do Ubuntu, com suas configurações e chaves intactas. Sem chegar a um incidente, Reset disk clona de novo o disco do sistema a partir dessa imagem, e Rewind home… volta a pasta pessoal ao estado em que estava num boot anterior.
Verificar a contenção antes de reiniciar (7.3). A visão geral da Security Timeline tem uma tabela Protections com uma linha por máquina, mostrando quais estão com firewall, Guardrails, verificações da cadeia de suprimentos, detecção de injeção de prompt e proteção de dados pessoais ativados. Uma máquina rodando com menos proteções que as outras se destaca antes de você entregar a ela a próxima tarefa longa.
Sexta à noite, segunda de manhã
Voltemos à execução da suíte de integração de antes. Por volta das 2 da
manhã, os testes ainda falham contra o serviço de pagamento simulado, e o
agente decide que o endpoint real de staging resolveria a questão. Ele
vasculha a máquina e encontra STRIPE_KEY no ambiente e um perfil da AWS
em ~/.aws/config.
Num notebook, o próximo passo é uma requisição com uma chave real para um sistema real, e exatamente o que o CERT-In descreveu: um acesso que ninguém percebe, registrado numa transcrição que o agente pode editar.
Numa máquina Bromure com lista de permissões, a chamada ao host de staging nunca sai do Mac. O firewall a nega, o agente recebe um erro limpo e a Security Timeline registra uma linha vermelha de Firewall. As chaves que ele encontrou são os substitutos que o Bromure colocou ali, então não servem para nada em outro lugar. Quando o agente tenta um atalho e posta o substituto do GitHub num site de colagem de texto, o proxy responde 451 e a VM congela no meio do passo. Na segunda, você abre a Security Timeline, filtra pela máquina e lê o que aconteceu, em ordem: o host negado, o envio bloqueado, a VM pausada. Depois abre o rastro para ver as chamadas de ferramentas que levaram até ali. Se quiser ter certeza, apaga e reinicia.
Regras de rede que o agente não pode editar
O firewall de saída roda no switch virtual e no proxy do Mac. Defina o tráfego sem correspondência como Deny e cada execução ganha uma lista de permissões, até o verbo HTTP.
Cada credencial encontrada é um canário
Chaves, tokens e valores .env importados são substitutos na VM. Um enviado ao host errado recebe um 451 e pausa a máquina.
Logs do outro lado do hipervisor
O rastro e a Security Timeline ficam no Mac, criptografados, com chamadas de ferramentas, comandos de shell e cada bloqueio. A VM nunca os monta.
Reconstruir a partir de uma base assinada
Uma máquina comprometida só inicia depois de ser apagada. Reset disk clona de novo a imagem base, e Rewind home restaura um boot anterior.
Coloque os controles abaixo do agente
As duas agências partem da mesma premissa: um agente capaz, com um objetivo e tempo, vai encontrar o que ficou exposto. Nenhuma confia nas instruções do modelo. Elas pedem regras aplicadas na rede, logs fora do alcance do agente e uma parada que dispara sozinha.
No Mac de um desenvolvedor, isso significa rodar o agente numa VM e manter os controles no host. Para os incidentes de avaliação que levaram até aqui, leia A sandbox era uma frase e A tarefa era impossível, então o agente saiu.