OpenAI te enseña cómo usar Codex de manera segura: límites del sandbox, aprobación automática, clasificación de seguridad, marco completo de implementación empresarial

OpenAI revela cómo despliega de manera segura su propio código de IA, el agente Codex, en entornos internos, con una estrategia central de “límites en la sandbox + aprobación automática de comportamientos de bajo riesgo + clasificación de seguridad de IA mediante un proxy de alertas”, permitiendo que la eficiencia en desarrollo y el control de seguridad empresarial funcionen en conjunto.
(Resumen previo: Gran actualización de OpenAI Codex: control en backend en Mac, navegador incorporado, generación de imágenes, lanzamiento de 111 nuevos plugins)
(Información adicional: ¡OpenAI lanza un nuevo proxy para ingenieros, Codex! Funciones de escritura de IA, corrección de bugs, ejecución de pruebas)

Índice de este artículo

Alternar

• Definición de límites en la sandbox, mecanismo de aprobación que decide cuándo detenerse
• Qué comandos están exentos de aprobación, cuáles se bloquean directamente
• Proxy de clasificación de seguridad de IA

OpenAI publicó esta semana un informe interno sobre despliegue en empresas, explicando cómo su equipo de seguridad opera Codex en entornos productivos. Es un registro práctico de operaciones, desde la configuración de la sandbox hasta la clasificación de alertas, revelando qué aspectos de control de seguridad son necesarios cuando una organización grande adopta un agente de IA.

Definición de límites en la sandbox, mecanismo de aprobación que decide cuándo detenerse

En un anuncio oficial, OpenAI señala que el principio fundamental para desplegar Codex es uno solo: mantener el agente dentro de límites técnicos claros, asegurando que comportamientos de bajo riesgo no interrumpan al usuario, mientras que comportamientos de alto riesgo deben detenerse para revisión humana.

Este principio se implementa mediante dos mecanismos complementarios: sandbox y estrategia de aprobación.

La sandbox define el espacio de ejecución de Codex, incluyendo rutas de escritura permitidas, si se permite conexión a internet externa, qué directorios del sistema están protegidos. Acciones fuera de la sandbox requieren pasar por un proceso de aprobación. Los usuarios pueden aprobar una operación específica de una vez, o autorizar que ese tipo de operación pase automáticamente durante toda la sesión.

Para tareas rutinarias, OpenAI habilitó un “modo de revisión automática”. Esta función envía las acciones planificadas por Codex junto con el contexto reciente a un “subproxy de aprobación automática”. Este subproxy evalúa si el riesgo es bajo y permite la acción sin interrumpir el flujo de trabajo; si detecta riesgo alto o potenciales consecuencias no previstas, escala a revisión humana.

La lógica de control de red funciona igual. Codex no tiene acceso abierto a conexiones externas; OpenAI mantiene una lista blanca de dominios necesarios para el flujo normal de trabajo de Codex. Los dominios fuera de la lista se bloquean por defecto, y si se detecta un dominio desconocido, se activa el proceso de aprobación.

La autenticación también forma parte del control. Las credenciales OAuth del CLI y MCP se almacenan en el llavero seguro del sistema operativo, y el inicio de sesión se realiza obligatoriamente a través del espacio de trabajo empresarial de ChatGPT, integrando las operaciones de Codex en la plataforma de logs de cumplimiento de ChatGPT Enterprise, para que el equipo de seguridad pueda consultarlas en conjunto.

Qué comandos están exentos de aprobación, cuáles se bloquean directamente

OpenAI no considera todos los comandos de shell iguales en riesgo, sino que ha establecido una jerarquía de reglas. Los comandos inofensivos comunes en desarrollo diario, pueden ejecutarse fuera de la sandbox sin aprobación. Los comandos de alto riesgo, en cambio, se bloquean directamente o requieren aprobación forzada.

Estas reglas se aplican mediante tres niveles superpuestos:

• Requisitos de gestión en la nube (ejecutados por administrador, no pueden ser sobreescritos por el usuario)
• Preferencias gestionadas en macOS
• Archivos de configuración local

Esta estructura permite a OpenAI mantener un estándar unificado en toda la organización, mientras prueba diferentes configuraciones según equipo, grupo de usuarios o entorno. La misma configuración se aplica a la aplicación de escritorio de Codex, CLI y extensiones en IDE, en todos los interfaces locales.

Este enfoque contrasta con estudios externos: se ha demostrado que el código generado por IA tiene un 57% más de vulnerabilidades de seguridad que el código escrito por humanos. Además, se reveló que GitHub Copilot tiene una vulnerabilidad grave CVSS 9.6 (CVE-2025-53773), que permite inyección de comandos remotos mediante prompts.

Estos datos muestran que, sin controles en capas, la exposición de las empresas a riesgos por código IA es mayor de lo esperado. La estrategia de OpenAI es gestionar esto en la configuración, no confiar en la capacidad de juicio del agente IA, haciendo que las reglas sean una realidad técnica, no solo una práctica operativa.

Proxy de clasificación de seguridad de IA

En su anuncio, OpenAI enfatiza que, por muy robusto que sea el control, siempre se necesita visibilidad tras el despliegue. Los logs tradicionales responden a “¿qué pasó?”, como qué programa se inició, qué archivos se modificaron, qué conexiones se intentaron. Pero lo que realmente quieren saber los equipos de seguridad es “¿por qué hizo esto Codex?” y “¿esto corresponde a la intención del usuario?”.

OpenAI habilitó logs con OpenTelemetry para Codex, que registran: prompts del usuario, decisiones de aprobación de herramientas, resultados de herramientas, uso de servidores MCP, eventos de permitidos o bloqueados en proxy de red. Los clientes empresariales y educativos pueden acceder a estos logs a través de la plataforma de cumplimiento de OpenAI.

Más importante aún, OpenAI integra estos logs en un “proxy de clasificación de seguridad de IA”. Cuando una herramienta de detección detecta comportamientos sospechosos en Codex y genera una alerta, este proxy automáticamente recupera los logs relacionados, reconstruye la solicitud original, actividades de herramientas, decisiones de aprobación, resultados y políticas de red, genera un informe analítico y lo envía al equipo de seguridad. Esto ayuda a determinar si la acción fue normal, un error inofensivo o un incidente que requiere atención.

Estos mismos datos de telemetría también se usan para análisis interno: seguimiento de tendencias de adopción, herramientas y servidores MCP más utilizados, frecuencia de bloqueos y disparos en sandbox de red, ajustes necesarios en despliegues. Los logs de OpenTelemetry se pueden integrar en sistemas SIEM y plataformas de cumplimiento.

Para organizaciones que aún evalúan la seguridad de los agentes IA, este informe funciona como una lista de referencia: si tu despliegue no cubre estos cuatro niveles, el riesgo puede estar allí.