OpenAI detalla cómo protege Codex: sandboxes, aprobaciones y auditoría de las acciones del agente

El 8 de mayo de 2026, OpenAI explicó cómo limita Codex dentro de sus propios flujos de trabajo. La idea es sencilla: un agente de código debe acelerar el desarrollo, pero no obtener acceso descontrolado a archivos, red e infraestructura.

Límites para Codex

La primera capa de protección es el sandbox. Define el marco técnico: dónde puede escribir Codex, qué directorios admiten escritura, si se permite el acceso a la red y qué rutas siguen protegidas.

Por encima funciona una política de aprobaciones. Si el agente necesita hacer algo fuera del entorno permitido, debe solicitar confirmación. El usuario puede aprobar una acción concreta o autorizar ese tipo de acciones hasta el final de la sesión. Esto reduce el riesgo de operaciones accidentales u opacas.

Además, OpenAI utiliza el modo Auto-review. Cuando Codex va a cruzar el límite del sandbox, envía el plan de la acción y el contexto reciente a un subagente de aprobación automática. Este puede dar luz verde de forma automática a las solicitudes de bajo riesgo y, en algunos casos, también a otras más sensibles si el usuario ya cuenta con un nivel de autorización suficiente. Así, las tareas rutinarias no frenan el trabajo, mientras que las acciones potencialmente peligrosas siguen deteniéndose para su revisión.

«Mantener al agente dentro de límites técnicos claros, agilizar las acciones de bajo riesgo y señalar explícitamente las arriesgadas»: así describe

OpenAI el objetivo de este esquema.

Red, accesos y reglas

La segunda capa es la gestión de accesos. OpenAI no concede a Codex acceso saliente libre a internet: la política de red permite los destinos esperados, bloquea los no deseados y exige aprobación para los dominios desconocidos. Incluso la búsqueda y el web fetch pueden limitarse a respuestas en caché.

Las credenciales de la CLI y de MCP OAuth se guardan en el keyring del sistema, el inicio de sesión se realiza obligatoriamente a través de ChatGPT y el acceso queda vinculado a un workspace enterprise concreto. El objetivo es que la actividad del agente permanezca dentro de los perímetros de control corporativos.

• Los únicos modos de sandbox permitidos son read-only y workspace-write
• Solo se habilitan automáticamente para escritura los directorios de trabajo conocidos de antemano
• En la red se puede activar un proxy, permitir localhost y bloquear dominios concretos
• Las direcciones conocidas, como *.openai.com, pueden pasar sin aprobación manual
• Los requisitos administrativos no se pueden desactivar desde el lado del usuario

También hay reglas específicas para los comandos de shell. Codex no considera todos los comandos igual de seguros: las operaciones read-only habituales pueden ejecutarse sin confirmación incluso fuera del sandbox, mientras que los patrones peligrosos pueden bloquearse o enviarse a revisión.

En el ejemplo de OpenAI, se permite sin más preguntas leer pull requests mediante gh pr view y list, así como diagnosticar Kubernetes con kubectl get, describe y logs. La compañía despliega la política base mediante managed configs y requirements, de modo que el mismo perímetro se aplica en la desktop app, la CLI y la IDE extension.

Registros con contexto

OpenAI subraya que las restricciones por sí solas no bastan. Los registros de seguridad convencionales muestran bien qué ha ocurrido: se lanzó un proceso, cambió un archivo, hubo un intento de conexión de red. Pero con ellos resulta difícil reconstruir la intención del agente y del usuario.

Por eso Codex puede exportar logs de OpenTelemetry con un contexto más propio del agente: las solicitudes originales del usuario, las decisiones sobre approvals, los resultados de las llamadas a herramientas, el uso de servidores MCP y los eventos del proxy de red, es decir, qué se permitió y qué se bloqueó. Para los clientes Enterprise y Edu, esta actividad también está disponible a través de Compliance Logs Platform, y los registros pueden centralizarse en sistemas SIEM y de compliance.

Dentro de OpenAI, estos datos los utiliza un agente de IA para el security triage. Si la protección de endpoints detecta una acción extraña de Codex, el equipo de seguridad no se limita a la alerta: revisa también los registros asociados para ver cuál fue la solicitud original, qué herramientas se ejecutaron, qué intentaba hacer el agente, qué decisiones tomó la red y dónde se requirió aprobación.

Esto ayuda a separar más rápido el comportamiento esperado de un error inofensivo y de un caso que realmente requiere escalado. Los mismos registros se usan también con fines operativos: para entender cómo crece el uso interno de Codex, qué herramientas tienen más demanda y dónde hay que ajustar todavía la política.

Qué significa

En la práctica, OpenAI está mostrando una plantilla corporativa para agentes de código: no un modelo inteligente en lugar de control, sino un modelo dentro de un entorno rigurosamente configurado, con auditoría y reglas. Para las empresas que quieren implantar este tipo de asistentes, es una señal de que la gran cuestión de producto ya no es solo la calidad del modelo, sino también lo bien que encaja en la seguridad, el compliance y los procesos internos.