Agent Safehouse – ferramenta de sandboxing de agentes locais para macOS

 (agent-safehouse.dev)
16 pontos por GN⁺ 2026-03-09 | 1 comentários | Compartilhar no WhatsApp
  • Ferramenta que isola agentes locais de IA por meio do sandbox nativo do macOS, impedindo que alterem o sistema fora do ambiente permitido
  • Todos os agentes são executados em ambientes de sandbox independentes, sem acesso ao diretório home do usuário ou a outros projetos
  • Aplica um modelo de acesso deny-first, permitindo leitura e escrita apenas em diretórios explicitamente autorizados
  • A instalação é concluída com um único script Bash, podendo ser executada imediatamente sem build adicional nem dependências
  • Com o recurso de geração de perfis baseada em LLM, é possível automatizar a configuração de sandbox-exec com privilégio mínimo

Visão geral

  • Agent Safehouse é um sistema de sandboxing exclusivo para macOS que protege contra danos a arquivos do sistema por agentes de IA executados localmente
    • "Go full --yolo. We've got you." "Move fast, break nothing"
    • Bloqueia o risco de execução inesperada de comandos causado pela natureza probabilística dos LLMs
  • Todos os principais agentes funcionam perfeitamente dentro do sandbox, sem impactar o sistema externo
  • Adota um modelo de acesso deny-first, bloqueando todo acesso por padrão e permitindo apenas caminhos explicitamente autorizados
    • Exemplo: ~/my-project permite leitura/escrita, enquanto ~/.ssh, ~/.aws e ~/other-repos têm acesso negado

Instalação e execução

  • A instalação é concluída com um único download de script shell
    • Baixe o script com o comando curl, salve em ~/.local/bin/safehouse e conceda permissão de execução
  • Depois disso, execute o agente desejado com o comando safehouse
    • Exemplo: safehouse claude --dangerously-skip-permissions
  • Por padrão, o Safehouse concede permissão de leitura e escrita ao diretório de trabalho atual (git root) e permite acesso somente leitura ao diretório da toolchain

Exemplo de validação do sandbox

  • O acesso a arquivos sensíveis é bloqueado no nível do kernel
    • Ao executar safehouse cat ~/.ssh/id_ed25519, ocorre o erro "Operation not permitted"
    • Outros diretórios de projeto, como ~/other-project, não ficam visíveis
    • O diretório do projeto atual continua acessível normalmente

Automação e geração de perfis

  • Com a adição de funções de shell, todos os agentes podem ser executados dentro do Safehouse por padrão
    • Exemplo: defina a função safe() no .zshrc ou .bashrc para aplicar sandbox automaticamente aos comandos claude, codex, amp e gemini
    • Para executar sem sandbox, use a forma command claude
  • Oferece um recurso de geração de perfis baseada em LLM
    • Modelos como Claude, Codex e Gemini analisam os templates do Safehouse para gerar perfis sandbox-exec de privilégio mínimo
    • Os perfis são salvos em ~/.config/sandbox-exec.profile com base no diretório home e nas informações da toolchain
    • Incluem permissões de acesso ao diretório de trabalho atual e atalhos de comando por agente

Segurança e relevância prática

  • Protege para que agentes locais baseados em LLM não realizem exclusões acidentais de arquivos nem alterações no sistema
  • Usa controle de acesso em nível de kernel do macOS para oferecer um ambiente de execução seguro por padrão
  • Por ser baseado em um único script, pode ser facilmente integrado ao fluxo de trabalho de desenvolvedores

Leituras relacionadas

1 comentários

 
GN⁺ 2026-03-09
Comentários do Hacker News

  • Eu não esperava que o projeto que criei fosse divulgado tão rápido assim
    1️⃣ Eu prefiro agentes executados diretamente no ambiente local. Em vez de contêineres ou servidores remotos, fico mais tranquilo quando rodam na minha própria máquina, ajustada por mim nos mínimos detalhes
    2️⃣ Isso é, na prática, um gerador de políticas para sandbox-exec. Não tem dependências nem virtualização. Em vez disso, investi muito tempo em descobrir as permissões mínimas necessárias para cada agente fazer coisas como atualização automática, integração com o keychain e colagem de imagens. O levantamento relacionado está organizado em agent-safehouse.dev/docs/agent-investigations
    3️⃣ Nem é preciso usar o projeto inteiro. Só o Policy Builder já serve para gerar políticas do sandbox-exec e usá-las nos seus dotfiles

    • Desculpe por ter divulgado antes da hora. Testei depois de ver um comentário seu antigo, e a eficiência foi tão boa que achei que valia um post
      Eu já tinha visto documentação sobre políticas de sandbox antes, mas foi a primeira vez que vi isso em formato de app pronto para usar
      Ainda assim, houve alguns incômodos — o acesso a .gitconfig e .gitignore no diretório home é bloqueado, e por causa das restrições de acesso a processos não dá para mandar o Claude executar comandos como lldb ou pkill. Seria bom ter controle granular de permissões
    • Fiquei curioso se daria para aplicar isso ao openclaw. É prático rodar de um jeito acessível na máquina local, mas ao mesmo tempo isso traz o problema de ficar mais difícil de controlar
    • Queria entender qual é a diferença prática entre rodar localmente e rodar em contêiner
    • Ah, era exatamente isso que eu estava procurando. Eu estava tentando ajustar bem o microsandbox, mas isso aqui parece bem mais realista
      Dei uma olhada no site e nos scripts e não encontrei nenhum problema em especial. Existe algum ponto de atenção que não esteja documentado?
    • Ironicamente, me interessei por um projeto desses justamente porque não confio em IA, mas é meio engraçado que para instalar eu precise baixar e executar um arquivo .sh de um servidor qualquer
      Seria bom disponibilizar em formato tarball. Com tarball, dá para inspecionar o conteúdo manualmente e verificar também se foi gerado automaticamente no CI, então transmite mais confiança

  • Fico feliz de ver projetos assim, e acho que sandboxing é o maior desafio no momento
    Os primeiros usuários vão simplesmente sair rodando agentes no ambiente local sem pensar muito, mas isso jamais vai funcionar no longo prazo ou em ambientes corporativos
    Não basta controlar rede, arquivos e permissões de execução; também é preciso lidar com cenários complexos, como testes em navegador ou criação de recursos em nuvem
    No fim, é preciso uma abordagem prática que integre segurança, custo e controle de permissões

    • Mas será que isso não é um problema impossível de resolver na raiz? Funcionalidade e segurança sempre entram em choque, e no fim as pessoas escolhem a primeira
    • Sandboxing em nível de arquivo é o básico; a parte realmente difícil é controle de credenciais e de rede
      Eu uso um daemon local que emite JWTs de curta duração para o agente não lidar diretamente com as chaves. Funciona bem para acesso a APIs, mas ainda assim, no nível do sistema de arquivos, ele poderia subir infinitas instâncias EC2

  • O problema é que é difícil comparar e avaliar vários sandboxes
    Isso parece ser um wrapper para sandbox-exec, e hoje em dia estão surgindo muitos wrappers assim
    O que realmente faz falta são documentos de verificação de confiabilidade e testes automatizados. A maioria dos sandboxes tem documentação insuficiente
    Para confiar, é preciso documentação detalhada e provas de funcionamento

    • Foi por isso que implementei em Bash — para evitar binários opacos
      Os perfis de sandbox-exec para cada agente estão separados na pasta de perfis no GitHub, então são fáceis de revisar
      Também estou realizando testes E2E com agentes reais
      Mesmo sem o wrapper do Safehouse, dá para gerar diretamente políticas de privilégios mínimos com o Policy Builder
      Além disso, também forneço um arquivo de instruções para o LLM escrever perfis de sandbox

  • Isso é um script wrapper para sandbox-exec. É bom porque já vem com muitos presets bem montados
    90% do sandbox-exec é definir o escopo certo, e os outros 90% são entender isso
    Dito isso, seria ótimo poder fazer sandboxing com overlay ou copy-on-write. Para mim já bastaria modificar só um ambiente temporário, e não o meu .bashrc

    • Usei Bash porque é difícil confiar em binários em Go ou Rust
      Overlay FS é complicado no macOS, mas resolvi isso limitando o acesso de leitura fora do CWD e induzindo o trabalho em uma pasta temporária
    • Estou criando um OSS chamado Amika. É uma ferramenta para subir sandboxes locais e remotos rapidamente, com boa integração com Git
      Também permite expor portas TCP/UDP e compartilhar com colegas de equipe. Veja o link do GitHub
    • Eu criei um projeto chamado Treebeard. A estrutura combina sandbox-exec, worktree e sistema de arquivos COW
      Assim, é possível acessar com segurança arquivos ignorados pelo git. Link do Treebeard
    • Mas o sandbox-exec já não foi deprecated?

  • Fato interessante: o sandbox-exec está oficialmente em estado de deprecated desde o macOS Sierra (2016)
    Mesmo assim, continua sendo útil na prática. O App Sandbox da Apple não se encaixa nesse tipo de regra personalizada
    Espero que a Apple não o remova de vez

    • Na verdade, parece que ele já nasceu deprecated. Quase não existe documentação da linguagem de perfis, e a maior parte do que se sabe foi descoberta por engenharia reversa

  • Também existe um projeto chamado Sandvault. Ele combina sandbox-exec com um sistema de usuários Unix
    Dá a cada agente uma conta de usuário separada e sem privilégios, e a interação acontece via sudo, SSH e diretórios compartilhados
    Link do Sandvault no GitHub

  • Eu criei um app GUI para macOS que permite gerenciar o sandbox-exec visualmente
    Ele também inclui filtragem de rede por domínio e detecção de segredos
    multitui.com

  • Compartilho um método para executar o código do Claude dentro do contêiner da Apple usando o comando container da Apple
    O ambiente é montado na sequência container system start → container run → container exec, e então Node.js e Claude são instalados

    • Valeu! Foi a primeira vez que descobri que também existe apple/container no Homebrew

  • Queria entender por que você acha melhor rodar agentes localmente.
    Para a maioria das pessoas, execução remota parece mais eficiente — afinal, não precisa deixar tudo ligado o tempo todo

    • A vantagem da execução local é controle e propriedade. É parecido com o motivo de alguém rodar Plex ou um servidor web por conta própria
      Além disso, você evita mensalidades
    • Eu criei o pixels para resolver esse problema. Ele pode rodar sobre TrueNAS SCALE ou Incus
      Estou reforçando a segurança, e ele já é adequado o bastante para workflows de IA
      Link do pixels no GitHub

  • Fiquei curioso se “clunker” é uma nova gíria para “clanker”. Um Roku amigo de um amigo quer saber
    Estou apanhando com o problema de sandboxing agora, então o timing foi perfeito

    • Era só um erro de digitação, acabei de corrigir