OpenAI muestra como gobierna Codex por dentro: sandbox, red cerrada y logs que si sirven
OpenAI publico el 8 de mayo de 2026 una mirada concreta a como usa Codex con sandboxing, reglas, politicas de red y telemetria. La pieza valiosa para builders no es el marketing de seguridad: es el contrato operativo que deja copiar.
Muchos equipos quieren un agente de coding autonomo hasta que llega la pregunta incomoda: que puede tocar, a donde puede salir y como explicas despues por que hizo lo que hizo. OpenAI intento responder eso con una pieza bastante mas util que el promedio de post corporativo.
El 8 de mayo de 2026, OpenAI publico Running Codex safely at OpenAI, una guia donde aterriza el contrato real con el que usa Codex internamente: sandboxing, aprobaciones, politicas de red, credenciales en keyring, reglas por comando y logs agent-aware.
La noticia no es "OpenAI se toma en serio la seguridad". La noticia es que por fin hay una referencia publica con suficiente detalle para copiar una postura minima decente.
El punto fuerte no es el sandbox; es la combinacion
OpenAI describe una postura con varias capas:
- sandbox para limitar donde puede escribir y si puede salir a red;
- approval policy para cortar acciones que cruzan el borde del sandbox;
- network proxy con dominios permitidos, negados y modos de busqueda web;
- reglas por prefijo para no tratar todos los comandos como igual de peligrosos;
- y telemetria OpenTelemetry para reconstruir que quiso hacer el agente y que termino haciendo.
Visto por separado, ninguna pieza sorprende. Juntas, si. El valor real es que el agente no depende de una unica barrera, sino de un contrato compuesto.
Tres detalles que un builder deberia copiar ya
1. La red no esta abierta por defecto
OpenAI dice explicitamente que no ejecuta Codex con salida outbound abierta. En su ejemplo, la red pasa por una policy administrada donde hay:
- modos de web search permitidos;
- dominios negados;
- dominios auto-permitidos;
- y aprobacion para destinos no familiares.
Eso evita el error clasico de darle internet porque "si no, el agente no resuelve". Si tu flujo necesita red, mejor definir a que servicios necesita llegar.
2. Las credenciales viven fuera del prompt
La guia tambien baja a tierra algo que demasiados equipos siguen resolviendo mal: las credenciales de CLI y MCP OAuth van al keyring del sistema operativo, el login se fuerza via ChatGPT, y la actividad queda atada al workspace empresarial.
Eso no elimina el riesgo, pero si reduce dos problemas comunes:
- secretos filtrados en texto plano;
- sesiones imposibles de auditar despues.
3. Los logs responden el por que, no solo el que
La parte mas fuerte del post esta en la telemetria. OpenAI explica que exporta eventos como:
- prompts de usuario;
- decisiones de aprobacion;
- resultados de tools;
- uso de servidores MCP;
- y allow/deny del proxy de red.
Eso cambia la calidad del debug operativo. Un log tradicional te dice que hubo un proceso o una conexion. Un log agent-aware te acerca a la intencion de la sesion.
Teardown rapido: donde esta el tradeoff
Este enfoque compra seguridad y gobernanza, pero no gratis.
- Mas aprobaciones pueden romper ritmo si el scope del agente esta mal definido.
- Politicas de red conservadoras obligan a modelar bien el flujo antes de delegar.
- Logs mas ricos tambien implican decidir que retener, quien lo ve y como lo centralizas.
Ese costo me parece sano. Lo toxico es lo contrario: agentes con acceso amplio y cero trazabilidad, que al principio se sienten rapidos y despues se vuelven imposibles de defender ante seguridad o compliance.
Checklist minimo antes de soltar un agente de coding
Si estas montando algo con Codex, Claude Code, Copilot CLI o una capa propia, este seria mi orden:
- define un sandbox por defecto;
- cierra la red y abre solo dominios necesarios;
- saca credenciales del prompt y metelas en un store seguro;
- permite comandos benignos por regla y corta los peligrosos por politica;
- exporta telemetria desde el primer dia.
Ese orden vale mas que afinar prompts. Un agente mal gobernado con prompts impecables sigue siendo un agente mal gobernado.
Por que esta nota tiene demanda cualificada
Las queries buenas aqui no son genericas:
codex securitycodex sandboxcoding agent telemetryagent approvalsmcp oauth keyring
La intencion es clara: equipos que ya estan usando agentes y necesitan pasar de demo a politica operativa. En espanol sigue habiendo hueco para explicar como cerrar el runtime sin matar productividad.
Si todavia estas armando la base antes de endurecer seguridad, conviene aterrizar primero el loop general en Instala Tu Propio Agente de IA. Y si tu principal duda hoy es account hygiene mas que sandbox, cruza esto con las nuevas sesiones activas de ChatGPT, Codex y API.
La lectura corta es esta: OpenAI no publico solo una historia de seguridad. Publico un patron concreto de control para agentes de coding que ya merecia una traduccion practica.