OpenAI detalla las protecciones de Codex: sandboxes, aprobaciones y auditoría de las acciones del agente
OpenAI mostró cómo ejecuta Codex internamente sin confiar plenamente en el agente. Para ello usa sandboxes, aprobaciones para acciones fuera de los límites, pol

El 8 de mayo de 2026, OpenAI explicó cómo restringe Codex dentro de sus flujos de trabajo. La idea es simple: un agente de código debe acelerar el desarrollo, pero no obtener acceso incontrolado a archivos, redes e infraestructura.
Límites para Codex
La primera capa de protección es la sandbox. Establece límites técnicos: dónde Codex puede escribir, qué directorios están abiertos para escritura, si se permite el acceso a la red y qué rutas permanecen protegidas. Encima de esto, funciona una política de aprobación. Si un agente necesita hacer algo fuera del entorno permitido, debe solicitar confirmación. Un usuario puede aprobar una acción específica única u otorgar permiso para ese tipo de acción durante el resto de la sesión. Esto reduce el riesgo de operaciones accidentales y opacas.
Aparte, OpenAI utiliza un modo Auto-review. Cuando Codex está a punto de cruzar un límite de sandbox, pasa el plan de acción y el contexto reciente a un subagente de auto-aprobación separado. Ese agente puede permitir automáticamente solicitudes de bajo riesgo y, en algunos casos, incluso las más sensibles, si el usuario ya tiene un nivel de autorización suficiente. Como resultado, las tareas rutinarias no ralentizan el trabajo, mientras que las acciones potencialmente peligrosas siguen siendo detenidas en la etapa de revisión.
"Mantener un agente dentro de límites técnicos claros, acelerar acciones de bajo riesgo y destacar explícitamente las de riesgo" — así es como
OpenAI describe el objetivo de este esquema.
Red, Acceso y Reglas
La segunda capa es la gestión de acceso. OpenAI no otorga a Codex acceso saliente libre a Internet: la política de red permite destinos esperados, bloquea indeseables y requiere aprobación para dominios desconocidos. Incluso la búsqueda y búsqueda web pueden estar restringidas a respuestas en caché. Las credenciales de CLI y MCP OAuth se almacenan en el llavero del sistema, el inicio de sesión es obligatorio a través de ChatGPT, y el acceso está vinculado a un espacio de trabajo empresarial específico. Esto garantiza que la actividad del agente permanezca dentro de los límites de control corporativo.
- Modos de sandbox permitidos — solo read-only y workspace-write
- La escritura se habilita automáticamente solo en directorios de trabajo pre-conocidos
- Para la red, puede habilitar un proxy, permitir localhost y bloquear dominios específicos
- Las direcciones conocidas como *.openai.com pueden pasar sin aprobación manual
- Los requisitos administrativos no se pueden desactivar del lado del usuario
También hay reglas separadas para comandos shell. Codex no considera todos los comandos igualmente seguros: las operaciones estándar de solo lectura pueden omitirse sin confirmación incluso fuera de la sandbox, mientras que los patrones peligrosos se bloquean o se envían para revisión. En el ejemplo de OpenAI, permiten sin preguntas adicionales leer solicitudes de extracción a través de gh pr view y list, así como diagnósticos de Kubernetes a través de kubectl get, describe y logs. La empresa implementa la política de base a través de configs administrados y requisitos, por lo que el mismo marco de control opera en la aplicación de escritorio, CLI y extensión IDE.
Logs con Explicación
OpenAI enfatiza por separado que las restricciones por sí solas son insuficientes. Los logs de seguridad estándar muestran bien qué sucedió: se inició un proceso, cambió un archivo, hubo un intento de conexión de red. Pero es difícil reconstruir la intención del agente y el usuario a partir de ellos.
Por lo tanto, Codex puede exportar logs de OpenTelemetry con contexto de agente más enriquecido: solicitudes originales del usuario, decisiones de aprobación, resultados de llamadas de herramientas, uso de servidores MCP y eventos de proxy de red — qué fue permitido y qué fue bloqueado. Para clientes Enterprise y Edu, esta actividad también está disponible a través de la Plataforma de Logs de Cumplimiento, y los logs pueden centralizarse en SIEM y sistemas de cumplimiento.
Dentro de OpenAI, estos datos los utiliza un agente IA para triaje de seguridad. Cuando la protección de endpoint reporta comportamiento extraño de Codex, el equipo de seguridad no solo mira la alerta en sí, sino también los logs acompañantes: cuál fue la solicitud original, qué herramientas se iniciaron, qué intentó hacer el agente, qué decisiones tomó la red y dónde se requirió aprobación. Esto ayuda a distinguir más rápidamente el comportamiento esperado de un error inofensivo y de un caso que realmente requiere escalación. Los mismos logs también se utilizan operacionalmente — para entender cómo está creciendo el uso interno de Codex, qué herramientas están en demanda y dónde la política aún necesita ajustes.
Lo Que Esto Significa
OpenAI está esencialmente demostrando un modelo corporativo para agentes de código: no un modelo inteligente en lugar de controles, sino un modelo dentro de un entorno rigurosamente configurado con auditoría y reglas. Para empresas que buscan implementar tales asistentes, esto es una señal de que la principal pregunta de producto ahora no es solo sobre la calidad del modelo, sino también sobre qué tan bien se ajusta a la seguridad, el cumplimiento y los procesos internos.