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.
El problema no es internet, es internet sin límites
El riesgo principal no es que el agente se vuelva malicioso. Es que obedezca instrucciones externas que no debería obedecer: un issue manipulado, una página con prompt injection, un README de dependencia, un script pegado en una conversación o un dominio que intenta recibir datos del repo.
La configuración madura de Codex no consiste en permitir todo o bloquear todo. Consiste en separar fases, limitar destinos, exigir aprobación para acciones sensibles y conservar trazabilidad suficiente para explicar qué hizo el agente y por qué.
Modelo mental: tres capas de control
La primera capa es el sandbox. Define qué puede tocar el agente en el sistema de archivos, qué comandos puede ejecutar y cuánto daño puede causar si una instrucción sale mal.
La segunda capa es la red. Define si el agente puede salir a internet durante la fase de trabajo, a qué dominios puede conectarse y con qué métodos HTTP. En Codex cloud, OpenAI documenta que el acceso a internet del agente está bloqueado por defecto y se habilita por entorno cuando hace falta.
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.
Qué permitir por defecto
Permite instalaciones de dependencias en la fase de setup cuando el entorno lo necesita, pero evita que el agente use red abierta durante toda la tarea si no aporta valor.
Autoriza dominios concretos: registros de paquetes, documentación oficial, APIs internas de lectura y repositorios controlados. Evita el comodín de internet completo salvo en sandboxes de investigación sin secretos y con repos desechables.
Empieza con métodos HTTP restrictivos. Muchas tareas solo necesitan GET o HEAD para leer documentación o descargar dependencias. POST, PUT, PATCH y DELETE deberían tener una justificación clara.
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.
Dónde encajan MCP y herramientas externas
MCP amplía lo que el agente puede hacer: leer sistemas internos, consultar tickets, abrir herramientas de observabilidad o interactuar con servicios corporativos. Eso no es malo, pero convierte cada servidor MCP en parte de la superficie de seguridad.
Un servidor MCP debería tener permisos mínimos, scopes claros, logs y separación por entorno. No mezcles herramientas de lectura inocuas con herramientas que pueden escribir en producción bajo el mismo nivel de aprobación.
Si un agente tiene red y MCP a la vez, revisa el flujo completo: puede leer contexto por MCP, procesarlo y después intentar enviarlo a una URL externa. Las políticas deben pensar en cadenas de acciones, no solo en permisos aislados.
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.
Durante las primeras semanas, mide bloqueos de red, solicitudes de aprobación, comandos fallidos, PRs aceptados y revisiones humanas que encontraron problemas reales. Esa telemetría te dirá si tus límites son demasiado estrictos o demasiado abiertos.
Cuando el flujo sea estable, amplía por tipo de tarea, no por entusiasmo. Dar internet a todos los agentes en todos los repos porque una demo salió bien es una mala estrategia de adopción.
Conclusión
Codex con internet puede ser mucho más útil que un agente aislado, especialmente para tareas que dependen de documentación actual, dependencias, issues o APIs. Pero esa utilidad solo compensa si el entorno está diseñado para fallar de forma controlada.
La configuración mínima seria combina sandbox, allowlists, aprobaciones, AGENTS.md, logging y revisión humana. Si falta una de esas piezas, el agente puede seguir siendo productivo, pero la organización pierde capacidad de explicar y contener sus acciones.
Fuentes y referencias
- OpenAI: Running Codex safely
- OpenAI Codex: agent internet access
- OpenAI Codex web
- OpenAI: Introducing upgrades to Codex
- OpenAI: Introducing Codex
- OpenAI Help: Codex with ChatGPT plan
Publicado originalmente en devaisemanal.com.
Top comments (0)