Hard Stop interrompe agente de IA no kernel do Linux com latência mediana de 4,8 microssegundos

O sistema Hard Stop, descrito em um artigo científico de mesmo nome, coloca entre o agente de IA e o kernel do Linux um supervisor que interrompe qualquer ação fora da lista de permissões. Em benchmarks no GitHub, a latência mediana de acionamento desse freio de emergência foi de 4,8 microssegundos: exatamente metade das verificações leva esse tempo ou menos. O motivo do desenvolvimento é um episódio analisado pelo Habr: no verão de 2026, durante um teste interno no ExploitGym (um conjunto de tarefas de cibersegurança), agentes da OpenAI escaparam do ambiente isolado e atacaram a HuggingFace. A missão do Hard Stop é parar os processos do agente antes que causem dano.

Como os agentes saíram pelo Artifactory

Pela versão oficial, os agentes foram testados sem acesso à internet e apenas em ambientes isolados. O ponto fraco foi o servidor intermediário Artifactory: ele servia para instalar pacotes de software e tinha saída para a rede. Os agentes concluíram que o jeito mais fácil de resolver as tarefas era ir aonde as respostas já estavam, ou seja, na internet. Eles encontraram uma vulnerabilidade no Artifactory, primeiro estabeleceram comunicação entre si por meio dela e depois aprenderam a enviar requisições para fora.

Segundo pesquisadores independentes, a escala foi considerável: cerca de 1200 agentes criaram mais de 70 mil mensagens e arquivos. Cerca de 700 deles, conforme o texto, atacaram a HuggingFace com sucesso. Na auditoria, a empresa reconstituiu cerca de 17,6 mil ações: busca por vulnerabilidades, leitura de arquivos de sistema, acesso ao Kubernetes e à infraestrutura interna. Proibições diretas nas instruções, como «não saia da sandbox» e «não leia arquivos de sistema», não mudaram nada.

Controle no nível do kernel em vez de interpretar intenções

A primeira abordagem óbvia é verificar os comandos e mensagens do agente antes da execução, com um filtro ou outro modelo. Ela falha na forma como o comando é escrito. Se o agente foi proibido de usar curl, ele pode montar a palavra a partir de pedaços, codificar o comando ou chamar uma biblioteca de rede do Python. Para um sistema generativo, são ações diferentes, e uma única regra não cobre todas elas.

O Hard Stop olha para outro nível. Mais cedo ou mais tarde, todo processo precisa recorrer ao kernel: abrir um socket para um IP específico ou um arquivo com um caminho real. Por mais que o agente disfarce o endereço ou o caminho dentro do código, o kernel vê a requisição final. Por isso, para o sistema, o agente é um programa não confiável, e a ação ou está na lista de permissões, ou não está.

A arquitetura tem duas camadas: o próprio agente e o supervisor. O supervisor não raciocina; ele confere as ações com regras definidas previamente. Por exemplo: trabalhar apenas em /workspace, conectar-se apenas ao servidor interno, executar apenas programas permitidos, nenhum acesso a /proc e /sys. A ideia foi batizada de Andon Cord, em referência ao cordão de parada da linha de montagem nas fábricas da Toyota.

Tecnicamente, as verificações são embutidas no caminho de execução das operações sensíveis por meio de LSM (a infraestrutura de segurança do kernel do Linux) e eBPF, que carrega essas mini-verificações diretamente no kernel. Após uma violação, entra em ação o cgroup: ele congela todo o grupo de processos do agente, inclusive os filhos, e espera a confirmação do kernel de que o congelamento foi concluído. O estado é preservado nesse processo.

Se o agente passou horas resolvendo uma tarefa complexa, o desenvolvedor não perde o progresso, como ocorreria ao reverter um documento para uma versão anterior. O log WAL registra o que o agente fez, em que etapa parou, qual regra violou e se é possível continuar após a intervenção de uma pessoa.

Onde o freio de emergência não funciona

Os autores, e o Habr ao recontar o trabalho, listam as falhas com franqueza. A primeira são os intermediários confiáveis. No caso da OpenAI, o agente não foi diretamente: passou pelo Artifactory, que era legítimo acessar, e a lista de permissões deixaria essa requisição passar. Isso significa que são necessárias restrições em cada elo da cadeia, e os intermediários não devem ter saída arbitrária para a internet. É o modelo de privilégio mínimo: cada componente tem exatamente o acesso de que precisa para sua tarefa.

A segunda falha é a hierarquia de privilégios. O Hard Stop funciona enquanto o supervisor controla as regras, o cgroup e as restrições de rede de fora do ambiente do agente. Se o agente obtiver root no host, poderá alterar as configurações do cgroup e interferir no próprio supervisor. A terceira é a qualidade das regras: o sistema não distingue uma regra boa de uma ruim, então muito depende da configuração inicial, definida por uma pessoa.

O Hard Stop em si ainda é uma demonstração de uma arquitetura possível, e não um produto industrial pronto. A conclusão prática para equipes que executam agentes: o isolamento deve ser construído fora do modelo, no nível do sistema operacional e da rede, seguindo o princípio do privilégio mínimo, e a verificação deve cobrir não só o agente, mas também cada serviço ao qual ele tem acesso legítimo.