Pasar al contenido principal
OpenAI

8 de mayo de 2026

SeguridadSeguridad

Ejecutar Codex de forma segura en OpenAI

Una mirada a los controles, los límites y la telemetría que OpenAI usa para gobernar agentes de programación en flujos de trabajo reales.

Cargando...

A medida que los sistemas de IA se vuelven más capaces, cada vez actúan más en nombre de los usuarios. Los agentes de programación pueden revisar repositorios de forma autónoma, ejecutar comandos e interactuar con herramientas de desarrollo, tareas que antes requerían la intervención directa de una persona.

Con Codex, hemos diseñado estas capacidades junto con los controles que las organizaciones necesitan para una implementación segura. Los equipos de seguridad requieren mecanismos para gobernar cómo operan los agentes: a qué pueden acceder, cuándo se requiere aprobación humana, con qué sistemas pueden interactuar y qué telemetría está disponible para explicar su comportamiento.

En OpenAI, implementamos Codex con algunos objetivos claros: mantener al agente dentro de límites técnicos definidos, permitir que los desarrolladores avancen rápidamente en acciones de bajo riesgo y hacer explícitas las acciones de mayor riesgo. También conservamos telemetría nativa del agente para poder entender y auditar lo que hizo. En la práctica, esto implica configuraciones gestionadas, ejecución restringida, políticas de red y registros nativos del agente.

Controlar cómo opera Codex

Implementamos Codex con un principio simple: debe ser productivo dentro de un entorno delimitado, las acciones cotidianas de bajo riesgo deben ser fluidas y las acciones de mayor riesgo deben detenerse para revisión.

Aislamiento (sandboxing) y aprobaciones

Las aprobaciones y el aislamiento funcionan juntos. El entorno aislado define el límite técnico de ejecución, incluido dónde puede escribir Codex, si puede acceder a la red y qué rutas permanecen protegidas. La política de aprobación determina cuándo Codex debe pedir permiso para realizar una acción, por ejemplo, cuando necesita hacer algo fuera del entorno aislado. Los usuarios pueden aprobar la acción una vez o aprobar ese tipo de acción para esa sesión.

Para las solicitudes que cruzan el límite del entorno sandbox, usamos el modo de revisión automática(se abre en una nueva ventana), una función que, al activarse, aprueba automáticamente ciertos tipos de solicitudes para reducir la frecuencia con la que los usuarios tienen que detenerse y aprobar acciones de Codex. Codex envía la acción planificada y el contexto reciente al subagente de aprobación automática, que puede validar automáticamente acciones de bajo riesgo —o acciones de alto riesgo con un nivel suficiente de autorización del usuario— en lugar de interrumpir al usuario. Eso permite que Codex siga avanzando en tareas rutinarias, mientras sigue deteniéndose ante acciones de mayor riesgo o con consecuencias no deseadas.

TOML

1
# config.toml
2

3
# Turn on auto_review
4
approvals_reviewer = "auto_review"
5
# Add known development directories to the sandbox automatically
6
sandbox_workspace_write.writable_roots = ["~/development"]
7

8
# requirements.toml
9

10
# Require Codex to operate inside the sandbox
11
allowed_sandbox_modes = ["read-only", "workspace-write"]

Acceso a la red

No ejecutamos Codex con acceso saliente sin restricciones. Nuestra política de red gestionada permite destinos esperados, bloquea aquellos a los que no queremos que Codex acceda y requiere aprobación para dominios no reconocidos. Esto permite que Codex complete flujos de trabajo comunes y conocidos sin otorgarle acceso amplio a la red.

TOML

1
# requirements.toml
2

3
# Ensure web fetch only comes from OpenAI's cache
4
allowed_web_search_modes = ["cached"]
5

6
[experimental_network]
7
# Turn on Network Proxy
8
enabled = true
9
# Allow Codex to interact with localhost
10
allow_local_binding = true
11
# Block all requests to this domain
12
denied_domains = ["pastebin.com"]
13
# Auto-allow requests to these domains
14
allowed_domains = ["login.microsoftonline.com", "*.openai.com"]

Identidad y credenciales

También gestionamos cómo se autentica Codex. Las credenciales OAuth de CLI y MCP se almacenan en el llavero seguro del sistema operativo, el inicio de sesión se fuerza a través de ChatGPT y el acceso se vincula a nuestro espacio de trabajo empresarial de ChatGPT. Eso mantiene el uso de Codex ligado a nuestros controles a nivel de espacio de trabajo y hace que la actividad de Codex esté disponible en la plataforma de Registros de cumplimiento de ChatGPT para nuestro espacio de trabajo empresarial.

TOML

1
# config.toml
2

3
# Store CLI Auth Creds in OS Keychain
4
cli_auth_credentials_store = "keyring"
5
# Store MCP Creds in OS Keychain
6
mcp_oauth_credentials_store = "keyring"
7
# Require Auth via ChatGPT
8
forced_login_method = "chatgpt"
9
# Require Auth to Specific ChatGPT Workspace
10
forced_chatgpt_workspace_id = "<workspace-uuid>"

Reglas

Usamos reglas para evitar que Codex trate todos los comandos de shell como si fueran igual de seguros. Los comandos comunes y benignos que los ingenieros usan en el día a día del desarrollo se permiten sin aprobación fuera del entorno aislado, mientras que los comandos claramente peligrosos pueden bloquearse o requerir aprobación. Esto permite que Codex avance con rapidez en tareas de ingeniería habituales, pero al mismo tiempo mantiene revisión o bloquea aquellos patrones que no queremos que se ejecuten fuera del entorno aislado.

Starlark

1
# default.rules
2

3
prefix_rule(
4
pattern = ["gh", "pr", ["view", "list"]],
5
decision = "allow",
6
justification = "Allows read-only GitHub PR inspection via gh CLI.",
7
)
8
prefix_rule(
9
pattern = ["kubectl", ["get", "describe", "logs"]],
10
decision = "allow",
11
justification = "Allows Kubernetes resource inspection for debugging.",
12
)

Configuraciones administradas

Aplicamos esta postura mediante una combinación de requisitos gestionados en la nube, preferencias administradas de macOS y archivos de requisitos locales. Los requisitos son controles aplicados por administradores que los usuarios no pueden anular. Las preferencias administradas de macOS y los archivos de requisitos locales nos permiten mantener una base consistente y, al mismo tiempo, probar distintas configuraciones por equipo, grupo de usuarios o entorno. Estas configuraciones se aplican en todas las superficies locales de Codex, incluida la aplicación de escritorio, la CLI y la extensión de IDE.

Telemetría nativa del agente y pistas de auditoría

El control es solo la mitad del trabajo. Una vez que se implementan los agentes, los equipos de seguridad necesitan visibilidad de lo que estos agentes están haciendo y por qué. Los registros de seguridad tradicionales siguen siendo útiles al revisar acciones realizadas por Codex, pero en su mayoría responden qué pasó: se inició un proceso, cambió un archivo, se intentó una conexión de red. Los defensores todavía tienen que averiguar por qué Codex hizo algo o cuál era la intención del usuario.

Codex puede ofrecer a los equipos de seguridad una visión más consciente del agente. Soporta la exportación de logs mediante OpenTelemetry para distintos eventos, como prompts de usuario, decisiones de aprobación de herramientas, resultados de ejecución de herramientas, uso de servidores MCP y eventos de red (permitidos o bloqueados por el proxy). Además, los registros de actividad de Codex están disponibles a través de la OpenAI Compliance Platform para clientes Enterprise y Edu.

TOML

1
# config.toml
2

3
[otel]
4
log_user_prompt = true
5
environment = "prod"
6

7
[otel.exporter.otlp-http]
8
endpoint = "http://localhost:14318/v1/logs"
9
protocol = "binary"

En OpenAI, usamos los registros de Codex junto con el agente de triaje de seguridad impulsado por IA. Cuando una alerta de punto de acceso indica que Codex hizo algo inusual, la herramienta de seguridad del punto de acceso nos dice que ocurrió un evento sospechoso. Luego, los registros de Codex ayudan a explicar la intención contextual del usuario y del agente. El agente de triaje de seguridad con IA usa los registros de Codex para inspeccionar la solicitud original, la actividad de herramientas, las decisiones de aprobación, los resultados de herramientas y cualquier decisión o bloqueo relevante de la política de red. El agente de triaje de seguridad con IA presenta su análisis al equipo de seguridad para revisión, con el fin de distinguir entre comportamiento esperado del agente, errores benignos y actividad que realmente justifica un escalamiento.

También utilizamos la misma telemetría de forma operativa. Analizamos estos registros para entender cómo cambia la adopción interna, qué herramientas y servidores MCP se usan, con qué frecuencia el entorno aislado de red bloquea o solicita aprobación, y en qué áreas el despliegue aún necesita ajustes. Estos registros de OpenTelemetry se pueden centralizar en sistemas SIEM y de cumplimiento.

De cara al futuro

A medida que los agentes de programación como Codex se integran en los flujos de trabajo de desarrollo, los equipos de seguridad necesitan herramientas diseñadas específicamente para gestionar este cambio. Codex ofrece las superficies de control, la gestión de configuración, el aislamiento y la telemetría detallada y consciente del agente necesarias para garantizar una adopción segura. Con estas capacidades implementadas, los equipos de seguridad pueden habilitar Codex con mayor confianza, al equilibrar la productividad de los desarrolladores con la visibilidad y el control requeridos para la seguridad empresarial. Más información sobre cómo configurar Codex aquí(se abre en una nueva ventana), y sobre la API de cumplimiento aquí(se abre en una nueva ventana).

Autor

OpenAI