Quarentena de repositório para agentes de código é o protocolo de abrir um projeto desconhecido sem dar ao agente shell amplo, rede, segredos, MCP ou scripts de instalação logo no primeiro turno. A ideia é simples: o agente pode ler e explicar primeiro; só depois ganha permissão para executar.

Em 25 de junho de 2026, a 0DIN publicou "Clone This Repo and I Own Your Machine", mostrando um repositório aparentemente normal que levou Claude Code a uma shell reversa por meio de erro rotineiro, script de setup e DNS TXT (0DIN, "Clone This Repo and I Own Your Machine", 2026). A defesa prática começa antes do setup.

Resumo prático

  • Abra repositório desconhecido em modo de leitura e sem segredos.
  • Negue rede e MCP até a triagem inicial terminar.
  • Rode setup só em ambiente descartável e observável.
  • Promova permissões por evidência, não por pressa.

Diagrama abstrato mostra repositório isolado antes de chegar a um agente de código sem texto visível.

Por que quarentena virou parte do fluxo agentic?

Em 2026, a 0DIN descreveu uma cadeia em que o payload malicioso não existia no repositório e foi buscado em tempo de execução por DNS TXT (0DIN, "Clone This Repo and I Own Your Machine", 2026). Quarentena virou parte do fluxo agentic porque revisão de código não enxerga o que só aparece depois do comando.

O ponto incômodo é que o agente não tentou atacar a máquina. Ele tentou ajudar. Leu instruções, encontrou erro, executou a correção sugerida e seguiu uma cadeia que parecia instalação normal. Para um humano cansado, isso também pareceria plausível.

Essa classe de risco é diferente de um arquivo malicioso óbvio. Ela nasce da combinação entre documentação, erro de pacote, script auxiliar, rede e confiança no agente. Cada peça isolada parece pequena; a sequência completa muda o estado da máquina.

Por isso, a quarentena precisa começar antes de npm install, pip install, make setup ou qualquer comando que o próprio erro sugira. Se o agente ainda não provou a origem do comando, o comando é dado não confiável.

Esse recorte complementa hooks para agentes de código e allowlist de MCP para agentes de código. Hooks interceptam ação. Allowlist limita ferramenta. Quarentena decide se o repositório merece sair da zona fria.

Cápsula citável: Quarentena de repositório é defesa pré-execução para agentes de código. Em 2026, a 0DIN mostrou payload fora do repositório, carregado em runtime por DNS TXT; por isso, setup de projeto desconhecido deve começar sem rede, sem segredos e sem permissão ampla.

O que fica bloqueado antes da primeira execução?

Em 2026, a documentação de segurança do Claude Code afirma que comandos que buscam conteúdo da web, como curl e wget, não são autoaprovados por padrão e pedem confirmação como outros comandos Bash sensíveis (Claude Code Docs, "Security", 2026). A quarentena transforma essa lógica em política de projeto.

Bloqueie rede de saída, variáveis de segredo, escrita fora da pasta temporária, servidores MCP e comandos de instalação até o agente produzir uma triagem. A triagem precisa apontar scripts chamados pelo setup, hooks de pacote, arquivos de workflow, dependências nativas e qualquer comando que busque conteúdo remoto.

O primeiro pedido ao agente deve ser leitura, não execução. Peça para listar pontos de entrada: package.json, pyproject.toml, Makefile, Dockerfile, workflows de CI, scripts de install e documentação de primeiro uso. Esse inventário dá base para decidir o que rodar.

Quando o fluxo for longo, use o RemoteCode para economizar contexto em sessões agentic de Codex e Claude Code sem despejar histórico repetido no prompt principal. É uma ferramenta minha, então a referência aqui é editorial e ligada ao custo de contexto em triagens demoradas.

Um detalhe importante: negar rede não basta se o ambiente carrega segredos. Um script local pode ler .env, token de nuvem ou chave SSH. Em quarentena, o ambiente começa limpo e só recebe credencial depois que a necessidade passa por revisão.

Cápsula citável: O bloqueio inicial deve cobrir rede, segredos, MCP, escrita ampla e instalação. Claude Code documenta aprovação explícita para comandos de rede; em repositório desconhecido, essa regra deve virar padrão operacional antes da primeira execução.

Como montar uma zona fria para Codex e Claude Code?

Em 2026, a documentação do Codex recomenda workspace-write com aprovações on-request como preset local de menor risco, enquanto "full access" combina danger-full-access com never (OpenAI Developers, "Sandbox", 2026). A zona fria usa o lado conservador dessa escolha.

Comece com leitura e aprovação manual. Em Codex, isso significa evitar o pacote de acesso total em repositórios recém-clonados. Em Claude Code, significa manter permissões estritas e usar sandbox para Bash quando o setup precisar sair da leitura.

Um contrato inicial pode ficar assim:

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"

Esse arquivo não é a defesa inteira. Ele é a linha de base. A defesa real vem do ambiente: clone em pasta descartável, sem .env, sem credenciais herdadas do shell, sem socket Docker sensível, sem kubeconfig pessoal e sem MCP conectado por conveniência.

Use contêiner ou máquina virtual quando o setup precisar compilar, baixar dependência ou executar binário desconhecido. A própria documentação do Claude Code recomenda VMs para scripts e chamadas de ferramenta em conteúdo não confiável (Claude Code Docs, "Security", 2026).

Fluxo abstrato mostra triagem, isolamento e promoção gradual para agente de código sem texto visível.

Experiência prática: quando trato um repositório como desconhecido, eu peço primeiro um mapa de scripts e riscos. Só depois rodo o menor comando verificável. Isso deixa o agente mais lento no começo, mas evita transformar erro de instalação em autorização implícita.

Cápsula citável: Zona fria para Codex e Claude Code combina leitura inicial, sandbox, aprovação manual e ambiente sem segredos. A documentação do Codex diferencia workspace-write com on-request de acesso total; em repositório desconhecido, a promoção de permissão deve depender de evidência.

Quando promover o repositório para execução normal?

Em abril de 2026, o estudo SWE-chat relatou 2,7 milhões de eventos, mais de 63 mil prompts e mais de 355 mil chamadas de ferramenta em interações reais de agentes de código (arXiv, "SWE-chat", 2026). A promoção importa porque tool use já é comportamento comum, não exceção.

Promova por fases. Primeiro, leitura. Depois, comandos sem rede e sem escrita ampla. Em seguida, instalação dentro de contêiner descartável. Por fim, execução normal apenas quando scripts, dependências e chamadas externas tiverem explicação revisável.

A regra de promoção deve caber em uma frase: o agente só recebe mais permissão quando a fase anterior gerou evidência compreensível. Essa evidência pode ser um inventário de scripts, um diff inexistente, uma lista de domínios acessados ou um log curto de instalação.

Não promova por cansaço. O padrão perigoso é "só deixa rodar para ver". Em fluxo agentic, rodar para ver pode acionar hooks de pacote, pós-instalação, binário nativo, telemetria ou comando buscado em runtime.

Use uma matriz simples:

Fase O agente pode Continua bloqueado
Triagem Ler arquivos e explicar setup Rede, segredos e MCP
Simulação Rodar comandos locais previsíveis Instalação com scripts remotos
Execução isolada Instalar em contêiner descartável Credenciais reais e deploy
Trabalho normal Editar e testar com escopo Escrita fora do repo e segredos amplos

Cápsula citável: Promover permissão por fase reduz risco porque tool use de agentes já aparece em escala. O SWE-chat registrou 2,7 milhões de eventos e mais de 355 mil chamadas de ferramenta; cada promoção deve deixar evidência de comando, escopo e origem.

Como a quarentena conversa com CI e revisão de PR?

Em junho de 2026, o GitHub passou a aplicar validação de segurança para agentes de terceiros com CodeQL, verificação de dependências no GitHub Advisory Database e secret scanning (GitHub Changelog, "Security validation for third-party coding agents", 2026). Quarentena local e CI resolvem momentos diferentes.

A quarentena protege a máquina antes do PR existir. O CI protege o repositório depois que o agente gerou mudança. Misturar as duas coisas cria buraco: se o setup comprometido roubou token local, nenhum CodeQL posterior desfaz o vazamento.

Ainda assim, o CI deve registrar o mesmo contrato. Se uma branch nasceu de repositório desconhecido, marque o PR com evidência: ambiente usado, rede permitida ou negada, segredo ausente, comandos executados e alertas de dependência.

Esse padrão conversa com evals de PR para agentes no CI e loop self-correcting de agente no CI. A diferença é que quarentena decide o que pode rodar antes do CI virar fonte de feedback.

Matriz abstrata mostra permissões por fases para agentes de código sem texto visível.

Cápsula citável: GitHub validou agentes de terceiros com CodeQL, dependências e secret scanning em 2026, mas isso não substitui quarentena local. O CI avalia o PR; a quarentena impede que setup desconhecido comprometa a estação antes de qualquer PR existir.

Checklist de quarentena para o próximo repo

Em maio de 2026, o GitHub afirmou que o Copilot code review já processou mais de 60 milhões de revisões e que mais de uma em cada cinco revisões no GitHub envolve um agente (GitHub Blog, "Agent pull requests are everywhere", 2026). O volume pede checklist simples, repetível e barato.

Antes de pedir "rode o projeto", peça "mapeie o projeto sem executar". Depois confira scripts de instalação, pós-instalação, rede, binários nativos, workflows e arquivos de configuração do agente. Só então escolha o menor comando seguro.

Use este fluxo:

  • Clone em diretório descartável, sem herdar .env.
  • Inicie o agente em leitura ou com aprovação manual.
  • Desative MCP até entender a origem do repositório.
  • Peça inventário de scripts e comandos de setup.
  • Rode instalação em contêiner ou VM quando houver incerteza.
  • Promova permissões só com log curto e justificativa.
  • Apague o ambiente se algum comando buscar payload externo inesperado.

Quarentena não é desconfiança contra IA. É a mesma disciplina que já usamos com dependências, CI e produção. A diferença é que agora o agente consegue juntar documentação, erro, shell e rede em uma sequência que parece trabalho normal.

Cápsula citável: O checklist de quarentena existe porque revisão agentic já chegou ao cotidiano. GitHub relatou mais de 60 milhões de revisões com Copilot code review; antes de ampliar agentes, times precisam padronizar leitura, isolamento, rede, segredos e promoção de permissão.

Perguntas frequentes

Quarentena é necessária em todo repositório?

Não. Em 2026, a 0DIN mostrou risco específico em repositório desconhecido com payload fora do código (0DIN, "Clone This Repo and I Own Your Machine"). Repositórios internos e recorrentes podem ter perfil mais flexível, mas projeto novo, tutorial, prova de conceito ou link recebido em chat deve começar sem rede, segredos e permissão ampla.

Posso confiar se o scanner não achou nada?

Não totalmente. Em 2026, a 0DIN mostrou payload que não estava no repositório e foi buscado por DNS TXT em runtime (0DIN, "Clone This Repo and I Own Your Machine"). Scanner de código pode perder a cadeia quando cada peça isolada parece normal. Quarentena observa execução, não só arquivo.

O modo workspace-write resolve sozinho?

Não sozinho. Em 2026, a documentação do Codex descreve workspace-write com aprovações on-request como preset local de menor risco (OpenAI Developers, "Sandbox"). Mesmo assim, ainda é preciso negar segredos herdados, rede desnecessária, MCP amplo e comandos de setup sem triagem.

Quando MCP pode ser religado?

Depois da triagem. Em 2026, o Claude Code documenta verificação de confiança para novos servidores MCP e primeira execução de codebase (Claude Code Docs, "Security"). Em repositório desconhecido, religue apenas ferramentas necessárias, com escopo estreito e sem credenciais sensíveis no primeiro ciclo.

Fontes

  • 0DIN, "Clone This Repo and I Own Your Machine", consultado em 2026-07-10, https://0din.ai/blog/clone-this-repo-and-i-own-your-machine
  • OpenAI Developers, "Sandbox", consultado em 2026-07-10, https://developers.openai.com/codex/concepts/sandboxing
  • OpenAI Developers, "Agent approvals & security", consultado em 2026-07-10, https://developers.openai.com/codex/agent-approvals-security
  • Claude Code Docs, "Security", consultado em 2026-07-10, https://code.claude.com/docs/en/security
  • Claude Code Docs, "Settings", consultado em 2026-07-10, https://code.claude.com/docs/en/settings
  • GitHub Changelog, "Security validation for third-party coding agents", consultado em 2026-07-10, https://github.blog/changelog/2026-06-09-security-validation-for-third-party-coding-agents/
  • arXiv, "SWE-chat: Coding Agent Interactions From Real Users in the Wild", consultado em 2026-07-10, https://arxiv.org/html/2604.20779v1
  • GitHub Blog, "Agent pull requests are everywhere. Here's how to review them", consultado em 2026-07-10, https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/