4
thiagoluismoraes
1 min de leitura ·

Pitch: Leash — sandbox open source que mostra exatamente o que seu agente de IA está enviando pela rede

Devido ao último incidente que ocorreu com o Grok CLI, escrevi uma sandbox pra saber de verdade o que roda e o que acontece na minha rede quando um agente de IA tá com controle do terminal.

O que tem de especial:

  • descriptografa cada request HTTPS via mitmproxy e aplica uma allowlist de domínios — qualquer coisa fora da lista é bloqueada e logada
  • monitora syscalls com Falco (eBPF) — pega leitura de credencial, tentativa de escape, bypass de rede
  • tem um dashboard web pra ver tudo em tempo real e gerenciar a allowlist sem editar YAML na mão

Construí em torno do meu cenário: meu host é macOS ARM, então uso uma VM Lima pra isolar de verdade — os agentes (Claude Code, Codex, Gemini, Grok) rodam lá dentro sem acesso direto à internet, só através do proxy.

Se alguém quiser testar, apontar problemas, sugestões, contribuir, sejam muito bem vindos!

MIT license, código aberto.

github.com/thiagolmoraes/leash

Carregando publicação patrocinada...
1

Meus 2 cents,

Parabens pela iniciativa !

Tambem tenho procurado formas de vigiar o trafego que os agentes tem gerado.

No meu caso tenho usado o OmniRoute, mas teu metodo tambem eh bem interessante.

Repositorio devidamente starreado e forkeado - obrigado por compartilhar !

Saude e Sucesso !

Este post foi favoritado via extensão TABNEWS FAVORITOS

Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS

1

Gostei bastante da combinação de proxy com allowlist e monitoramento de syscall. Acho que o ponto mais forte é transformar comportamento invisível do agente em algo auditável.

Uma pergunta: como você está pensando em tratar tráfego que não passa bem pelo fluxo HTTPS comum, como ferramentas que usam gRPC, websockets ou algum cliente com certificate pinning?

Imagino que nesses casos a parte de bloqueio por padrão continue sendo útil, mesmo quando não dá para descriptografar tudo. Mas talvez valha separar no dashboard o que foi “inspecionado” do que foi apenas “bloqueado por política”, para não passar uma sensação maior de visibilidade do que realmente existe.

1

Não cheguei a pensar nesse cenário de outros protocolos como gRPC por exemplo, se tiver o cenário exato do uso, a gente pode pensar em algo, fique a vontade para contribuir :D

1

Faz sentido. Um cenário que eu imagino é um agente rodando ferramenta de desenvolvimento que conversa com serviços locais ou remotos usando gRPC ou websocket, por exemplo um language server, um serviço interno de busca ou algum runtime que mantém conexão aberta.

Nesse caso, talvez o objetivo não precise ser descriptografar tudo. Só separar bem três estados já ajudaria bastante:

  • tráfego inspecionado;
  • tráfego permitido mas não inspecionado;
  • tráfego bloqueado por política.

Assim o usuário não confunde “não vi nada suspeito” com “eu realmente consegui observar tudo”.