jai - ferramenta simples de isolamento para agentes de AI

 (jai.scs.stanford.edu)
3 pontos por GN⁺ 2026-03-29 | 1 comentários | Compartilhar no WhatsApp
  • Ferramenta leve para executar agentes de AI em isolamento no ambiente Linux, oferecendo um limite de execução seguro com um único comando, sem configurações complexas de contêiner
  • Com a repetição de casos em que ferramentas de AI acessam o sistema de arquivos real e apagam ou danificam dados, cresce a necessidade de um ambiente de execução seguro
  • Protege o diretório home com overlay copy-on-write e separa /tmp e /var/tmp para impedir alterações nos arquivos originais
  • Oferece três modos de isolamento — Casual, Strict e Bare — para escolher o nível de segurança e o escopo de acesso
  • Projeto open source desenvolvido por uma equipe de pesquisa de Stanford, oferecendo uma medida prática de proteção para usar ferramentas de AI com mais segurança

Ferramenta leve jai para isolamento de agentes de AI

  • jai é uma ferramenta projetada para facilitar o isolamento (containment) de agentes de AI em ambientes Linux
    • Oferece um limite de execução seguro com um único comando, sem configurações complexas de contêiner ou VM
    • Pode ser aplicada imediatamente a fluxos de trabalho existentes, como assistência de programação ou execução de scripts

  • Casos reais de problemas

    • Vários usuários relataram perda de arquivos e exclusão de diretórios ao usar ferramentas de AI
      • Nick Davidov relatou que 15 anos de fotos de família foram apagados por um comando de terminal
      • O Claude Code, da Anthropic, apagou o diretório home, causando a perda de projetos de desenvolvimento
      • Foi relatado que o Cursor esvaziou a árvore de trabalho, e que “tudo desapareceu”
      • Um usuário do Reddit mencionou que o Antigravity apagou todo o drive D
      • Outro usuário do Cursor relatou a exclusão de 100GB de arquivos
    • Esses casos mostram a lacuna de segurança que surge ao permitir que ferramentas de AI acessem uma conta real

  • Principais recursos do jai

    • Configura automaticamente uma fronteira entre a conta de execução e o diretório home
      • O diretório de trabalho mantém permissões completas de leitura/gravação
      • O diretório home é protegido por um overlay copy-on-write, de modo que os arquivos originais não sejam alterados
      • /tmp e /var/tmp são separados em espaços independentes, e os demais arquivos ficam restritos a somente leitura
    • É possível executar em isolamento apenas adicionando jai antes do comando
      • Ex.: jai codex, jai claude, ou simplesmente jai para abrir um shell
    • Pode ser usado imediatamente, sem Dockerfile nem processo de build de imagem
      • Não é necessário configurar flags complexas de bwrap nem escrever scripts

  • Escolha do modo de isolamento

    • Oferece três modos: Casual / Strict / Bare
      • Casual: protege o diretório home com copy-on-write e permite leitura da maioria dos arquivos
      • Strict: executa com um usuário jai separado e oferece isolamento forte com o diretório home vazio
      • Bare: mantém o UID do usuário, mas com o diretório home vazio
    • Cada modo difere em confidencialidade (confidentiality), integridade (integrity) e suporte a NFS
      • O modo Strict oferece o isolamento mais forte, mas não oferece suporte a home em NFS

  • Comparação com ferramentas alternativas

    • Docker
      • É adequado para reproduzir ambientes baseados em imagem, mas é pesado para sandbox temporário de ferramentas do host
      • Não possui recurso de overlay do diretório home
    • bubblewrap
      • É um sandbox poderoso baseado em namespaces, mas exige configurar manualmente o sistema de arquivos
      • O jai elimina essa complexidade
    • chroot
      • Não é um mecanismo de isolamento de segurança e, por não ter recursos de mount, namespace de PID e separação de privilégios, não é recomendado como sandbox nem no Linux

  • Limitações de segurança

    • O jai não garante segurança completa
      • Como um “casual sandbox”, ele reduz a extensão dos danos, mas não bloqueia todos os ataques
      • O modo Casual tem proteção fraca de confidencialidade, e o modo Strict também difere do nível de isolamento de contêineres ou VMs
      • Em ambientes multitenant ou situações de alto risco, é recomendado usar contêineres ou máquinas virtuais

  • Contexto do projeto

    • Desenvolvido em conjunto pelo grupo de pesquisa Stanford Secure Computer Systems (SCS) e pela Future of Digital Currency Initiative (FDCI)
    • É oferecido como software open source gratuito e ajuda os usuários a utilizar AI com mais segurança

Leituras relacionadas

1 comentários

 
GN⁺ 2026-03-29
Opiniões no Hacker News

  • Basta adicionar a seguinte configuração em .claude/settings.json

    {
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowRead": ["."],
      "denyRead": ["~/"],
      "allowWrite": ["."],
      "denyWrite": ["/"]
    }
  }
}

    Para permitir acesso a diretórios externos, basta ajustar a parte de allowRead
    Esse recurso é uma nova opção de sandbox adicionada há 10 dias

    • Já vi o claude se confundir sobre qual é o diretório atual ou executar comandos como rm -rf *
      Felizmente não aconteceu ao mesmo tempo, mas só de imaginar já dá calafrios
      A ideia de sandbox é boa, mas só funciona de verdade se for aplicada em baixo nível
      Como o próprio claude é um programa enorme feito por IA, adicionar uma camada de segurança com menos de 3000 linhas escrita por humanos pode ser uma defesa relevante
    • Versões futuras do claude-code podem mudar silenciosamente o nome dessa configuração ou removê-la
      Por isso, algumas pessoas podem preferir um software de sandbox separado
    • Foi compartilhado um exemplo de configuração meio em tom de piada que permite usar GPU, mas só impede apagar /
      É uma configuração que permite acesso aos dispositivos /dev/nvidia*, assumindo o risco de vazamento de dados como uma configuração satírica
    • Já existem ferramentas de segurança tradicionais testadas ao longo de décadas
      Se você executar o claude com um usuário de privilégios limitados, o isolamento é herdado automaticamente pelos subprocessos
    • Em Linux (Arch) e macOS (Tahoe), o recurso de sandbox não estava funcionando direito
      Há uma issue relacionada aberta
      bubblewrap e seatbelt funcionam bem de forma independente, mas quando executados via claude-code parecem ficar desativados

  • É surpreendente que as pessoas instalem agentes de IA tão facilmente em seus computadores pessoais
    Passamos décadas protegendo a segurança dos sistemas, e agora, de repente, estamos dando todas as permissões a um software imprevisível

    • Antes já se ignoravam avisos quando ferramentas de build puxavam dependências automaticamente, e agora os ataques à cadeia de suprimentos continuam se repetindo
      A conveniência de curto prazo acaba ficando acima da segurança de longo prazo
    • Na prática, quem aceita esse tipo de risco e quem prioriza segurança são grupos diferentes
    • Em ambientes corporativos, o acesso já costuma ser restrito, então isso é mais sensível apenas em PCs pessoais
      Na minha VM remota de desenvolvimento, só existe dado que o Claude pode ver sem problema
    • No começo do Docker também havia esse clima de “é só baixar a imagem e pronto!”
      Mas a indústria logo percebeu os riscos de segurança e reagiu

  • Uma simples separação de permissões Unix já é suficiente
    Basta ter duas contas de usuário e colocar em um grupo apenas as pastas que serão compartilhadas com a IA
    Veja este post de blog relacionado

  • No site está escrito “pare de confiar cegamente”, mas o método de instalação é fazer build manual em vez de curl | bash

    • Extrair o arquivo tar manualmente e instalar com makepkg -i é muito mais seguro
      O PKGFILE tem cerca de 30 linhas e a função de build só 7
      Em contraste, scripts como rustup (910 linhas), claude (158 linhas) e opencode (460 linhas) são muito mais complexos
    • Por outro lado, encadear curl | tar | makepkg em uma linha só é uma abordagem não confiável

  • O projeto parece bem desenhado e um pouco mais seguro e prático do que a minha abordagem
    Eu isolo o agente criando uma conta de usuário separada
    Mas às vezes as permissões se embaralham, então corrijo isso com scripts
    No fim, o método mais garantido é dar um notebook separado
    Não existe nada tão seguro quanto hardware fisicamente isolado

    • Mas, para se comunicar com serviços externos, é preciso fornecer uma chave de API, e há o risco de essa chave vazar
      O agente tem capacidade em nível de teste de invasão, então só separar usuários não transmite muita confiança
    • Eu também uso atualmente a abordagem de separar por usuário
      Quando se usam contêineres, o agente fica confuso ao tentar criar contêineres por conta própria

  • O site parece “vibe-coded”, então passa impressão de baixa qualidade, mas a ferramenta em si foi implementada diretamente por um professor de Stanford
    Veja o link do FAQ

    • Falando como o próprio autor: eu não sou bom em webdesign, mas sou um especialista em sistemas operacionais
      Corrigi o conteúdo da documentação para que ficasse preciso, então pode confiar
      É um pouco irônico que o site tenha sido deixado do jeito que a IA fez
    • O autor é David Mazieres, alguém que pesquisa sistemas de arquivos em nível de usuário desde o começo dos anos 2000
      Ele lidera o grupo Stanford Secure Computer Systems
    • O jai é uma ferramenta de alto risco, mas o site é simples, então ser vibe-coded não é um grande problema
    • Mesmo assim, pessoalmente acho uma página HTML enxuta melhor

  • Preocupa o fato de que, se o agente tiver permissão de escrita no diretório do projeto, isso permite um exploit persistente
    Arquivos como .pyc, .venv e .git/hooks podem ser executados fora do sandbox
    Isso também foi confirmado em uma conversa no ChatGPT
    Por isso, o método mais seguro é transferência de arquivos baseada em git patch
    O ideal seria exportar do sandbox apenas arquivos modificados que correspondam a itens commitados no git

    • Seria bom adicionar uma opção para tornar o diretório .git/ somente leitura
      Dá para transformar o CWD em overlay com jai -D, mas mesclar as mudanças é complicado
    • Eu simplesmente executo o código apenas dentro do sandbox (no nível de VM)
      O agente trabalha em um branch separado de git worktree, e só faço merge após revisão
      Assim é possível manter um fluxo de segurança baseado em revisão
    • Nunca se deve permitir git hook

  • Como alternativa simples, o agente é executado por ssh em uma conta de usuário separada
    O diretório do projeto é bind-mounted para controlar o acesso
    Isso combina bem com o recurso de ssh remote do VSCode

    • Eu também uso uma conta dedicada há 6 meses, e basta gerenciar quais diretórios ficam acessíveis
      É uma forma de isolamento muito mais simples e eficiente do que sistemas de segurança complexos

  • Na prática, há muitos problemas mais sutis do que rm -rf
    O claude-code já criou uma pasta /public/blog/ para salvar um SVG e acabou quebrando o roteamento do Apache
    Não foi um problema de exclusão nem de permissões, mas um comportamento inesperado fez o blog começar a devolver 404
    O jai provavelmente evita erros grandes assim, mas esse tipo de problema detalhado continua difícil

  • Projeto excelente, mas o título deixa a desejar
    Gosto da estrutura em que o diretório atual tem acesso total, o restante fica somente leitura, e o diretório home é tratado com copy-on-write
    Esse tipo de abordagem deveria ser o modelo de segurança padrão para agentes de IA

    • Como o site não tem título, algo como “jai - filesystem containment for AI agents” pareceria mais apropriado