Seguridad de OpenAI Codex: riesgos, controles y buenas prácticas

¿Qué es OpenAI Codex y por qué cambia el modelo de seguridad?

OpenAI Codex es la herramienta de programación agéntica de OpenAI. Funciona allá donde el desarrollador ya trabaja: una CLI de Codex en la terminal, una extensión de IDE, un modo en la nube y multiagente que ejecuta tareas de forma asíncrona, y un SDK para conectar Codex a tu propia automatización. Actúa sobre instrucciones en lenguaje natural: analiza una base de código, genera una funcionalidad, ejecuta las pruebas, arregla los fallos, abre un pull request. Se conecta a GitHub, corre junto a sistemas de compilación y puede apuntarse a un repositorio y dejarse trabajando.

Primero una aclaración de nombres, porque hace tropezar a casi todos los que buscan este tema. "Codex" en este artículo significa el agente de código (CLI, extensión de IDE, nube y SDK). Por separado, OpenAI lanzó una función llamada literalmente Codex Security: un agente que se conecta a un repositorio, construye un modelo de amenazas específico de la base de código, escanea el historial de commits, valida vulnerabilidades candidatas en un entorno aislado y propone arreglos para revisión humana. Las dos son fáciles de confundir. Esta guía trata de asegurar el agente de código Codex. Codex Security, la propia capacidad de OpenAI para encontrar vulnerabilidades, se cubre brevemente más abajo como una entrada asistencial, no como un programa de seguridad completo.

Esa propiedad agéntica es la que rompe el viejo modelo de seguridad. Un asistente de IDE tradicional sugiere completados; una persona acepta o rechaza cada uno. El radio de impacto de una mala sugerencia es un bloque de código que un desarrollador todavía tiene que pegar. Codex, en cambio, ejecuta acciones. Lee archivos que no nombraste, ejecuta comandos que no escribiste, edita código por todo el árbol y, en modo nube, puede correr durante mucho tiempo sin que nadie mire. La superficie de ataque ya no es "qué código sugirió el modelo". Es "qué puede hacer este agente con el acceso que tiene, y quién puede influir en sus instrucciones".

“

Una sugerencia es un borrador que una persona elige aceptar. Una acción es algo que ya ocurrió. El modelo de seguridad tiene que pasar de revisar borradores a restringir acciones.

Hay un segundo cambio que importa aún más, y tiene que ver con la velocidad. El pull request se convirtió en el hogar de la seguridad de las aplicaciones porque operaba a ritmo humano: una persona bajaba el ritmo, leía el diff y solo entonces fusionaba. Codex, especialmente en modo nube y multiagente, no corre a ritmo humano. Una sola sesión puede entregar más código en una tarde del que un revisor lee en una semana. Cuando eso ocurre, el diff deja de ser un punto de control y se convierte en una transcripción de decisiones ya tomadas. Cualquier control que solo actúe en el pull request ahora revisa historia, no la previene.

Para la mayoría de los equipos la pregunta práctica no es si Codex tiene protecciones nativas. Las tiene, y están diseñadas con sensatez. La pregunta es si esas protecciones bastan para el uso diario. La respuesta honesta es no. La propia guía "Running Codex safely" de OpenAI enmarca el entorno aislado y las aprobaciones como defensa en profundidad, no como una frontera completa, y en el momento en que cambias al modo full-access o habilitas el acceso a red en el sandbox, esas barreras de seguridad se quitan por diseño. Una adopción segura sigue dependiendo de los permisos, la disciplina con el entorno aislado, la supervisión humana y la validación independiente sobre el código, las dependencias y los pipelines.

Cómo funciona el modelo de seguridad de Codex

El modelo de Codex se construye sobre tres ideas: ejecutar el trabajo dentro de un entorno aislado, preguntar antes de hacer cualquier cosa que escape de él y mantener la red cerrada salvo que la abras. En la práctica eso se manifiesta en un puñado de controles.

Es una base genuinamente cuidada, y la mayor parte de esta lista no existía en los asistentes de IDE de hace una generación. La trampa es leerla como una frontera de seguridad terminada. OpenAI es explícito en que el modo auto es un punto intermedio más que una garantía, que full-access y el flag --dangerously-bypass-approvals-and-sandbox eliminan el sandbox a propósito, y que habilitar el acceso a red dentro del sandbox es un intercambio deliberado de seguridad por capacidad. Cada control de esta lista tiene una forma documentada de desactivarse, y la siguiente sección trata de lo que ocurre cuando lo haces, o cuando un atacante lo hace por ti.

Los 6 principales riesgos de seguridad en OpenAI Codex

Los riesgos siguientes no son teóricos. Se corresponden con vulnerabilidades documentadas, investigación publicada y el OWASP Top 10 para Aplicaciones LLM. Las cifras que los enmarcan son las mismas que ahora cita todo equipo de AppSec.

1. Inyección de comandos y ejecución remota de código

Codex escribe y ejecuta código a nivel de sistema, así que un fallo en cómo maneja sus propias entradas se convierte en una ruta hacia la ejecución de código. Esto no es hipotético. BeyondTrust Phantom Labs divulgó una vulnerabilidad crítica de inyección de comandos en OpenAI Codex que permitía el robo de GitHub User Access Tokens, con la carga colada a través de un nombre de rama de GitHub y oculta de la interfaz mediante caracteres Unicode invisibles. Como vivía en la petición de creación de tarea, afectaba a la vez al sitio web de ChatGPT, la CLI de Codex, el SDK de Codex y la extensión de IDE de Codex.

OpenAI lo remedió (un hotfix inicial en la semana posterior al informe de diciembre de 2025, protecciones de shell más fuertes y alcance de token reducido a principios de 2026, finalmente clasificado como Critical Priority 1), así que este bug concreto está cerrado. Sigue siendo la ilustración más clara de la superficie: un agente que ejecuta comandos de shell en tu nombre convierte cualquier entrada sin sanear que lee, un nombre de rama, un nombre de archivo, una respuesta de herramienta, en un posible punto de inyección. El peligro se agrava cuando el agente corre con acceso de shell amplio y un modo permisivo, porque una cadena de comandos individualmente inofensivos puede instalar una dependencia, alterar una configuración de CI o abrir un mecanismo de persistencia.

2. Cadena de suministro y dependencias maliciosas

Codex instala paquetes, clona repositorios y ejecuta scripts de configuración como parte del trabajo normal, y su propia popularidad lo ha vuelto un objetivo. TechRadar y otros medios informaron de un paquete npm, codexui-android, que se hacía pasar por una UI remota para Codex, atrajo unas 29.000 descargas y, tras un lanzamiento inicial limpio, empujó una actualización que exfiltraba silenciosamente el contenido del archivo de credenciales de Codex (~/.codex/auth.json), tokens de acceso, de refresco y de ID, a un servidor controlado por el atacante. Como el token de refresco no caduca, una sola instalación comprometida puede conceder acceso persistente y silencioso.

Ese incidente se inscribe en un patrón más amplio. A lo largo de 2025 y entrando en 2026, las campañas de typosquatting y de imitación en npm apuntaron cada vez más a las herramientas de programación con IA y a sus ecosistemas. El propio flujo de desarrollo se convierte en el vector de ataque: un package.json envenenado, un hook post-install malicioso o un helper con typosquatting pueden convertir un prompt rutinario de "configura este repo" en un robo de credenciales. La alucinación de paquetes lo agrava: un agente que inventa con confianza un nombre de paquete plausible pero inexistente entrega a un atacante un hueco para registrarlo y convertirlo en arma.

3. Inyección de prompts y escritura de exploits dirigida

La inyección de prompts es el riesgo definitorio de las herramientas de programación agénticas, y es el riesgo LLM número uno de OWASP por tercer año consecutivo (LLM01). Un atacante esconde instrucciones en algo que el agente lee, un archivo, una página web, una incidencia, el README de una dependencia, la salida de una herramienta, y el agente las sigue, anulando su comportamiento previsto.

El contexto agéntico empeora el resultado, porque Codex no solo responde; actúa y escribe código a nivel de sistema. Un agente dirigido puede ser empujado a escribir un exploit, debilitar una comprobación de autorización, añadir una ruta de deserialización insegura o conectar una puerta trasera que parece correcta a un revisor cansado. La forma peligrosa es la indirecta: no tienes que pegar un prompt malicioso, solo tienes que apuntar Codex a un repositorio envenenado o dejar que consuma una salida de herramienta hostil. Como un modelo de lenguaje no puede separar de forma fiable una instrucción de confianza de una maliciosa incrustada en datos, la inyección puede llevar a ejecución de comandos, exfiltración de datos o manipulación silenciosa de código.

4. Modos de sandbox y de aprobación demasiado permisivos

La seguridad de Codex descansa en su sandbox y en sus avisos de aprobación, y ambos pueden rebajarse con un solo flag. Elegir full-access (danger-full-access), o habilitar el acceso de red saliente dentro del sandbox workspace-write, cambia la barrera de seguridad por capacidad, y OpenAI lo dice sin rodeos. Con el sandbox abierto y la red alcanzable, el mismo agente que estaba contenido hace un momento puede ahora escribir fuera del espacio de trabajo y enviar datos a cualquier parte.

El mecanismo que erosiona esto en la práctica es la fatiga de aprobaciones. Cuando el agente se detiene repetidamente, la gente recurre a --ask-for-approval never, o al preset full-auto, para quitarse los avisos de encima. En una semana el cuidadoso valor por defecto se ha convertido silenciosamente en una concesión general, y nadie decidió que fuera así. La versión a nivel de equipo es peor: un desarrollador corre en read-only, otro corre en full-access porque iba más rápido un viernes, y en el momento en que comparten un repositorio o un flujo de trabajo automatizado, la configuración más débil fija la postura real para todos.

5. Retención de datos y privacidad

Codex es útil porque tiene contexto, y ese contexto rutinariamente incluye más que el archivo que tienes delante: código adyacente, configuración, variables de entorno y a veces credenciales. Los agentes generan y transmiten grandes cantidades de código privado en serie, prompt tras prompt, tarea tras tarea. Para bases de código sensibles o reguladas, la pregunta correcta no es solo "¿está cifrada la conexión?", sino "¿qué se almacena, durante cuánto tiempo, dónde y quién puede alcanzarlo?".

La exposición suele ser indirecta más que dramática. Al resumir un repositorio o depurar un error, el agente puede sacar a la luz un token o un endpoint interno en una salida que luego acaba en un pull request, un ticket o un chat, donde sobrevive mucho después de que termine la sesión. Las organizaciones que adoptan Codex a escala deberían revisar los términos de manejo y retención de datos de OpenAI para la superficie que usan (la API, los niveles business y enterprise difieren), mantener los secretos y los datos regulados fuera del alcance del agente y tratar todo lo que el agente emite como potencialmente registrado.

6. Autonomía a escala

La capacidad que hace atractivo a Codex, ejecuta una tarea y vuelve a un pull request terminado, es también la que ensancha la brecha de revisión. En modo nube y multiagente, Codex puede hacer cambios grandes y barriendo muchos archivos con poca atención humana entre medias. Cuanto más autónoma y de mayor duración es la tarea, más grande es el diff, y menor la fracción de él que una persona realmente lee antes de aprobarlo.

Eso importa para la seguridad porque la ventana para que un cambio inseguro o malicioso aterrice crece con el tamaño del diff sin leer. Una regresión sutil de autorización, una dependencia inyectada o una validación silenciosamente debilitada son mucho más fáciles de pasar por alto en un cambio autónomo de 2.000 líneas que en uno de 20 que un desarrollador escribió deliberadamente. La autonomía no crea nuevas clases de vulnerabilidad tanto como elimina la fricción natural que solía atraparlas, que es precisamente por lo que los controles de abajo se apoyan tanto en la revisión, el acotamiento y el gobierno en el momento del prompt.

Qué cubre la seguridad nativa de Codex y qué no

Los controles nativos son reales, y conviene ser preciso sobre la línea entre lo que gestionan y lo que te dejan a ti.

Lee la columna de la derecha como el trabajo real. Los controles nativos son el suelo: el sandbox y el valor por defecto de red evitan que un error honesto, o un solo comando dirigido, se convierta en un desastre a escala de toda la máquina. No se diseñaron para frenar a un adversario decidido que controla las entradas del agente, y OpenAI no afirma que lo hicieran. Todo lo que convierte "Codex está instalado" en "Codex está gobernado" vive en las prácticas que siguen.

Buenas prácticas para asegurar OpenAI Codex

Estas nueve prácticas cierran la brecha entre la base nativa y una postura de seguridad real. Ninguna es exótica; la disciplina está en aplicarlas de forma consistente en un equipo que se mueve rápido.

1. Mantén el sandbox activado y full-access desactivado. Usa por defecto read-only para explorar y auto (workspace-write) para el trabajo real, y trata full-access (danger-full-access) y --dangerously-bypass-approvals-and-sandbox como exclusivos de contenedores desechables. Confirma que el sandbox del SO está realmente activado en cada plataforma en la que corres, y nunca lo desactives en una máquina que pueda alcanzar credenciales reales o hosts de producción.

2. Deja la red cerrada salvo que una tarea la necesite de verdad. El valor por defecto de la nube, sin acceso saliente, es la barrera de seguridad más valiosa que trae Codex, porque la exfiltración suele necesitar la red. Habilita el acceso a red en el sandbox workspace-write solo para la tarea concreta que lo requiere, acótalo a destinos conocidos donde puedas y vuelve a desactivarlo después en lugar de dejarlo abierto por costumbre.

3. Aplica privilegio mínimo a repositorios y tokens. Da a Codex acceso solo a los repositorios que una tarea necesita, prefiere tokens de GitHub de corta vida y de alcance estrecho frente a los amplios y persistentes, y rótalos según un calendario en lugar de esperar a un incidente. La divulgación de BeyondTrust es un recordatorio de que un solo token de GitHub filtrado puede alcanzar todos los repositorios para los que se concedió, así que el alcance del token es el alcance de la brecha.

4. Gobierna dependencias y paquetes. Restringe las instalaciones a registros de confianza o espejos internos, exige aprobación para paquetes nuevos y analiza todo con análisis de composición de software. No dejes que el agente instale automáticamente paquetes oscuros o no verificados por mucha confianza con la que los sugiera, verifica que un paquete sugerido existe realmente antes de añadirlo y desconfía especialmente de las herramientas helper que envuelven al propio Codex, que es exactamente donde vivía el roba-tokens codexui-android.

5. Mantén a una persona en el bucle sobre el código generado. Trata la salida de Codex como un borrador, no como una implementación final, y dimensiona la revisión al tamaño del cambio. Encamina el código generado y modificado por revisión de pull request y pruebas automatizadas, con escrutinio extra en autenticación, validación de entradas y rutas con privilegios. El objetivo no es desconfiar del modelo; es que un agente que produce miles de líneas al día, especialmente en modo nube, producirá fallos sutiles más rápido de lo que afloran por sí solos.

6. Ejecuta el trabajo no confiable en aislamiento. Cuando apuntes Codex a un repositorio desconocido, una incidencia de terceros o cualquier cosa que no escribiste tú, ejecútalo en un contenedor o VM sin secretos del host montados y sin ruta a producción. La inyección de prompts indirecta llega exactamente a través de este tipo de contenido, así que la defensa más barata es asegurarte de que un agente dirigido no tenga nada valioso al alcance.

7. Gestiona los secretos fuera de alcance. Mantén los secretos en texto plano completamente fuera del contexto del agente: usa una bóveda e inyéctalos en tiempo de ejecución, redacta los valores sensibles en los registros y no dejes que el agente lea archivos de credenciales o contenidos de .env que no necesita. Protege el propio archivo de credenciales de Codex (~/.codex/auth.json) como el objetivo de alto valor que es, y si un secreto aparece alguna vez en una transcripción o una salida, rótalo de inmediato e investiga cómo llegó ahí.

8. Restringe la autonomía en modo nube y multiagente. Acota estrechamente las tareas de larga duración y asíncronas, prefiere varios cambios revisables en lugar de uno barriendo, y exige aprobación humana antes de que una rama autorada por Codex se fusione en algo protegido. Cuanto más grande es el diff autónomo, más deliberada tiene que ser la revisión, así que fija expectativas (y reglas de protección de ramas) acordes al volumen que Codex puede producir.

9. Fija la política por sensibilidad de repositorio y entorno. Clasifica los repositorios (público, interno, regulado, producción) y aplica controles más estrictos a los sensibles: modos read-only o estrechamente acotados, red cerrada, niega el acceso a secretos, exige una revisión más fuerte. Ejecuta Codex contra sistemas críticos solo en entornos sin ruta directa a credenciales de producción, y documenta la política para que los desarrolladores sepan dónde se permite la ayuda de IA y bajo qué restricciones. Usa Codex Security y el SAST tradicional como entradas asistenciales a esa revisión, no como un sustituto de ella.

Donde se detienen los controles nativos: asegurar al agente en el momento del prompt

Recorre de nuevo los riesgos y emerge un patrón. El sandbox, los modos de aprobación y el paso de revisión actúan todos sobre lo que el agente ya ha decidido hacer, o sobre código que ya ha escrito. Se agrupan alrededor del pull request, porque ahí ha vivido siempre la AppSec. Pero el PR solo fue un punto de control porque una persona lo leía, y a ritmo de agente, especialmente en modo nube, ya nadie lo lee de principio a fin.

El lugar para aplicar una regla ya no es el diff; es el prompt, antes de que se escriba la línea insegura. Cualquier regla que quieras que el agente siga tiene que estar en sus manos en el momento en que escribe, no esperando en un escáner que llega una vez que el código está en disco y el agente ha pasado a la siguiente tarea.

Esa es la capa que añade VibeDefend. Es una CLI de npm gratuita que se instala en unos cinco segundos y conecta OpenAI Codex (además de Claude Code, Cursor, Windsurf y VS Code Copilot) en cuatro capas de gobierno que corren dentro del bucle del agente.

Reglas de negocio Las convenciones de tu repo que nunca se escribieron (usa Decimal128 para el dinero, la autorización pasa por requireOwner). VibeDefend las extrae de cómo tu equipo ya programa y las carga en el contexto del agente antes de cada edición. Reglas de seguridad OWASP Top 10, SOC 2, RGPD e ISO 27001, cargadas el día que instalas. El agente lee el recordatorio aplicable antes de escribir, así el requisito del marco se vuelve parte del código en lugar de una casilla a marcar en auditoría. Action Guard Las llamadas destructivas (un sudo rm -rf, una lectura cruda de una variable de entorno con forma de secreto, un psql improvisado contra un host de producción) se interceptan antes de dispararse. Advierte o bloquea según la regla, con cada intercepción en el registro de auditoría. Live Findings Cada resultado de sus escáneres de CybeDefend (SAST con alcanzabilidad, SCA, secretos, IaC y CI/CD) está en vivo en el contexto del agente, así que no solo escribe código seguro, también tría y arregla las vulnerabilidades que ya tienes.

Es importante destacar que nada de tu código cruza la red. Las decisiones ocurren localmente, junto al agente; solo metadatos de gobierno estructurados (la regla que se disparó, la ruta del archivo, la severidad, una marca de tiempo) llegan al backend. Los tenants de EU y US están físicamente separados, y eliges la región en el momento de la instalación. Ese modelo de privacidad es lo que permite que un control se sitúe tan cerca del código sin convertirse, por sí mismo, en un riesgo de exfiltración de datos, lo que importa aún más para un agente cuyo propio archivo de credenciales ya ha sido objetivo de robo.

Esto no es un reemplazo de las prácticas anteriores. Es la capa que falta y que ellas dan por hecha: la que pone tus reglas en las manos del agente en el momento del prompt, para que la línea insegura se reescriba antes de siquiera sugerirse, en lugar de atraparse tres etapas después por un escáner que lee un diff que nadie tuvo tiempo de leer. El sandbox impide que el agente haga lo que no debe; VibeDefend moldea lo que escribe, de entrada.

Preguntas frecuentes

¿Es seguro OpenAI Codex?

OpenAI Codex es seguro de usar cuando está en un entorno aislado y acotado, y arriesgado cuando no lo está. Su sandbox a nivel del sistema operativo, sus modos de aprobación escalonados y su comportamiento de red desactivada por defecto en la nube previenen una gran clase de accidentes y contienen la mayoría de los comandos perdidos. El riesgo residual viene de la configuración (modo full-access, red habilitada, aprobaciones desactivadas), de las entradas (inyección de prompts, repositorios y paquetes maliciosos) y de la autonomía a escala (grandes cambios en la nube que quedan poco revisados). Trátalo como un agente poderoso que necesita privilegio mínimo, aislamiento y revisión humana, no como una herramienta segura nada más sacarla de la caja.

¿Cuál es la diferencia entre Codex y "Codex Security"?

Son dos cosas distintas de OpenAI que comparten un nombre. Codex es la herramienta de programación agéntica: la CLI, la extensión de IDE, el modo nube y el SDK que leen tu repo, editan archivos, ejecutan comandos y abren pull requests. Codex Security es un agente separado para encontrar vulnerabilidades que se conecta a un repositorio, construye un modelo de amenazas, escanea el historial de commits, valida problemas candidatos en aislamiento y propone arreglos para revisión humana. Esta guía trata de asegurar el agente de código Codex. Codex Security es una entrada asistencial a la revisión de código, útil como un par de ojos extra, no un programa de seguridad completo.

¿Codex ejecuta el código en un sandbox?

Sí. Codex ejecuta comandos dentro de un sandbox del sistema operativo: Seatbelt en macOS, Landlock y seccomp en Linux, y un sandbox dedicado en Windows. Por defecto, las escrituras se limitan al espacio de trabajo activo y, en el entorno de nube, el acceso de red saliente está desactivado. Esos valores por defecto son el núcleo de su modelo de seguridad. Pueden rebajarse deliberadamente con full-access (danger-full-access) o habilitando el acceso a red dentro del sandbox workspace-write, y OpenAI es explícito en que hacerlo elimina la protección a propósito.

¿Puede Codex filtrar mi token de GitHub o mis credenciales?

Puede si no tienes cuidado, y hay precedente. BeyondTrust Phantom Labs divulgó una vulnerabilidad de inyección de comandos que dejaba a los atacantes robar GitHub User Access Tokens mediante un nombre de rama cuidadosamente diseñado a través del sitio web de ChatGPT, la CLI de Codex, el SDK y la extensión de IDE; OpenAI lo ha remediado desde entonces. Por separado, un paquete npm malicioso que se hacía pasar por un helper de Codex exfiltró el archivo de credenciales de Codex (~/.codex/auth.json) de unas 29.000 instalaciones. Defiende el token acotándolo de forma estrecha, rotándolo, examinando cualquier herramienta helper y protegiendo el archivo de credenciales como un secreto de alto valor.

¿Codex envía mi código a OpenAI?

Codex envía el contexto que necesita a los modelos de OpenAI para generar respuestas, lo que puede incluir código, contenidos de archivos y el contexto circundante de tu tarea. Qué se almacena y durante cuánto tiempo depende de la superficie que uses y de tu nivel (los términos de la API, business y enterprise difieren en retención y entrenamiento). Para código sensible, elige un nivel y una configuración que se ajusten a tus requisitos de manejo de datos, mantén los secretos y los datos regulados fuera del alcance del agente y revisa las políticas de retención. Los metadatos de gobierno de una capa añadida como VibeDefend se mantienen separados y no transmiten código fuente.

¿Qué modo de sandbox/aprobación de Codex debería usar?

Para la mayoría del trabajo, read-only para explorar y auto (el sandbox workspace-write con aprobación bajo petición) para hacer cambios, con la red dejada cerrada. Reserva full-access (danger-full-access) y --dangerously-bypass-approvals-and-sandbox para contenedores desechables sin credenciales reales, y evita --ask-for-approval never en cualquier máquina que pueda alcanzar producción o secretos. Ajusta el modo a la sensibilidad del repositorio: cuanto más crítico es el sistema, más ajustado el sandbox, más aprobación y menos red debería tener el agente.

¿En qué se diferencia la seguridad de Codex de Claude Code, Cursor o GitHub Copilot?

Los fundamentos son compartidos (privilegio mínimo, gestión de secretos, revisión humana, análisis de dependencias), pero las superficies difieren. Las superficies distintivas de Codex son su sandbox del SO más la vía de escape full-access, sus incidentes de inyección de comandos y de cadena de suministro en npm, y la brecha de revisión del modo nube autónomo. Claude Code se apoya en la profunda integración con MCP y el shell; Cursor ha tenido Workspace Trust desactivado por defecto; GitHub Copilot ha lidiado con sugerencias inseguras y fuga de secretos a escala. Cubrimos cada agente en su propia guía.