Por que seu sandbox de microVM resolve muito bem um problema específico, mas não o problema de segurança de agentes

MicroVMs são excelentes para isolar máquinas inteiras, mas não servem para controlar o que um agente faz dentro delas. Quando você coloca um agente de código em uma microVM, ele herda suas credenciais, chaves SSH e tokens de acesso, tudo que ele precisa para funcionar. O problema não é ele escapar da máquina virtual, mas sim usar esses privilégios legítimos para apagar um banco de dados, enviar segredos para um servidor externo ou modificar arquivos críticos por causa de uma instrução mal interpretada. O hipervisor não vê essas ações: ele só garante que o sistema operacional convidado não quebre a barreira com o host. Mas o agente já está dentro da casa, com as chaves da porta da frente.

A verdadeira proteção para agentes vem de controle de permissões granulares: quem pode ler qual arquivo, qual domínio pode ser acessado, quais syscalls são permitidas. Ferramentas como nono.sh atuam nesse nível, interceptando chamadas de sistema antes que o agente as execute. Isso não é virtualização. É filtragem de ações. Sem isso, você tem uma caixa forte, mas deixou todos os segredos dentro dela, e o agente, por mais bem-intencionado que seja, pode ser convencido a entregar tudo.

Empresas que adotam agentes de código para automação de desenvolvimento estão subestimando o risco de falhas não maliciosas. O dano mais comum não vem de um invasor, mas de um agente que confia demais em um prompt, executa um comando errado ou lê um arquivo sensível por acidente. Se o agente tem acesso total ao seu ambiente, ele pode destruir o que você mais valoriza, sem precisar burlar nenhuma camada de segurança. A solução não é mais virtualização, mas sim limitar o raio de ação de cada processo. Isso muda o jogo: em vez de confiar na isolação de máquina, você passa a confiar em políticas que dizem exatamente o que cada agente pode e não pode fazer, mesmo dentro da própria conta do usuário.