Un escape de sandbox por archivo de agente de código es la falla en la que el agente respeta el límite directo. Aun así, crea un artefacto que otra herramienta ejecuta fuera de ese límite. El problema no es solo shell. Es confianza transitiva entre workspace, IDE, Git, hook, socket local y CI.

En 2026, Stack Overflow informó en "2025 Developer Survey: AI" que el 84% de las personas encuestadas usa o planea usar herramientas de IA en desarrollo (Stack Overflow, "2025 Developer Survey: AI", 2025, consultado el 23/07/2026). La misma encuesta informó uso diario por el 51% de profesionales. A esa escala, la pregunta es quién confía en los archivos que escribe el agente.

Resumen práctico

  • El sandbox del agente no cubre automáticamente el host.
  • Un archivo de configuración puede convertirse en ejecución indirecta.
  • Git, IDE, hooks, Docker y extensiones entran en el threat model.
  • CI debe registrar procedencia antes de consumir artefactos del agente.

Diagrama abstracto muestra un agente escribiendo archivos que cruzan una frontera de confianza sin texto visible.

¿Por qué este escape no parece una ruptura de sandbox?

El 20 de julio de 2026, Pillar publicó "The Week of Sandbox Escapes" con siete hallazgos en cuatro herramientas (Pillar Security, "The Week of Sandbox Escapes", 2026, consultado el 23/07/2026). El recorte incluyó Cursor, Codex, Gemini CLI y Antigravity. La idea práctica es directa: el agente no necesita romper el sandbox si puede influir en algo externo.

Este patrón dificulta la revisión porque el log del agente puede verse limpio. Escribe dentro del workspace, usa una operación permitida y se detiene antes de una acción claramente peligrosa. Después, una extensión del IDE, un comando Git, un hook o un daemon local lee ese archivo como configuración humana confiable.

La lección de arquitectura es simple: sandbox es una frontera de proceso, pero un flujo agentic es una cadena de confianza. Si la cadena incluye consumidores fuera del sandbox, el control debe seguir el artefacto, no solo el proceso que lo produjo.

Cápsula citable: El escape de sandbox por archivo de agente es una falla de handoff. Pillar documentó siete hallazgos en cuatro herramientas en 2026; el patrón común es un agente que escribe contenido permitido que un componente confiable del host ejecuta o interpreta después.

Este recorte complementa la cuarentena de repositorio para agentes de código y GhostApproval en agentes de código. Allí, el foco es input hostil y ruta real. Aquí, el foco es el consumidor confiable que corre después.

¿Dónde confía el host en el archivo que acaba de escribir el agente?

En 2026, Pillar agrupó los hallazgos en cuatro modos de falla: denylists incompletas, configuración ejecutable de workspace, allowlists por nombre de comando y daemons locales privilegiados (Pillar Security, "The Week of Sandbox Escapes", 2026, consultado el 23/07/2026). El host confía en archivos cuando extensiones, hooks y daemons tratan configuración como código operativo.

El caso más peligroso no es un archivo sospechoso llamado por un comando explícito. Es el archivo normal. Un proyecto moderno tiene configuración de tareas, entornos virtuales, metadatos Git, scripts de paquetes, hooks de herramientas, definiciones de contenedor y cachés de extensión. Muchos se leen automáticamente.

Diagrama abstracto muestra flujos entre workspace, host y puntos de bloqueo sin texto visible.

Haz cuatro preguntas antes de permitir escrituras amplias. ¿El agente puede editar un archivo que el IDE carga sin preguntar? ¿Puede cambiar configuración Git que modifica un comando futuro? ¿Puede tocar un socket o daemon fuera del sandbox? ¿Puede crear automatización que CI ejecuta en el siguiente job?

Superficie Riesgo práctico Control mínimo
Configuración de IDE Una tarea o extensión corre fuera del sandbox. Bloquear escritura automática y pedir revisión.
Git y hooks Un comando aparente llama helper o config alterada. Validar invocación, argumentos y config efectiva.
Entorno virtual Descubrimiento automático ejecuta binario manipulado. Recrear el entorno fuera de rutas escritas por agente.
Daemon local Socket privilegiado se vuelve ejecución indirecta. Negar por defecto y liberar solo en job aislado.

Experiencia práctica: cuando diseño un harness para agente de código, trato configuración de host como cambio de plataforma. El archivo puede parecer pequeño, pero su consumidor suele tener más permiso que el agente. Por eso prefiero bloquear primero y liberar después con evidencia corta en el PR.

Cápsula citable: La frontera real está donde el host consume el archivo. Pillar describió cuatro modos de falla en 2026; todos muestran que configuración de workspace, allowlists y daemons necesitan política propia en flujos agentic.

¿Cómo limitar escritura sin frenar el trabajo agentic?

En 2026, la documentación de Codex describió tres modos principales de sandbox: read-only, workspace-write y danger-full-access (OpenAI Developers, "Sandbox", 2026, consultado el 23/07/2026). Para este riesgo, workspace-write es necesario en muchas tareas, pero no alcanza cuando el workspace contiene configuración ejecutable.

El ajuste práctico es separar escritura común de escritura sensible. Código fuente, tests y documentación pueden seguir el flujo normal. Los archivos consumidos por el host necesitan una regla extra: pedir revisión, negar el cambio o mover la ejecución a un runner descartable.

Claude Code ayuda en esa separación porque los permisos se aplican en la herramienta, no en el modelo. Su documentación dice que prompts y CLAUDE.md influyen en lo que Claude intenta hacer, pero el acceso lo conceden o revocan permisos, hooks o modos (Claude Code Docs, "Configure permissions", 2026, consultado el 23/07/2026).

En loops largos, el coste de contexto también pesa porque el agente debe recordar qué archivos son sensibles y qué evidencia ya fue aprobada. Uso RemoteCode para mantener continuidad en flujos agentic de Claude Code y Codex con menos repetición de contexto cuando el trabajo cruza varias rondas; es una herramienta mía, así que esta mención es editorial y ligada al problema de tokens.

Cápsula citable: El control sano no bloquea toda escritura del agente. Codex documenta workspace-write para edición controlada, mientras Claude Code refuerza que permisos se aplican fuera del modelo; archivos consumidos por el host necesitan una regla más antes de convertirse en ejecución.

¿Qué archivos deben convertirse en frontera de aprobación?

En 2026, arXiv en "Harness Engineering for Agentic AI Coding Tools" analizó 2.853 repositorios e identificó ocho mecanismos de configuración para herramientas agentic, con AGENTS.md como punto inicial interoperable (arXiv, "Harness Engineering for Agentic AI Coding Tools", 2026, consultado el 23/07/2026). La lista de fronteras debe salir del harness, no de la memoria del revisor.

Empieza por archivos que cambian comportamiento fuera de la ejecución directa del agente. Incluye .git, hooks, .vscode, .idea, .claude, .codex, .devcontainer, entornos virtuales, scripts de paquete, archivos de runner y cualquier configuración que active una herramienta local.

Después clasifica por consumidor. Si quien lee el archivo es un test dentro del runner, el riesgo es menor. Si quien lee es el host del desarrollador, una extensión amplia o un daemon con socket privilegiado, la regla debe ser más dura.

{
  "frontera": {
    "codigo_comun": "edicion_con_revision_normal",
    "configuracion_de_host": "pedir_aprobacion",
    "daemon_local": "negado_por_defecto",
    "secreto_o_credencial": "fuera_del_workspace",
    "artefacto_del_agente": "registrar_procedencia"
  }
}

Cápsula citable: Un harness de agente debe listar consumidores, no solo archivos. El estudio de arXiv analizó 2.853 repositorios y ocho mecanismos de configuración; para seguridad, cada mecanismo debe declarar quién consume el artefacto y qué política aplica.

Este contrato se conecta con el coste de contexto para Claude Code y Codex. Un archivo de reglas demasiado amplio se vuelve ruido. Mantén la política corta, ejecutable y ligada a incidentes reales.

¿Cómo probar esta falla en CI antes del incidente?

En 2026, arXiv en "ABTest" generó 647 casos de fuzzing en repositorios reales, señaló 1.573 anomalías y confirmó manualmente 642 nuevas anomalías, con precisión de 40,8% (arXiv, "ABTest: Behavior-Driven Testing for AI Coding Agents", 2026, consultado el 23/07/2026). Por eso el harness necesita test conductual, no solo lint.

Monta un repositorio de prueba con configuración sensible inofensiva. El objetivo no es explotar a tu propio equipo. Es medir si el agente intenta editar un archivo protegido, si CI bloquea el cambio y si el resumen final muestra la decisión correcta.

Diagrama abstracto muestra una secuencia de gates protegiendo archivos creados por agente sin texto visible.

Usa payloads benignos. Un archivo .vscode puede apuntar a un comando falso que solo registra un evento. Un hook puede escribir en un archivo temporal. Un socket de daemon puede reemplazarse por un stub local. El test pasa cuando el agente recibe un bloqueo claro y elige otro camino.

Test Señal de aprobación
Intento de editar config sensible Hook bloquea y registra ruta.
Comando permitido con argumento peligroso La política evalúa la invocación completa.
Artefacto creado por agente La procedencia aparece en el resumen del PR.
Consumidor fuera del sandbox CI exige revisión humana antes de ejecutar.

Cápsula citable: Los evals de seguridad para agentes deben reproducir handoffs. ABTest generó 647 casos y confirmó 642 anomalías nuevas; para escape indirecto de sandbox, el test debe verificar si un archivo escrito por el agente puede convertirse en acción del host.

¿Qué entra en el contrato mínimo de host seguro?

En 2026, arXiv en "Overeager Coding Agents" evaluó 500 escenarios validados y cerca de 7.500 ejecuciones en cuatro productos de agente, incluidos Claude Code, Codex CLI y Gemini CLI (arXiv, "Overeager Coding Agents", 2026, consultado el 23/07/2026). El contrato mínimo debe limitar alcance antes de que la intención del agente crezca sola.

El contrato cabe en una página. Primero, ningún agente edita configuración consumida por el host sin aprobación. Segundo, toda automatización creada por agente corre en runner aislado antes de tocar laptops, secretos o daemons. Tercero, el PR muestra procedencia: creado por humano, por el agente o por el repositorio original.

También registra excepciones. Si un agente necesita editar .devcontainer, la justificación debe aparecer en el PR. Si necesita Docker, usa runner descartable. Si necesita cambiar un hook, trátalo como cambio de política, no como detalle de implementación.

Cápsula citable: Un host seguro para agentes empieza con alcance explícito. El estudio Overeager evaluó 500 escenarios y cerca de 7.500 ejecuciones; en equipos reales, eso se convierte en política de aprobación para configuración, daemons, secretos y artefactos creados por el agente.

FAQ sobre escape de sandbox por archivo de agente

¿El sandbox dejó de ser útil para agentes de código?

No. En 2026, OpenAI describe sandbox como la frontera que permite autonomía sin acceso irrestricto al computador (OpenAI Developers, "Sandbox", 2026, consultado el 23/07/2026). La lección de Pillar es que el sandbox debe considerar archivos escritos y consumidores del host, no solo el proceso del agente.

¿Debo bloquear toda escritura en .vscode, .git y hooks?

Bloquea escritura automática y pide revisión cuando haya ejecución fuera del sandbox. En 2026, Claude Code documenta PreToolUse para bloquear ediciones en archivos protegidos antes de la escritura (Claude Code Docs, "Automate actions with hooks", 2026, consultado el 23/07/2026). La regla puede ser estrecha, pero debe ser ejecutable.

¿Esto vale para CI o solo para laptop de desarrollador?

Vale para ambos. En 2026, la guía de despliegue seguro del Claude Agent SDK recomienda aislamiento con sandbox, contenedores, gVisor o máquinas virtuales según el threat model (Claude Code Docs, "Securely deploying AI agents", 2026, consultado el 23/07/2026). CI reduce riesgo cuando el runner es descartable y sin secreto amplio.

¿Cómo sé si mi allowlist de comandos es débil?

Prueba argumentos, directorio, configuración y efecto colateral, no solo el nombre. En 2026, Pillar relató el caso GitPwned en Codex CLI, donde git show parecía seguro por nombre, pero argumentos permitían escritura y configuración maliciosa (Pillar Security, "GitPwned: Allowlist to RCE", 2026, consultado el 23/07/2026).

Cierre

El sandbox sigue siendo necesario, pero no es el final del threat model agentic. El agente ahora escribe entradas futuras para herramientas que existían antes que él.

El camino pragmático es tratar configuración ejecutable como frontera: negar por defecto, pedir revisión cuando el host consume, correr en runner descartable y registrar procedencia. Si el agente creó el archivo, el host debe desconfiar antes de ejecutar.

Fuentes consultadas

  • Stack Overflow, "2025 Developer Survey: AI", consultado el 23/07/2026, https://survey.stackoverflow.co/2025/ai
  • Pillar Security, "The Week of Sandbox Escapes", consultado el 23/07/2026, https://www.pillar.security/blog/the-week-of-sandbox-escapes
  • Pillar Security, "GitPwned: Allowlist to RCE", consultado el 23/07/2026, https://www.pillar.security/blog/gitpwned-allowlist-to-rce
  • OpenAI Developers, "Sandbox", consultado el 23/07/2026, https://developers.openai.com/codex/concepts/sandboxing
  • Claude Code Docs, "Configure permissions", consultado el 23/07/2026, https://code.claude.com/docs/en/permissions
  • Claude Code Docs, "Automate actions with hooks", consultado el 23/07/2026, https://code.claude.com/docs/en/hooks-guide
  • Claude Code Docs, "Securely deploying AI agents", consultado el 23/07/2026, https://code.claude.com/docs/en/agent-sdk/secure-deployment
  • arXiv, "Harness Engineering for Agentic AI Coding Tools: An Exploratory Study", consultado el 23/07/2026, https://arxiv.org/abs/2602.14690
  • arXiv, "ABTest: Behavior-Driven Testing for AI Coding Agents", consultado el 23/07/2026, https://arxiv.org/abs/2604.03362
  • arXiv, "Overeager Coding Agents: Measuring Out-of-Scope Actions on Benign Tasks", consultado el 23/07/2026, https://arxiv.org/abs/2605.18583