Codex con acceso a internet: cómo configurar sandbox, permisos y auditoría sin abrir demasiado el repo

Dar internet a un agente de código puede desbloquear tareas reales, pero también abre riesgos de prompt injection, exfiltración y dependencias no confiables.

Un agente de código sin red puede leer, modificar y probar dentro de un entorno acotado. En cuanto le das internet, puede instalar dependencias, consultar documentación, abrir issues, llamar APIs y resolver tareas que antes exigían intervención humana. Ese salto es útil, pero cambia el modelo de amenaza.

La tercera capa es la aprobación humana. Algunas acciones no deberían depender solo de una allowlist: publicar paquetes, tocar secretos, ejecutar migraciones, enviar datos externos, cambiar infraestructura o abrir un PR con impacto de seguridad.

Riesgos que debes diseñar explícitamente

• Prompt injection: contenido externo que intenta cambiar la tarea, revelar secretos o ejecutar comandos no relacionados.
• Exfiltración: envío accidental de código, variables de entorno, tokens, logs o fragmentos de commits a dominios no confiables.
• Supply chain: descarga de dependencias vulnerables, typosquatting, scripts de instalación agresivos o paquetes con licencias incompatibles.
• Persistencia involuntaria: cambios en configuración, credenciales, workflows o scripts que sobreviven al sandbox y acaban en el repo.
• Falsa confianza: aceptar un PR porque el agente muestra tests verdes sin revisar qué comandos ejecutó, qué red usó y qué archivos modificó.

Checklist de configuración para equipos

• Define entornos separados para tareas normales, tareas con red y tareas de alto riesgo.
• Mantén secretos fuera del entorno del agente salvo que sean imprescindibles y de alcance mínimo.
• Usa allowlists de dominios en lugar de internet abierto.
• Exige aprobación para comandos destructivos, cambios de infraestructura, publicación y operaciones con datos sensibles.
• Registra prompts, decisiones de aprobación, comandos, resultados, uso de MCP y decisiones de red.
• Incluye instrucciones del repo en AGENTS.md para que el agente sepa qué tests correr y qué rutas no tocar.
• Revisa diffs como revisarías el trabajo de una persona nueva: intención, cobertura de tests, impacto y rollback.

Un rollout razonable

Empieza con repos internos de bajo riesgo y tareas acotadas: actualizar documentación, mejorar tests, corregir bugs pequeños o preparar refactors sin merge automático.