Sandboxing y permisos para agentes de código: guía segura

Un agente de código no es solo un autocompletador. Según cómo lo configures, puede inspeccionar un repositorio, escribir archivos, ejecutar tests, instalar dependencias, consultar internet y proponer cambios. El riesgo no está únicamente en que genere código incorrecto: también puede obedecer instrucciones maliciosas encontradas en un issue, un README o una dependencia.

La defensa práctica es separar cuatro decisiones que suelen mezclarse: qué archivos puede tocar, qué comandos puede ejecutar, a qué red puede salir y qué acciones necesitan aprobación. El sandbox pone límites técnicos; la política de aprobación decide cuándo el agente debe detenerse. Una aprobación no sustituye al aislamiento y un sandbox demasiado amplio no se arregla con un botón de “sí”.

Qué dicen las herramientas actuales

La siguiente tabla resume controles descritos en documentación oficial consultada el 3 de septiembre de 2026. No son equivalentes entre productos: sirven como referencia para diseñar tu propia frontera de confianza.

Superficie	Aislamiento o permiso documentado	Decisión operativa
Codex local	El sandbox del sistema limita el acceso, con red desactivada por defecto y escritura normalmente restringida al workspace activo	Trabaja en un repositorio o worktree dedicado; habilita red solo para una necesidad concreta
Codex cloud	Ejecuta el agente en contenedores aislados; la fase de preparación puede usar red y la fase del agente queda offline por defecto	No expongas secretos durante la fase de trabajo; separa instalación de ejecución
Claude Code en modo manual	Comienza con permisos de solo lectura y pide aprobación para editar, probar o ejecutar comandos; su Bash sandbox puede aislar filesystem y red	Mantén modo manual para repositorios con datos sensibles y aprueba comandos individualmente
GitHub Copilot cloud agent	Usa un entorno de desarrollo efímero basado en GitHub Actions y trabaja sobre una rama que puedes revisar antes del pull request	Exige diff, tests y revisión humana antes de integrar cambios
OWASP	Recomienda mínimo privilegio, aprobación humana para acciones de alto riesgo, separación del contenido externo y pruebas adversariales	Trata el modelo como un usuario no confiable, no como una credencial con criterio propio

Estas medidas reducen el radio de explosión, pero no garantizan que el resultado sea seguro. Si un agente tiene acceso de lectura a todo tu directorio personal, una instrucción escondida puede intentar buscar archivos que no necesita. Si puede usar la red, también puede enviar datos o descargar una dependencia vulnerable. Por eso la primera pregunta no es qué herramienta te gusta, sino qué acceso necesita realmente la tarea.

La política mínima que sí vale la pena configurar

Empieza con una tarea concreta y un workspace desechable. La política base debería parecerse a esto:

workspace:
  root: ./repo-de-trabajo
  write: true
  outside_root: false
network:
  enabled: false
  allowlist: []
credentials:
  inherited: false
  injected: only-when-required
commands:
  auto_approve: [read-only, tests-locales]
  require_approval: [install, network, deploy, database-write]
review:
  require_diff: true
  require_tests: true
  human_before_merge: true

No copies esta configuración literalmente a una herramienta que use otro formato. Úsala como contrato para traducir a sus controles reales. El detalle importante es la combinación: directorio limitado, red cerrada, credenciales no heredadas y aprobación explícita para acciones con efectos externos.

1. Reduce el filesystem antes de reducir la vigilancia

El agente necesita el repositorio, no tus llaves SSH, tu carpeta de documentos ni todos los proyectos hermanos. Ejecutarlo desde un worktree separado ayuda a revisar y descartar cambios sin contaminar el checkout principal. Excluye .env, historiales de shell, claves privadas, archivos de producción y dumps de bases de datos.

La frontera debe aplicarse a los comandos que el agente lanza, no solo a su herramienta de edición. Un test runner, Git o un gestor de paquetes pueden leer y escribir por su cuenta. La documentación de Codex describe precisamente este punto: los comandos iniciados dentro del sandbox heredan sus límites.

2. Mantén la red cerrada durante la edición

Una guía de código rara vez necesita internet para corregir una función y ejecutar tests locales. Activa red únicamente para instalar una dependencia o consultar una documentación específica; después vuelve a cerrarla. Si el producto permite una allowlist, autoriza dominios concretos y, cuando sea suficiente, limita los métodos HTTP a GET, HEAD y OPTIONS.

El contenido externo es entrada no confiable. Un issue puede contener una instrucción que parezca parte de la tarea, pero que intente ejecutar un curl con información del repositorio. La recomendación de prompt injection y defensas por capa aplica especialmente a agentes de código: no pegues texto externo en el contexto como si fuera una orden de confianza.

3. No heredes credenciales por comodidad

El agente no debería recibir automáticamente tus tokens de GitHub, producción, cloud o pagos. Usa credenciales efímeras y con alcance limitado cuando la tarea las necesite. Para una instalación, un token de lectura de paquetes puede bastar; no hace falta entregar una clave capaz de desplegar o modificar una base de datos.

Nunca uses secretos como mecanismo de comunicación con el modelo. La aplicación o el runtime debe ejecutar las operaciones privilegiadas y devolver solo el resultado mínimo. Si el agente necesita abrir un pull request, es preferible un flujo controlado de CI que valide el diff a dejarle una credencial permanente con capacidad de escribir en producción. Para ampliar este tema, consulta cómo evitar fugas de datos en agentes de IA.

Qué aprobar y qué bloquear

Clasifica acciones por impacto, no por lo convincente que suene la explicación del agente:

• Bajo riesgo: leer archivos del workspace, ejecutar formatter, correr tests sin red y generar un diff.
• Riesgo medio: instalar paquetes, modificar configuración de CI, acceder a un dominio nuevo o leer un archivo fuera del workspace.
• Alto riesgo: publicar, borrar datos, cambiar permisos, escribir en una base de datos, enviar mensajes o subir secretos.

Las dos últimas categorías deben detenerse para revisión humana. El agente puede preparar el comando o el cambio, pero una persona debe confirmar el alcance y revisar el resultado. El pull request no es una formalidad: es la frontera donde se inspeccionan diff, tests, dependencias nuevas y archivos tocados. Claude Code vs. Codex compara sus modelos de permisos y aprobación desde la perspectiva de uso diario.

Matriz de verificación antes de confiar

Haz esta prueba con un repositorio de laboratorio y una credencial señuelo, nunca con producción:

Prueba	Resultado aceptable	Si falla
Leer ../otro-proyecto	Bloqueado o pide aprobación	Reduce el root del workspace
Ejecutar curl sin red	Bloqueado	Desactiva red por defecto
Leer .env	Excluido o pide aprobación	Retira secretos heredados y añade deny rules
Instalar una dependencia	Pide aprobación o usa fase controlada	Separa setup de ejecución
Intentar borrar datos	Detenido antes de ejecutar	Añade aprobación obligatoria y backup
Producir cambios	Diff en rama aislada	No integres directamente a la rama principal

Registra qué pasó, no solo si el agente terminó la tarea. La observabilidad de agentes debe mostrar comandos, herramientas, dominios, archivos modificados y decisiones de aprobación sin registrar valores secretos.

La regla para operar sin martirio

Usa autonomía dentro de una caja pequeña y fricción fuera de ella. Un agente que pide aprobación para cada lectura es inútil; uno que puede navegar todo tu equipo, usar la red y desplegar por sí solo es una apuesta innecesaria. El punto medio es un worktree aislado, filesystem mínimo, red cerrada, credenciales efímeras, comandos clasificados y revisión obligatoria del diff antes de integrar.

Configura primero esa política con un proyecto de prueba. Luego mide cuántas aprobaciones son ruido y ajusta allowlists específicas, no permisos globales. La seguridad correcta no consiste en confiar más en el agente: consiste en que incluso un agente confundido tenga poco que puede romper. El hub de seguridad, coste y operación agrupa esta guía con las de fugas de datos y observabilidad; y si aún no tienes el runtime montado, el curso gratuito deja un agente funcionando para practicar la matriz de verificación en un proyecto de prueba.