s 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
Publicado originalmente en devaisemanal.com.
