OpenAI ha dedicado gran parte de 2026 a introducir la IA más profundamente en la seguridad del software.
En marzo, lanzó Codex Security en versión preliminar de investigación como un agente de seguridad de aplicaciones diseñado para encontrar, validar y ayudar a corregir vulnerabilidades. En junio, OpenAI presentó Patch the Planet, una iniciativa de Daybreak junto con Trail of Bits centrada en ayudar a los mantenedores de proyectos de código abierto a encontrar y corregir problemas de seguridad. A finales de julio, OpenAI también publicó el CLI de código abierto Codex Security y el SDK de TypeScript.
Esto hace que la historia de seguridad en torno a Codex sea especialmente importante.
Codex no es solo un modelo de generación de código. Es un agente de programación conectado de forma local y en la nube que puede leer repositorios, editar archivos, invocar herramientas, ejecutar comandos, cargar plugins, conectarse a servicios MCP y operar dentro de entornos de desarrollo que suelen contener código fuente y credenciales.
En septiembre, un informe de BAAI/New Ziyuan destacó una nueva afirmación sobre la seguridad de Codex atribuida a 360 Tulongfeng, un sistema chino de pruebas de seguridad de IA. El informe afirma que el problema estaba relacionado con la ruta de sincronización del plugin Git seleccionado de Codex y que podía eludir el límite de aprobación que los usuarios normalmente esperan antes de realizar acciones sensibles.
Este nuevo hallazgo específico de 360 no ha estado acompañado de un aviso público de OpenAI ni de un informe técnico público detallado que demuestre de forma independiente que se trata de un día cero distinto. Sin embargo, el riesgo general descrito en el artículo es real: los informes públicos anteriores sobre problemas de Codex ya habían mostrado que la sincronización de plugins seleccionados durante el inicio podía ejecutarse fuera del sandbox del modelo y, bajo determinadas condiciones del entorno Git, operar sobre el repositorio del usuario en lugar de hacerlo sobre la caché del plugin.
La diferencia es importante. Este artículo conserva la estructura de la historia original y separa los incidentes públicos confirmados, los hallazgos comunicados por investigadores y las afirmaciones atribuidas a proveedores.
OpenAI presentó Codex Security el 6 de marzo de 2026.
El producto está diseñado para crear contexto sobre una base de código, identificar debilidades de seguridad, validar si un hallazgo es relevante y proponer correcciones. A diferencia de un simple escáner de patrones, OpenAI lo posiciona como un sistema de seguridad agéntico capaz de razonar sobre un proyecto y reducir los falsos positivos.
Más tarde, OpenAI amplió este esfuerzo con Patch the Planet.
La iniciativa combina la investigación de vulnerabilidades asistida por IA con revisión humana para que los mantenedores reciban hallazgos que hayan sido comprobados y que puedan incluir parches y pruebas.
El mensaje subyacente es sencillo: la IA puede aumentar tanto la velocidad de creación de software como la de descubrimiento de vulnerabilidades, por lo que los equipos defensivos necesitan formas más rápidas de revisar y corregir el código.
La ironía que destaca el artículo de origen es que el mismo tipo de infraestructura de agentes de programación que se utiliza para encontrar los fallos de otras personas también se ha convertido en un objetivo valioso para los investigadores de seguridad.
¿En qué consiste la nueva afirmación sobre la sincronización de plugins seleccionados?
El artículo de origen atribuye una vulnerabilidad de Codex descubierta recientemente al sistema Tulongfeng de 360 y afirma que el problema está relacionado con el mecanismo de sincronización de plugins Git seleccionados de Codex.
En el uso normal, Codex depende de varios controles de seguridad:
- Un sandbox define dónde pueden leer o escribir los comandos dirigidos por el modelo.
- Las políticas de aprobación determinan cuándo Codex debe detenerse y solicitar autorización antes de realizar acciones sensibles.
- Los mecanismos de plugins y MCP amplían las capacidades del agente.
- Git se utiliza para obtener y sincronizar código y contenido de plugins.
El riesgo aparece cuando el código de inicio o de infraestructura se ejecuta fuera del mismo sandbox utilizado para los comandos dirigidos por el modelo.
Esta distinción ya es visible en los informes públicos sobre problemas de Codex.
Un problema publicado en GitHub en julio documentó un caso en el que la sincronización de plugins seleccionados durante el inicio ejecutaba comandos Git sin aislar completamente las variables de entorno GIT_* locales al repositorio. Cuando Codex se iniciaba dentro de determinados contextos de hooks de Git o worktrees, la sincronización podía actuar sobre el repositorio del usuario en lugar de hacerlo sobre la caché de plugins prevista.
El autor señaló específicamente que --sandbox read-only no contenía el comportamiento porque la sincronización formaba parte de la infraestructura de inicio de Codex, no de un comando ejecutado por el modelo dentro del sandbox.
OpenAI fusionó una corrección titulada «Isolate curated plugin sync Git environment» el 24 de junio de 2026. Los problemas públicos relacionados con las versiones 0.142.x afectadas y las primeras compilaciones 0.143 mostraron que la corrección estuvo inicialmente presente en main antes de llegar a las versiones estables.
Este historial público respalda el argumento principal del artículo: los límites de seguridad de un agente deben cubrir su propia infraestructura, no solo los comandos de shell solicitados directamente por el modelo.
Lo que sigue siendo menos claro es si la afirmación de septiembre atribuida a Tulongfeng representa una ruta de explotación independiente además del problema público anterior de aislamiento de la sincronización durante el inicio. Sin un aviso público, un CVE o un informe técnico de OpenAI o 360, esta versión no presenta esa afirmación sobre un «nuevo día cero» como un hecho establecido de forma independiente.
Por qué las solicitudes de aprobación no son suficientes por sí solas
Un modelo de seguridad habitual de Codex tiene este aspecto:
- El agente solicita una acción.
- El sandbox comprueba si la acción se ajusta a su límite permitido.
- Si la acción necesita más privilegios, Codex se detiene.
- El usuario o el revisor la aprueba o la rechaza.
- Solo entonces debería continuar la acción sensible.
Las directrices actuales de OpenAI sobre seguridad de agentes siguen el mismo principio general: los efectos secundarios de alto riesgo deben limitarse de forma independiente y, cuando sea necesario, detenerse para una revisión humana explícita.
El problema es que una solicitud de permisos solo puede proteger una acción si esta pasa realmente por la ruta de código que aplica la solicitud.
Si un actualizador en segundo plano, un sincronizador de plugins, un proceso auxiliar u otro subsistema de confianza realiza tareas fuera de esa ruta, la interfaz visible de aprobación puede no ser el límite de seguridad relevante.
Esta es una de las lecciones más importantes de los informes de vulnerabilidades de Codex de 2026.
El modelo de amenazas de una herramienta de programación con IA ya no se limita a:
«¿El modelo solicitará ejecutar un comando peligroso?»
También incluye:
«¿Qué partes de la plataforma del agente pueden modificar archivos, iniciar procesos, obtener código, cargar plugins, leer credenciales o interactuar con Git antes de que se active el flujo normal de aprobación del modelo o fuera de él?»
Un error de sincronización de plugins puede convertirse en un problema de cadena de suministro de software
El artículo de origen ilustra el posible impacto con un escenario de cadena de suministro de software.
La cadena no requiere que el malware llegue mediante una descarga obviamente maliciosa.
Una secuencia más realista sería:
- Un desarrollador abre o trabaja con un repositorio no confiable o comprometido.
- Una vulnerabilidad del agente de programación cruza un límite de sandbox o de aprobación previsto.
- El atacante accede a las credenciales o herramientas de desarrollo disponibles en esa estación de trabajo.
- Esas credenciales se utilizan para modificar el código fuente, CI/CD, la publicación de paquetes o la infraestructura de lanzamiento.
- Se publica una versión maliciosa a través del canal de actualización confiable habitual del proyecto.
- Los usuarios posteriores instalan lo que parece una actualización legítima.
Por eso las estaciones de trabajo de los desarrolladores son objetivos de alto valor.
Pueden contener:
- Tokens de GitHub o GitLab
- Credenciales de servicios en la nube
- Secretos de CI/CD
- Credenciales para publicar paquetes
- Certificados de firma de código
- Acceso a producción
- Repositorios internos
La primera máquina comprometida quizá no sea el objetivo real del atacante.
El objetivo puede ser la confianza asociada a la identidad del desarrollador y a su canal de lanzamiento.
Esta es la característica definitoria del riesgo de cadena de suministro: el atacante intenta convertir una ruta de software confiable en el mecanismo de distribución.
Codex ha afrontado varios hallazgos de seguridad en 2026
La historia de los plugins seleccionados forma parte de una secuencia más amplia de investigaciones de seguridad sobre agentes de programación con IA.
El artículo de origen agrupa varios incidentes de 2026, y la mayoría puede verificarse de forma independiente.
Mayo: Pwn2Own Berlin incorpora los agentes de programación como objetivos formales
Pwn2Own Berlin 2026 introdujo una categoría específica de Coding Agent, con OpenAI Codex, Anthropic Claude Code y Cursor como objetivos.
Los resultados oficiales del primer día de Zero Day Initiative muestran que Compass Security explotó con éxito OpenAI Codex utilizando un problema CWE-150 y obtuvo 40.000 dólares y cuatro puntos de Master of Pwn.
Doyensec también demostró una explotación contra Codex, pero el resultado se clasificó como una colisión porque el proveedor ya conocía el error subyacente.
El evento en su conjunto terminó con 47 vulnerabilidades de día cero únicas y 1.298.250 dólares en premios en todas las categorías.
Pwn2Own es especialmente útil como punto de referencia porque sus reglas para agentes de programación excluían los jailbreaks simples y los modos inseguros. Una participación exitosa debía atravesar un límite de seguridad significativo mediante un flujo de trabajo común de un agente de programación.
Agosto: 360 afirma que Tulongfeng encontró seis vulnerabilidades de alto valor en Codex
El 12 de agosto, 360 declaró públicamente que su sistema de seguridad de IA Tulongfeng había encontrado seis vulnerabilidades de seguridad de alto valor en OpenAI Codex.
Según el anuncio de 360, los hallazgos incluían casos de alto riesgo que podían provocar ejecución remota de código arbitrario y eludir las solicitudes de confianza de Codex cuando los usuarios abrían directorios de proyectos no confiables.
Varios medios chinos y Xinhua, mediante un informe distribuido, repitieron la información.
Sin embargo, los informes técnicos detallados y los identificadores al estilo CVE de los seis hallazgos no se hicieron públicos en las fuentes revisadas para este artículo.
Por tanto, la forma correcta de expresar la afirmación es:
360 afirma que Tulongfeng encontró seis vulnerabilidades de alto valor en Codex, incluidos casos con impacto de ejecución remota de código.
Esto es diferente de validar de forma independiente las seis cadenas de explotación a partir de material técnico público.
Agosto-septiembre: Overpatch y Heapjack
El investigador de seguridad Oren Yomtov, de Accomplish, comunicó a OpenAI dos escapes del sandbox de Codex el 12 de agosto.
Los investigadores los denominaron Overpatch y Heapjack.
Overpatch afectaba a la ruta de aplicación de parches del CLI de código abierto de Codex y podía escapar del límite previsto de escritura en el espacio de trabajo.
Heapjack tenía como objetivo un helper de JavaScript utilizado por Codex Desktop y, según los investigadores, podía terminar ejecutando comandos sin sandbox incluso cuando Codex funcionaba en modo de solo lectura.
Los investigadores afirman que OpenAI corrigió ambos problemas en un plazo de ocho días.
Sus indicaciones de corrección publicadas señalan que los usuarios deben actualizar a:
| Problema | Versión corregida comunicada por el investigador |
|---|---|
| Overpatch | Codex CLI 0.149.0 o posterior |
| Heapjack | Compilación de Codex Desktop 26.818.21641 o posterior |
Estos números de versión proceden de la divulgación de los investigadores y no de un aviso de seguridad independiente de OpenAI.
17 de septiembre: Plugin4Shell afecta a cuatro agentes de programación importantes
AIR Security divulgó Plugin4Shell el 17 de septiembre.
El fallo afectaba a la lógica de instalación y actualización de plugins en:
- Claude Code
- OpenAI Codex
- GitHub Copilot
- Gemini CLI
AIR lo describió como una ruta de ejecución remota de código sin interacción del usuario, basada en un fallo que impedía verificar que el código descargado después de la instalación del plugin coincidiera realmente con el commit que el marketplace pretendía fijar.
Dado que Codex y Claude Code podían actualizar automáticamente los plugins instalados, un plugin que antes era confiable podía convertirse en una vía de cadena de suministro sin requerir un nuevo clic del usuario.
AIR afirma que OpenAI corrigió Codex en la versión 0.146.0.
Plugin4Shell es importante porque no fue un fallo del comportamiento del modelo. Fue un fallo clásico de diseño de la cadena de suministro de software en la capa de distribución que rodea al agente.
¿Qué tienen en común estos incidentes?
Los hallazgos de Codex de 2026 no comparten una única causa raíz.
Algunos afectan a los límites del sandbox.
Otros afectan a procesos auxiliares.
Algunos están relacionados con la gestión del entorno Git.
Otros afectan a la distribución de plugins.
Lo que sí comparten es una base informática de confianza ampliada.
Un agente de programación moderno no es simplemente:
solicitud del usuario -> modelo -> respuesta
Se parece más a:
usuario
-> modelo
-> armazón del agente
-> enrutador de herramientas
-> shell
-> sistema de archivos
-> Git
-> gestor de plugins
-> servicios MCP
-> credenciales
-> red
-> CI/CD
Cada capa introduce capacidades útiles.
Crea un sitio de presentacion y capta leads en minutos
Describe tu idea una vez y We0 AI puede generar un sitio de presentacion, paginas y CMS, y ayudarte a atraer clientes y trafico tras el lanzamiento.
Una generación completa de proyectos para registro gratuito
Lo mejor para probar un flujo de generación completo y ver rápidamente el primer borrador del proyecto.
Cada capa también puede introducir un nuevo límite de seguridad.
Por eso, afirmar que «el modelo está en un sandbox» no constituye por sí solo un argumento de seguridad completo.
La plataforma del agente también debe demostrar que el actualizador, el cargador de plugins, el editor de archivos, el puente de terminal, los proxies de red, los demonios auxiliares y las rutas de credenciales respetan los mismos supuestos de seguridad.
La IA está aumentando tanto la producción de software como el descubrimiento de vulnerabilidades
El argumento más amplio del artículo de origen es que la IA está acelerando ambos lados de la seguridad del software.
En el ámbito del desarrollo, los agentes de programación pueden crear funcionalidades, pruebas, infraestructura, integraciones y proyectos completos mucho más rápido que los flujos de trabajo manuales tradicionales.
Eso aumenta la cantidad de código nuevo que se produce.
En el ámbito defensivo, sistemas como Codex Security y Tulongfeng están diseñados para analizar grandes bases de código y encontrar vulnerabilidades a escala de máquina.
Eso aumenta la velocidad a la que pueden descubrirse vulnerabilidades antiguas y nuevas.
Ambas tendencias se refuerzan mutuamente.
Más código crea una mayor superficie de ataque.
Una automatización de seguridad más eficaz descubre una mayor parte de esa superficie de ataque.
El resultado no es necesariamente un ecosistema de software menos seguro. Pero sí significa que la revisión de seguridad debe funcionar a una velocidad más cercana a la del desarrollo asistido por IA.
Por qué las herramientas de programación con IA constituyen una capa especialmente sensible
Los agentes de programación ocupan una posición poco habitual en la pila de software.
Se sitúan antes que las aplicaciones que los usuarios acabarán instalando.
Pueden tener acceso a:
- Código fuente
- Scripts de compilación
- Ejecución de shell
- Historial de Git
- Archivos de dependencias
- Secretos de desarrollo
- Flujos de lanzamiento
Un fallo en un chatbot normal puede producir una respuesta incorrecta.
Un fallo en un agente de programación puede producir en ocasiones un archivo modificado, un proceso iniciado, un repositorio alterado, una credencial expuesta o una ruta de compilación comprometida.
Por eso la seguridad de los agentes de programación se parece cada vez más a la seguridad de endpoints y de la cadena de suministro de software, y no únicamente a la seguridad del modelo.
Las propias directrices actuales de OpenAI sobre el sandbox reflejan esta realidad. Recomiendan aislar las cargas de trabajo, restringir el acceso de salida a la red, separar las credenciales, mantener las claves de aplicación fuera de los entornos de ejecución del agente y utilizar controles de aprobación independientes para las acciones relevantes.
Quién encuentra primero la vulnerabilidad es importante
El último tercio del artículo de origen se centra en 360 Tulongfeng y en la carrera entre defensores y atacantes.
La idea central es válida: una vulnerabilidad existe tanto si el proveedor la conoce como si no.
Si un defensor la encuentra primero, existe una oportunidad de corregir el sistema antes de que la explotación se extienda.
Si un atacante la encuentra primero, el mismo error puede convertirse en un incidente.
Ese es el argumento económico detrás de la investigación automatizada de vulnerabilidades.
Las iniciativas Codex Security y Patch the Planet de OpenAI se basan en la misma premisa, aunque procedan de una organización diferente.
El objetivo es adelantar el descubrimiento de vulnerabilidades en el ciclo de vida del software.
Qué afirma 360 que hace Tulongfeng
360 describe Tulongfeng como un sistema de descubrimiento de vulnerabilidades mediante IA construido alrededor de dos componentes:
- Un modelo especializado en seguridad, entrenado con datos de vulnerabilidades y de ataque y defensa recopilados durante muchos años.
- Un conjunto de agentes especializados que reproduce partes de los flujos de trabajo de expertos en seguridad, como el análisis de la superficie de ataque, la evaluación de vulnerabilidades, el análisis de código, el uso de herramientas y la validación dinámica.
360 afirma que el producto se ha utilizado para probar código fuente, binarios, firmware, sistemas empresariales y cadenas de herramientas de IA.
La empresa también afirma que Tulongfeng había encontrado más de 10.000 vulnerabilidades a finales de agosto o septiembre de 2026.
Ese total es una cifra acumulada comunicada por el proveedor.
Un anuncio de la comunidad de 360 publicado el 25 de agosto afirmaba que el sistema había encontrado más de 10.000 vulnerabilidades y que cerca de 400 organizaciones se habían conectado y habían completado pruebas de seguridad. Una publicación posterior de septiembre repitió la cifra de más de 10.000.
El artículo de origen también afirma que 260 hallazgos habían sido verificados por autoridades chinas de vulnerabilidades y que casi 500 organizaciones se habían conectado. Esas cifras exactas no coincidieron con la fuente más reciente de 360 revisada para esta versión, por lo que no se repiten aquí como cifras confirmadas de forma independiente.
El ciclo de «automejora» de Tulongfeng
El artículo de origen describe el enfoque de Tulongfeng como una forma de mejora recursiva.
El concepto tiene menos que ver con que el modelo base reescriba sus propios pesos y más con la creación de una memoria operativa reutilizable a partir de tareas de seguridad completadas.
El flujo de trabajo puede resumirse así:
- Un agente se encuentra con un problema difícil de análisis de vulnerabilidades.
- El sistema registra todo el proceso de razonamiento y uso de herramientas.
- El flujo de trabajo se abstrae en una estrategia reutilizable.
- Otros agentes pueden acceder posteriormente a esa estrategia.
- Las tareas futuras comienzan con una experiencia acumulada mayor.
Esto es similar a la forma en que los equipos de seguridad crean manuales operativos, bases de conocimiento sobre exploits, reglas de detección y procedimientos de respuesta a incidentes.
La diferencia es que un sistema de agentes puede reutilizar potencialmente esa experiencia a mucha mayor velocidad y en numerosas tareas paralelas.
La afirmación del proveedor es que esto convierte los descubrimientos de seguridad individuales en una capacidad compartida en toda la flota de agentes.
La carrera de seguridad no termina con un solo parche
El artículo termina con una imagen de cadena de suministro que merece conservarse.
Cuando un usuario pulsa «Actualizar», ese software puede haber pasado por:
- Un repositorio de código abierto
- Una estación de trabajo de desarrollador
- Una herramienta de programación con IA
- Un sistema de compilación
- Un pipeline de CI/CD
- Un proceso de firma
- Una tienda de aplicaciones o un registro de paquetes
- Un mecanismo de actualización automática
Cada etapa hereda la confianza de la etapa anterior.
Los agentes de programación con IA se sitúan ahora cerca del principio de esa cadena.
Esto hace que sus propios controles de seguridad formen parte del modelo de seguridad de cada aplicación que ayudan a crear y distribuir.
La lección práctica no es que los desarrolladores deban dejar de utilizar agentes de programación.
Es que los agentes de programación deben tratarse como infraestructura de desarrollo con privilegios elevados.
Necesitan gestión de versiones, aislamiento, mínimo privilegio, separación de secretos, gobernanza de plugins, supervisión de seguridad y aplicación rápida de parches, igual que cualquier otra herramienta con privilegios.
Lista de comprobación práctica de seguridad para usuarios de Codex
A partir de las directrices actuales de OpenAI y de las divulgaciones públicas de vulnerabilidades de 2026, los desarrolladores pueden reducir la exposición con algunas prácticas concretas.
Mantén Codex actualizado
Las correcciones de seguridad conocidas se han publicado rápidamente.
Para los problemas divulgados por investigadores que se cubren arriba, los usuarios afectados deberían utilizar versiones posteriores a las compilaciones corregidas comunicadas para Plugin4Shell, Overpatch y Heapjack.
Trata los repositorios no confiables como código no confiable
No des por hecho que «solo le pedí algo al agente» significa que no puede ejecutarse ninguna ruta de código.
Utiliza aislamiento cuando revises repositorios desconocidos.
Separa las credenciales de larga duración
Evita exponer directamente credenciales de alto valor de servicios en la nube, registros de paquetes, firma y producción a un entorno de ejecución del agente.
Restringe el acceso a la red
Permite únicamente los destinos de salida necesarios para la tarea.
Un agente de programación con salida arbitraria y credenciales amplias tiene un radio de impacto mucho mayor.
Revisa los plugins y las integraciones MCP
Un agente confiable aún puede verse comprometido a través de una extensión no confiable o de un canal de actualización comprometido.
Fija, audita y actualiza los plugins de forma deliberada.
Mantén la aprobación humana fuera del límite de ejecución no confiable
Para operaciones de alto impacto, las aprobaciones deben aplicarse mediante un componente confiable independiente, en lugar de depender únicamente de una lógica que se ejecuta dentro del mismo entorno que el agente.
Supervisa la infraestructura que rodea al agente
Registra y revisa:
- Llamadas a herramientas
- Actualizaciones de plugins
- Operaciones de Git
- Conexiones de red
- Uso de credenciales
- Escrituras en el sistema de archivos
- Eventos de aprobación
La respuesta final del modelo es solo una parte de lo que hizo el agente.
Preguntas frecuentes
¿Qué es el problema de sincronización de plugins seleccionados de Codex?
Codex ha utilizado un mecanismo de inicio para sincronizar plugins seleccionados mediante Git. Los problemas públicos de GitHub mostraron que las primeras versiones podían heredar el estado del entorno Git local al repositorio y realizar operaciones de sincronización sobre el repositorio del usuario en lugar de hacerlo sobre la caché de plugins prevista, fuera del sandbox del modelo.
¿Encontró 360 Tulongfeng un nuevo día cero de Codex en septiembre de 2026?
El artículo de BAAI/New Ziyuan atribuye una nueva ruta de ataque mediante la sincronización de Git seleccionado a 360 Tulongfeng. Sin embargo, no se encontró ningún aviso público de OpenAI ni una divulgación técnica detallada de 360 que establezca de forma independiente que esta afirmación específica de septiembre sea un nuevo día cero distinto. Por tanto, debe tratarse como un informe atribuido y no como un hallazgo público completamente verificado.
¿Qué son Overpatch y Heapjack?
Son dos escapes del sandbox de Codex divulgados por el investigador de Accomplish Oren Yomtov. El investigador afirma que ambos se comunicaron a OpenAI el 12 de agosto y que se corrigieron en un plazo de ocho días.
¿Qué es Plugin4Shell?
Plugin4Shell es una vulnerabilidad de cadena de suministro de plugins divulgada por AIR Security el 17 de septiembre de 2026. AIR afirma que afectaba a Claude Code, Codex, GitHub Copilot y Gemini CLI al romper la garantía de que un plugin instalado coincidiera con el commit que el marketplace pretendía fijar.
¿Codex fue explotado en Pwn2Own Berlin 2026?
Sí. Zero Day Initiative comunicó una explotación exitosa de Codex por parte de Compass Security durante el primer día y otra explotación exitosa de Codex por parte de Ikotas Labs durante el tercer día. Doyensec también demostró una explotación que se clasificó como colisión porque el proveedor ya conocía el error subyacente.
¿Codex Security es de código abierto?
OpenAI publicó el CLI de Codex Security y el SDK de TypeScript como software de código abierto en julio de 2026. El acceso a algunas capacidades de ciberseguridad y a hallazgos protegidos puede seguir requiriendo un acceso adecuado a OpenAI o Trusted Access for Cyber.
¿Utilizar el modo de sandbox de solo lectura garantiza que no pueda ocurrir nada peligroso?
No debe tratarse ningún modo individual como una garantía absoluta. Varios hallazgos de 2026 fueron relevantes precisamente porque el componente vulnerable operaba fuera del sandbox esperado del modelo o atravesaba el límite de seguridad previsto.
¿Cómo deben proteger los equipos los agentes de programación con IA?
Utiliza versiones actuales, aísla el código no confiable, restringe el acceso a la red, mantén las credenciales de larga duración fuera del entorno de ejecución, audita los plugins, utiliza aprobaciones humanas independientes para las acciones importantes y registra la actividad real de herramientas y sistemas del agente.
Herramientas relacionadas
- OpenAI Codex: CLI de Codex de código abierto y código central utilizado para flujos de trabajo locales con agentes de programación.
- Codex Security: CLI y SDK de TypeScript de OpenAI para definir políticas de seguridad y encontrar, validar y corregir vulnerabilidades.
- OpenAI Deployment Safety Hub: Tarjetas de sistema oficiales e información sobre seguridad de despliegue para los modelos de OpenAI.
- Zero Day Initiative: Programa de divulgación de vulnerabilidades y organizador de Pwn2Own Berlin 2026.
- AIR Security: Empresa de seguridad de agentes que divulgó Plugin4Shell.
- 360 Tulongfeng: Introducción pública de 360 a su sistema de agentes de IA para el descubrimiento de vulnerabilidades.
Enlaces relacionados
- OpenAI Codex Security Research Preview: Anuncio oficial de marzo de 2026 sobre Codex Security.
- OpenAI Patch the Planet: Iniciativa oficial de Daybreak para el trabajo de seguridad de código abierto asistido por IA.
- Codex Security GitHub Repository: Repositorio oficial del CLI y SDK de código abierto.
- Codex Curated Plugin Sync Issue #31498: Informe público que muestra que la sincronización Git durante el inicio podía operar fuera del límite del sandbox de solo lectura bajo un estado de entorno Git heredado.
- Pwn2Own Berlin 2026 Day One Results: Resultados oficiales de ZDI que documentan una explotación exitosa de Codex y una colisión.
- Accomplish: Escaping the OpenAI Codex Sandbox, Twice: Divulgación de los investigadores sobre Overpatch y Heapjack, incluidas las versiones corregidas comunicadas.
- AIR Security: Plugin4Shell: Publicación de investigación primaria sobre la vulnerabilidad de cadena de suministro de plugins que afectó a varios agentes.
Resumen
OpenAI utiliza Codex Security y Patch the Planet para acelerar la investigación defensiva de vulnerabilidades, pero el propio Codex se ha convertido en un objetivo de seguridad cada vez más importante porque se encuentra cerca del código fuente, las herramientas, las credenciales, los plugins y los flujos de lanzamiento de software.
Entre los incidentes de 2026 verificados públicamente se incluyen las explotaciones de Codex en Pwn2Own, los errores de aislamiento de la sincronización de plugins seleccionados durante el inicio, los escapes del sandbox Overpatch y Heapjack, y Plugin4Shell. El «nuevo día cero» de septiembre atribuido a 360 Tulongfeng debe tratarse con mayor cautela hasta que un aviso público detallado establezca en qué se diferencia de los problemas anteriores de sincronización de plugins.
La lección general es coherente en todos estos casos: el límite de seguridad de un agente de programación con IA abarca mucho más que el modelo. El actualizador, el gestor de plugins, la integración con Git, el entorno de ejecución de herramientas, los procesos auxiliares, el acceso a la red, la gestión de credenciales y el sistema de aprobación forman parte de la base informática de confianza.
Las herramientas de programación con IA son ahora infraestructura de software situada en las fases iniciales de la cadena. Sus propios controles de seguridad deben tratarse con el mismo rigor que las aplicaciones y las cadenas de suministro que ayudan a crear.
