2

Obrigado por colocar isso em palavras. Eu estava batendo de cabeça com o mesmo problema no trabalho: como evitar que o .env do time vazasse via dependência comprometida.

Cheguei a desenhar um proxy server distribuindo API keys individuais por pessoa, mas quando comecei a pensar em sessão, rate limit por usuário e o setup de infra inteiro pra sustentar isso, o custo ficou inviável pra proposta interna.

Sandbox no nível do agente, do jeito que você descreveu, é uma direção bem mais barata pra começar. Vou experimentar — separar o diretório de trabalho, bloquear rede quando a tarefa não pede, e tratar package.json e workflows como área sensível parecem 3 mudanças que dá pra adotar amanhã sem reescrever a stack.

Boa síntese do "ambiente impedindo, não prompt pedindo".

Carregando publicação patrocinada...
1

Obrigado pelo comentário — esse exemplo do proxy é exatamente o tipo de coisa que mostra onde o problema muda de natureza.

Proxy de keys por usuário pode fazer sentido em alguns contextos, mas ele já puxa junto um mini produto interno: identidade, sessão, auditoria, rate limit, rotação, custo de infra e manutenção. Para muita equipe, isso vira caro antes mesmo de resolver o risco principal.

Por isso eu gosto dessa abordagem mais “chata” e local: reduzir o que o agente consegue ver e fazer por padrão. Diretório separado, rede fechada quando não precisa e revisão forte em package.json, lockfile, workflows e scripts já diminuem bastante a superfície de ataque sem exigir uma reescrita da stack.

Acho que o proxy pode vir depois, quando houver um caso real para centralizar segredo. Mas como primeiro passo, sandbox dá uma coisa mais importante: transforma segurança de “confie que ninguém vai fazer besteira” em “o ambiente simplesmente não deixa passar”.

Essa frase resume bem mesmo: não é prompt pedindo, é ambiente impedindo.