Cuarentena de repositorio para agentes de código es abrir un proyecto desconocido sin dar al agente shell amplio, red, secretos, MCP o scripts de instalación desde el primer turno. El agente puede leer y explicar primero. La ejecución viene después, cuando el repositorio gana confianza.

El 25 de junio de 2026, 0DIN publicó "Clone This Repo and I Own Your Machine", mostrando un repositorio aparentemente normal que llevó Claude Code a una shell reversa mediante un error rutinario, un script de setup y DNS TXT (0DIN, "Clone This Repo and I Own Your Machine", 2026). La defensa empieza antes de setup.

Resumen práctico

  • Abre repos desconocidos en modo lectura y sin secretos.
  • Niega red y MCP hasta terminar el triage.
  • Ejecuta setup solo en entornos descartables y observables.
  • Promueve permisos por evidencia, no por comodidad.

Diagrama abstracto muestra un repositorio aislado antes de llegar a un agente de código sin texto visible.

¿Por qué la cuarentena entró al flujo agentic?

En 2026, 0DIN describió una cadena donde el payload malicioso no estaba en el repositorio y se obtenía en runtime desde un registro DNS TXT (0DIN, "Clone This Repo and I Own Your Machine", 2026). La cuarentena importa porque la revisión de código no ve lo que aparece solo después de ejecutar.

Lo incómodo es que el agente intentaba ayudar. Leyó instrucciones, encontró un error, ejecutó la corrección sugerida y siguió una cadena que parecía instalación normal. Un humano cansado también podría ver ese camino como plausible.

Esta clase de riesgo no es solo un archivo sospechoso. Es la secuencia de documentación, error de paquete, script auxiliar, red y confianza en el agente. Cada pieza parece pequeña. La cadena completa cambia la máquina.

Por eso la cuarentena empieza antes de npm install, pip install, make setup o cualquier comando sugerido por el propio error. Si el agente aún no probó adónde lleva el comando, el comando es input no confiable.

Este recorte complementa hooks para agentes de código y allowlist MCP para agentes de código. Los hooks interceptan acción. Las allowlists limitan herramientas. La cuarentena decide si el repositorio sale de la zona fría.

Cápsula citable: La cuarentena de repositorio es defensa previa a la ejecución para agentes de código. En 2026, 0DIN mostró payload fuera del repositorio, cargado en runtime por DNS TXT; por eso, el setup desconocido debe empezar sin red, secretos ni permiso amplio.

¿Qué queda bloqueado antes de la primera ejecución?

En 2026, la documentación de seguridad de Claude Code dice que comandos que traen contenido de la web, como curl y wget, no se autoaprueban por defecto y piden confirmación como otros comandos Bash sensibles (Claude Code Docs, "Security", 2026). La cuarentena convierte esa lógica en política de proyecto.

Bloquea red saliente, variables de secreto, escritura fuera de la carpeta temporal, servidores MCP y comandos de instalación hasta que el agente produzca un triage. Ese triage debe identificar scripts de setup, hooks de paquete, workflows, dependencias nativas y comandos que traen contenido remoto.

El primer pedido al agente debe ser lectura, no ejecución. Pídele listar puntos de entrada: package.json, pyproject.toml, Makefile, Dockerfile, workflows de CI, scripts de install y documentación de primer uso. Ese inventario permite decidir el siguiente comando.

En sesiones largas, uso RemoteCode para reducir contexto repetido en sesiones agentic de Codex y Claude Code en vez de meter el mismo historial en el prompt principal. Es una herramienta mía, así que esta mención es editorial y ligada al costo de contexto durante triages extensos.

Negar red no alcanza si el entorno carga secretos. Un script local puede leer .env, tokens de nube o llaves SSH. En cuarentena, el entorno empieza limpio y solo recibe credenciales cuando la necesidad pasa por revisión.

Cápsula citable: El bloqueo inicial debe cubrir red, secretos, MCP, escritura amplia e instalación. Claude Code documenta aprobación explícita para comandos de red; en repositorios desconocidos, esa regla debe ser el modo operativo antes de ejecutar.

¿Cómo montar una zona fría para Codex y Claude Code?

En 2026, la documentación de Codex recomienda workspace-write con aprobaciones on-request como preset local de menor riesgo, mientras el acceso total combina danger-full-access con never (OpenAI Developers, "Sandbox", 2026). La zona fría elige el lado conservador.

Empieza con lectura y aprobación manual. En Codex, evita el paquete de acceso total para repositorios recién clonados. En Claude Code, mantén permisos estrictos y usa sandbox para Bash cuando el setup necesite pasar de la lectura.

Un contrato base puede verse así:

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

Ese archivo no es toda la defensa. El límite real es el entorno: clona en carpeta descartable, sin .env, sin credenciales heredadas del shell, sin socket Docker sensible, sin kubeconfig personal y sin MCP conectado por comodidad.

Usa contenedor o máquina virtual cuando el setup necesite compilar, descargar dependencias o ejecutar binarios desconocidos. La propia documentación de Claude Code recomienda VMs para scripts y llamadas de herramienta al interactuar con contenido no confiable (Claude Code Docs, "Security", 2026).

Flujo abstracto muestra triage, aislamiento y promoción gradual para agente de código sin texto visible.

Experiencia práctica: cuando trato un repo como desconocido, primero pido un mapa de scripts y riesgos. Después ejecuto el menor comando verificable. Eso vuelve el comienzo más lento, pero evita convertir una falla de instalación en autorización implícita.

Cápsula citable: Una zona fría para Codex y Claude Code combina lectura inicial, sandbox, aprobación manual y entorno sin secretos. La documentación de Codex distingue workspace-write con on-request del acceso total; un repo desconocido debe ganar permisos con evidencia.

¿Cuándo promover el repo a ejecución normal?

En abril de 2026, el estudio SWE-chat reportó 2,7 millones de eventos, más de 63 mil prompts y más de 355 mil llamadas de herramienta en interacciones reales con agentes de código (arXiv, "SWE-chat", 2026). La promoción importa porque tool use ya es normal, no excepción.

Promueve por fases. Primero, lectura. Luego, comandos locales sin red ni escritura amplia. Después, instalación dentro de un contenedor descartable. Al final, ejecución normal solo cuando scripts, dependencias y llamadas externas tengan explicación revisable.

La regla debe caber en una frase: el agente recibe más permiso solo cuando la fase anterior produjo evidencia comprensible. Esa evidencia puede ser inventario de scripts, diff vacío, lista de dominios o log corto de instalación.

No promuevas por cansancio. El patrón peligroso es "déjalo correr para ver". En flujo agentic, correr para ver puede activar hooks de paquete, pasos post-install, binarios nativos, telemetría o comandos obtenidos en runtime.

Usa una matriz compacta:

Fase El agente puede Sigue bloqueado
Triage Leer archivos y explicar setup Red, secretos y MCP
Simulación Ejecutar comandos locales previsibles Instalación con scripts remotos
Ejecución aislada Instalar en contenedor descartable Credenciales reales y deploy
Trabajo normal Editar y probar con alcance Escritura fuera del repo y secretos amplios

Cápsula citable: Promover permisos por fase reduce riesgo porque tool use de agentes ya ocurre a escala. SWE-chat registró 2,7 millones de eventos y más de 355 mil llamadas de herramienta; cada promoción debe dejar evidencia de comando, alcance y origen.

¿Cómo se conecta la cuarentena con CI y revisión de PR?

En junio de 2026, GitHub extendió validación de seguridad para agentes de terceros con CodeQL, revisión de dependencias contra GitHub Advisory Database y secret scanning (GitHub Changelog, "Security validation for third-party coding agents", 2026). Cuarentena local y CI protegen momentos distintos.

La cuarentena protege la máquina antes de que exista un PR. El CI protege el repositorio después de que el agente crea un cambio. Si el setup ya filtró un token local, ningún CodeQL posterior deshace esa fuga.

Aun así, el CI debe llevar el mismo contrato. Si una branch nació de un repo desconocido, pon la evidencia en el PR: entorno usado, red permitida o negada, secretos ausentes, comandos ejecutados y alertas de dependencia.

Esto conversa con evals de PR para agentes en CI y loops autocorrectivos en CI. La diferencia es el momento: la cuarentena decide qué puede correr antes de que CI sea feedback.

Matriz abstracta muestra fases de permiso para agentes de código sin texto visible.

Cápsula citable: GitHub validó agentes de terceros con CodeQL, dependencias y secret scanning en 2026, pero eso no reemplaza la cuarentena local. El CI evalúa el PR; la cuarentena evita que setup desconocido comprometa la estación antes de que exista un PR.

Checklist de cuarentena para el próximo repo

En mayo de 2026, GitHub dijo que Copilot code review había procesado más de 60 millones de revisiones y que más de una de cada cinco revisiones en GitHub involucraba un agente (GitHub Blog, "Agent pull requests are everywhere", 2026). Ese volumen pide checklist simple y repetible.

Antes de pedir "ejecuta el proyecto", pide "mapea el proyecto sin ejecutar". Luego revisa scripts de instalación, hooks post-install, red, binarios nativos, workflows y archivos de configuración del agente. Solo entonces elige el menor comando seguro.

Usa este flujo:

  • Clona en un directorio descartable, sin heredar .env.
  • Inicia el agente en lectura o con aprobación manual.
  • Desactiva MCP hasta entender el origen del repositorio.
  • Pide inventario de scripts y comandos de setup.
  • Ejecuta instalación en contenedor o VM si hay incertidumbre.
  • Promueve permisos solo con log corto y motivo.
  • Borra el entorno si un comando obtiene payload externo inesperado.

La cuarentena no es desconfianza contra la IA. Es la misma disciplina que ya usamos con dependencias, CI y producción. La diferencia es que ahora el agente puede unir documentación, error, shell y red en una secuencia que parece trabajo normal.

Cápsula citable: El checklist de cuarentena existe porque la revisión agentic ya es cotidiana. GitHub reportó más de 60 millones de revisiones con Copilot code review; antes de ampliar agentes, los equipos deben estandarizar lectura, aislamiento, red, secretos y promoción de permisos.

Preguntas frecuentes

¿La cuarentena es necesaria en todo repositorio?

No. En 2026, 0DIN mostró un riesgo específico en repositorios desconocidos con payload fuera del código (0DIN, "Clone This Repo and I Own Your Machine"). Repos internos y recurrentes pueden ser más flexibles, pero proyecto nuevo, tutorial, prueba de concepto o link de chat debe empezar sin red, secretos ni permiso amplio.

¿Puedo confiar si el scanner no encontró nada?

No totalmente. En 2026, 0DIN mostró un payload que no estaba en el repositorio y fue obtenido por DNS TXT en runtime (0DIN, "Clone This Repo and I Own Your Machine"). Los scanners pueden perder cadenas donde cada pieza aislada parece normal. La cuarentena observa ejecución, no solo archivos.

¿workspace-write lo resuelve por sí solo?

No por sí solo. En 2026, la documentación de Codex describe workspace-write con aprobaciones on-request como preset local de menor riesgo (OpenAI Developers, "Sandbox"). Aun así, hay que quitar secretos heredados, red innecesaria, MCP amplio y setup sin triage.

¿Cuándo se puede activar MCP otra vez?

Después del triage. En 2026, Claude Code documenta verificación de confianza para nuevos servidores MCP y primeras ejecuciones de codebase (Claude Code Docs, "Security"). En un repo desconocido, activa solo herramientas necesarias, con alcance estrecho y sin credenciales sensibles en el primer ciclo.

Fuentes

  • 0DIN, "Clone This Repo and I Own Your Machine", consultado en 2026-07-10, https://0din.ai/blog/clone-this-repo-and-i-own-your-machine
  • OpenAI Developers, "Sandbox", consultado en 2026-07-10, https://developers.openai.com/codex/concepts/sandboxing
  • OpenAI Developers, "Agent approvals & security", consultado en 2026-07-10, https://developers.openai.com/codex/agent-approvals-security
  • Claude Code Docs, "Security", consultado en 2026-07-10, https://code.claude.com/docs/en/security
  • Claude Code Docs, "Settings", consultado en 2026-07-10, https://code.claude.com/docs/en/settings
  • GitHub Changelog, "Security validation for third-party coding agents", consultado en 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 en 2026-07-10, https://arxiv.org/html/2604.20779v1
  • GitHub Blog, "Agent pull requests are everywhere. Here's how to review them", consultado en 2026-07-10, https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/