Guía práctica de seguridad de Codex

Usa esta receta cuando los empleados deban iniciar sesión en Codex a través del espacio de trabajo de ChatGPT de tu empresa, y se prohíban las cuentas personales de ChatGPT y la autenticación con API key en los dispositivos administrados.

Resultado previsto

En los dispositivos administrados por la empresa, Codex solo acepta el inicio de sesión con ChatGPT en el espacio de trabajo de ChatGPT de la empresa.

Requisitos previos

• El UUID del espacio de trabajo aprobado de ChatGPT Enterprise.

• Un medio para distribuir la configuración administrada de Codex a los dispositivos.

• La decisión de prohibir la autenticación con API key en los dispositivos administrados.

Configura

1. Registra el UUID del espacio de trabajo aprobado en tu repositorio interno de configuración.

2. Añade requisitos obligatorios de autenticación al requirements.toml local:

   allowed_login_methods = ["chatgpt"]
   allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]

La primera clave permite únicamente la autenticación con ChatGPT; la segunda restringe el inicio de sesión al espacio de trabajo aprobado. Sustituye el UUID ilustrativo por el UUID de tu espacio de trabajo. Consulta la referencia de requisitos.

3. Implementa los requisitos mediante requirements.toml local o mediante MDM de macOS usando las rutas de Dónde debe ubicarse la configuración. Estos requisitos de autenticación se aplican antes de cargar las credenciales y antes de recuperar la política de la nube; Codex los ignora en los requisitos administrados desde la nube. Protege el archivo y su directorio superior contra modificaciones por parte del usuario. Los valores predeterminados heredados de managed_config.toml no aplican esta restricción.

4. Durante la prueba piloto, cierra las sesiones de los usuarios o elimina las sesiones personales de Codex almacenadas previamente. No des por hecho que una política nueva invalida retroactivamente una sesión existente.

5. Combina la restricción de inicio de sesión con los roles del espacio de trabajo y el acceso de los grupos. La autenticación controla qué identidad inicia sesión; RBAC controla qué funciones de Codex puede usar esa identidad. Consulta Autenticación.

Verifica

• Cierra sesión en Codex.

• Intenta iniciar sesión con una cuenta personal de ChatGPT. Resultado esperado: Se rechaza el inicio de sesión en el espacio de trabajo personal.

• Intenta iniciar sesión en Codex con API key. Resultado esperado: Se rechaza el inicio de sesión con API key.

• Inicia sesión en el espacio de trabajo aprobado con la cuenta corporativa. Resultado esperado: El inicio de sesión se completa correctamente.

• Reinicia la aplicación de escritorio, la CLI y la extensión del IDE; después, repite las comprobaciones.

Revierte los cambios

Restaura los requisitos locales de autenticación anteriores y vuelve a implementar el paquete revisado.

Límites

Esto controla los clientes de Codex administrados en dispositivos administrados. Combínalo con controles de aplicaciones en los dispositivos y con una política de red si el requisito es «no permitir el uso personal de Codex desde los recursos corporativos».

Usa esta receta cuando los desarrolladores necesiten acceso de solo lectura o limitado al espacio de trabajo, y quieras impedir que seleccionen acceso completo o eludan las aprobaciones y el aislamiento con --yolo.

Resultado previsto

Los usuarios solo pueden seleccionar perfiles aprobados de solo lectura o limitados al espacio de trabajo. No pueden seleccionar danger-full-access, approval_policy = "never" ni --yolo.

Configura

1. Define un perfil de espacio de trabajo aprobado:

   [permissions.corp-workspace]
   description = "Company workspace access with no unrestricted host access."
   extends = ":workspace"

2. Impón los perfiles y las políticas de aprobación permitidos:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]
   default_permissions = "corp-workspace"

   [allowed_permission_profiles]
   ":read-only" = true
   "corp-workspace" = true
   ":danger-full-access" = false

La lista de permitidos es exhaustiva: se deniegan los perfiles que no figuren en ella o estén establecidos en false, incluidos los que se añadan en versiones futuras. Consulta la Referencia de configuración.

3. Para los clientes heredados que todavía usan sandbox_mode, usa:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_sandbox_modes = ["read-only", "workspace-write"]

4. Distribuye esto como requisitos impuestos por el administrador, no como un archivo de configuración editable por el usuario.

5. Si más adelante permites la revisión automática, añádela de forma deliberada después de realizar pruebas. La revisión automática cambia quién revisa el cruce de un límite; no restablece un límite eliminado. Consulta Revisión automática.

Verifica

• Abre el selector de permisos. Resultado esperado: El acceso completo no está disponible o se rechaza.

• Inicia con --dangerously-bypass-approvals-and-sandbox. Resultado esperado: Codex rechaza el inicio o impone un perfil compatible.

• Inicia con --sandbox danger-full-access --ask-for-approval never. Resultado esperado: Se rechaza el inicio.

• Ejecuta una tarea normal en el espacio de trabajo. Resultado esperado: La tarea se completa correctamente; los cruces de límites siguen requiriendo aprobación.

Revierte los cambios

Restaura el paquete de requisitos anterior. Mantén bloqueado el acceso sin restricciones salvo que exista una excepción aprobada por separado.

Límites

Esto controla los permisos de ejecución de Codex. No elimina los privilegios de una cuenta privilegiada del sistema operativo.

Usa esta receta cuando tu organización necesite decidir qué MCP servers puede usar Codex e imponer una lista de aprobados.

Permitir un servidor y configurarlo son pasos separados. Una entrada en la lista de permitidos autoriza un servidor coincidente; no crea su configuración. Configura el servidor por separado con el nombre y la identidad correspondientes, junto con la autenticación que requiera.

Resultado previsto

Codex habilita únicamente los MCP servers cuyo nombre e identidad configurados coincidan con la lista aprobada por la empresa.

Configura

1. Haz un inventario de cada servidor aprobado: responsable, finalidad, transporte, ejecutable o URL exactos, autenticación, clasificación de datos y herramientas con capacidad de escritura.

2. Empieza por denegar todo. Una tabla administrada vacía deshabilita todos los MCP servers:

   [mcp_servers]

3. Añade los servidores HTTP aprobados mediante su URL exacta:

   [mcp_servers.internal_docs]
   identity = { url = "https://mcp.example.com/docs" }

4. Añade los servidores stdio aprobados mediante el ejecutable y los argumentos posicionales:

   [mcp_servers.internal_build.identity]
   command = { executable = "/usr/local/bin/company-mcp", args = [
     { match = "exact", value = "serve" },
     { match = "prefix", value = "--workspace=" },
   ] }

El comparador estructurado comprueba el ejecutable, la cantidad de argumentos y su orden. No restringe cwd, env ni env_vars. Considera el control de todo el contexto de inicio como un requisito previo para aprobar un servidor stdio: protege su ejecutable y sus dependencias, e impide que configuraciones de usuario o proyecto no confiables proporcionen un directorio de trabajo o un entorno que puedan cambiar su comportamiento. Si no puedes imponer ese límite de forma independiente, deja el servidor stdio sin aprobar y usa un servidor HTTP revisado en su lugar.

5. Añade por separado las identidades MCP incluidas en plugins bajo plugins.<plugin>.mcp_servers.<server>.

6. Guarda la lista de aprobados en un repositorio de configuración revisado e impleméntala mediante requisitos impuestos por el administrador.

El cliente habilita un servidor solo cuando tanto su nombre como su identidad coinciden con una entrada aprobada. Consulta Configuración administrada.

Verifica

• Configura el servidor aprobado de forma exacta. Resultado esperado: El servidor se inicia.

• Cambia un carácter de la URL. Resultado esperado: El servidor se deshabilita.

• Cambia la cantidad o el orden de los argumentos de stdio, o proporciona un argumento que no cumpla las reglas de argumentos configuradas. Resultado esperado: El servidor se deshabilita. Los valores que sigan cumpliendo un prefijo permitido continúan estando permitidos.

• En un proyecto confiable desechable, prueba modificaciones inofensivas de cwd, env y env_vars conservando el ejecutable y los argumentos coincidentes. La coincidencia de identidad por sí sola no rechaza estas modificaciones. Verifica que tu control independiente del contexto de inicio rechace las modificaciones inseguras o que el servidor stdio siga sin aprobarse; no uses una carga de inyección real.

• Añade un nombre no aprobado. Resultado esperado: El servidor se deshabilita.

• Prueba un servidor incluido en un plugin. Resultado esperado: El servidor funciona únicamente con la identidad aprobada.

Revierte los cambios

Elimina la entrada recién añadida. Para detener de inmediato todo uso de MCP, implementa una tabla mcp_servers vacía.

Límites

Incluir una identidad en la lista de permitidos no demuestra que las herramientas, los datos de origen, las credenciales o el entorno de inicio de un servidor sean seguros. Los procesos MCP stdio locales se ejecutan fuera del entorno aislado de comandos local; la coincidencia de un ejecutable y sus argumentos no restringe el acceso del servidor ni impide la carga de código basada en el entorno. Revisa de forma independiente todo el contexto de inicio y los permisos del servidor. Consulta Requisitos de identidad de MCP.

Usa esta receta cuando tu equipo de seguridad necesite comprender qué hace Codex en los dispositivos y en tu red. Reúne eventos de ejecución y herramientas, decisiones de aprobación, registros de auditoría del espacio de trabajo y registros de red para las investigaciones.

Resultado previsto

Los equipos de seguridad pueden correlacionar ejecuciones de Codex, decisiones sobre herramientas, aprobaciones, registros de auditoría del espacio de trabajo y tráfico de salida real de la red sin depender del relato del propio modelo.

Usa cuatro fuentes de evidencia

1. OpenTelemetry de Codex: eventos de ejecución, API, modelo, entorno aislado, aprobación y herramientas.

2. Hooks administrados del ciclo de vida: registros en el dispositivo relacionados con el uso de herramientas y las solicitudes de permisos.

3. Registros del proxy o la puerta de enlace de red: destinos DNS/HTTP reales y resultados de las conexiones.

4. Compliance API: registros de auditoría e investigación a nivel del espacio de trabajo.

Ninguna fuente por sí sola proporciona una supervisión completa de la red.

Configura

1. Envía los registros de OpenTelemetry de Codex a tu recopilador, ocultando los prompts sin procesar:

   [otel]
   environment = "enterprise"
   log_user_prompt = false

   [otel.exporter.otlp-http]
   endpoint = "https://otel.example.com/v1/logs"
   protocol = "binary"
   headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }

Proporciona OTLP_TOKEN al proceso de Codex mediante tu gestor de secretos aprobado o el entorno del proceso antes de iniciar el cliente. Mantén el token fuera de los archivos TOML implementados y del control de código fuente.

Codex puede emitir inicios de conversación, solicitudes de API, eventos de transmisión, metadatos de prompts, decisiones sobre herramientas y resultados de herramientas. Consulta Configuración avanzada.

2. Implementa OTel fuera de la configuración local del proyecto. Los archivos .codex/config.toml del proyecto no pueden anular el enrutamiento de la telemetría.

3. Añade hooks administrados del ciclo de vida para SessionStart, PreToolUse, PermissionRequest, PostToolUse, Stop y SessionEnd.

4. Instala los scripts de hooks en un directorio administrado por un administrador y establece allow_managed_hooks_only = true si deben ignorarse los hooks de usuario, proyecto y plugins.

5. Enruta el tráfico de los comandos ejecutados en el entorno aislado a través de un proxy con registros independientes. OTel registra que se ejecutó una herramienta; el proxy registra dónde intentó conectarse el subproceso.

6. Configura telemetría independiente para la búsqueda web, las aplicaciones, los conectores, los MCP servers, la actividad del navegador y Codex Cloud. Las reglas del proxy de comandos local no los cubren automáticamente.

7. Transmite los registros compatibles de Compliance API al SIEM y aplica tus propios controles de retención y conservación legal. Consulta Compliance API y eventos de auditoría.

8. Correlaciona el usuario o la cuenta de servicio, el host o ejecutor, el ID de conversación, el modelo, la versión del cliente, el perfil de permisos, la decisión de aprobación, el destino y el nombre de la herramienta.

Verifica

Ejecuta una sesión controlada que haga lo siguiente:

• Lee un archivo permitido.

• Intenta leer un archivo bloqueado.

• Ejecuta un comando permitido.

• Intenta realizar una solicitud de salida bloqueada.

• Solicita aprobación y recibe una denegación.

• Finaliza la sesión.

Resultados esperados por fuente de evidencia:

• OTel muestra eventos de ejecución y herramientas.

• Los hooks muestran el ciclo de vida de la sesión.

• Los registros del proxy muestran los destinos permitidos y bloqueados.

• La ingesta de Compliance recibe los registros compatibles.

• El SIEM correlaciona esos registros con el usuario o la carga de trabajo.

Revierte los cambios

Deshabilita el exportador y los hooks restaurando la configuración anterior. No elimines el registro independiente del proxy como parte de una reversión de la telemetría.

Límites

No prometas que la telemetría de Codex captura todos los argumentos de comandos, todos los bytes de salida o todos los paquetes de red. Documenta la cobertura de cada capa.

Usa esta receta cuando Codex no deba tener acceso a internet o deba acceder únicamente a destinos aprobados. Elige el procedimiento local o de la nube según el entorno que estés configurando, y ten presentes los distintos alcances de sus políticas.

Resultado previsto

Codex no tiene acceso a internet o accede únicamente a dominios aprobados, según la configuración que elijas. Los entornos de Codex Cloud (Legacy) también pueden restringir los métodos HTTP.

Configura Codex Cloud actual

1. Crea entornos separados para distintos niveles de confianza, como no-internet-review, approved-dependencies-build y cyber-lab.

2. En la configuración del entorno, deja desactivada la opción Permitir que Codex acceda a internet, salvo que el flujo de trabajo necesite acceso a internet.

3. Cuando se requiera acceso, activa Permitir que Codex acceda a internet. En Permitir dominios, elige Solo dominios personalizados y después añade los hosts exactos necesarios en Dominios permitidos adicionales.

4. Guarda y prueba los servicios durante la configuración inicial. Publica o vuelve a publicar el entorno y después prueba el acceso a destinos aprobados y no aprobados en una tarea nueva. Revisa los scripts de configuración por separado: fija las versiones de las dependencias, da preferencia a los servidores espejo aprobados y evita descargar ejecutables que no se hayan revisado.

Consulta Conectarse a servicios. Los ajustes actuales de Codex Cloud no proporcionan el selector de métodos HTTP de Legacy.

Configura Codex Cloud (Legacy)

1. Mantén el acceso del agente a internet Desactivado cuando no sea necesario. Legacy Cloud bloquea internet durante la fase del agente de forma predeterminada; los scripts de configuración siguen ejecutándose con acceso a internet para instalar dependencias.

2. Cuando el agente requiera acceso, establécelo en Activado con una lista de permitidos limitada. Empieza con Ninguno y añade dominios exactos.

3. Para flujos de trabajo de solo descarga, permite únicamente GET, HEAD y OPTIONS. Esto bloquea POST, PUT, PATCH, DELETE y otros métodos. Revisa los scripts de configuración por separado, porque la restricción de la fase del agente no controla su acceso a internet.

Consulta Acceso del agente a internet en Legacy. Estos ajustes preestablecidos y controles de métodos HTTP se aplican únicamente a Legacy Cloud.

Configura Codex local

1. En requirements.toml administrado por el administrador, define y selecciona el perfil de red aprobado, y restringe a los usuarios a ese perfil:

   default_permissions = "corp-build"

   [allowed_permission_profiles]
   "corp-build" = true

   [permissions.corp-build]
   description = "Workspace access with approved dependency destinations."
   extends = ":workspace"

   [permissions.corp-build.network]
   enabled = true
   allow_local_binding = false

   [permissions.corp-build.network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

2. Implementa el paquete de requisitos revisado usando Configuración administrada. Un perfil con nombre por sí solo está inactivo; default_permissions lo selecciona, y la lista de permitidos impide seleccionar otros perfiles.

3. Activa el proxy administrado por el administrador en el mismo paquete de requisitos para que se apliquen las restricciones de dominio y los usuarios no puedan ampliarlas. Implementa juntos el proxy y el perfil con acceso a la red; un perfil con acceso a la red sin un proxy activo concede acceso directo a la red sin aplicar sus reglas de dominio:

   Precaución: [experimental_network] es experimental y puede cambiar. Valídalo en cada versión de cliente local y sistema operativo compatibles antes de ampliar la implementación. La compatibilidad con Windows es limitada; no apliques esta política a los usuarios de Windows hasta haber probado su aplicación efectiva en tu entorno.

   [experimental_network]
   enabled = true
   managed_allowed_domains_only = true

   [experimental_network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

4. Mantén desactivada la vinculación de puertos locales, salvo que el flujo de trabajo la necesite. Configura por separado el acceso a destinos de redes privadas; permitir un dominio no aprueba por sí solo sus direcciones privadas. Consulta Requisitos de acceso a la red.

5. Configura por separado la búsqueda web, las aplicaciones, los MCP servers, la actividad del navegador y Codex Cloud. Las reglas del entorno aislado local no los controlan.

Verifica

• Envía una solicitud a un dominio aprobado y confirma que se completa correctamente.

• Envía una solicitud a un dominio no aprobado y confirma que se bloquea.

• Envía solicitudes a localhost, a una IP privada y a un endpoint de metadatos de la nube. Confirma que cada solicitud se bloquea, salvo que esté aprobada explícitamente.

• En Codex Cloud (Legacy), intenta realizar una solicitud POST a un dominio permitido. Confirma que la solicitud se bloquea cuando solo se permiten GET, HEAD y OPTIONS.

• Confirma que los registros del proxy o de la puerta de enlace contienen entradas tanto de las solicitudes permitidas como de las denegadas.

Revierte los cambios

Vuelve a establecer el entorno en Desactivado o restaura la política de dominios anterior. Evita volver a un acceso a internet sin restricciones.

Límites

Una elevación aprobada para salir por completo del entorno aislado puede eludir el proxy de comandos local. Prueba por separado los comandos normales del entorno aislado y los comandos con elevación aprobada antes de confiar en la restricción.

Un dominio permitido puede seguir alojando inyecciones de prompts, paquetes comprometidos o documentación insegura.

Usa esta receta cuando Codex necesite acceso a directorios de código fuente aprobados, mientras que los secretos, los archivos .env, las claves SSH y los repositorios ajenos deban permanecer fuera de su alcance. Abarca la restricción del acceso a archivos y la reducción del número de variables de entorno que contienen credenciales y se pasan a los comandos iniciados.

Resultado previsto

Codex puede trabajar en directorios de código fuente aprobados, pero no puede leer archivos que suelen contener secretos ni heredar un conjunto amplio de variables de entorno que contienen credenciales.

Configura

1. Define patrones de denegación de lectura en un perfil de espacio de trabajo:

   [permissions.corp-workspace]
   description = "Workspace edits with secret-bearing paths denied."
   extends = ":workspace"

   [permissions.corp-workspace.filesystem]
   glob_scan_max_depth = 6

   [permissions.corp-workspace.filesystem.":workspace_roots"]
   "**/.env*" = "deny"
   "**/*.pem" = "deny"
   "**/*.p12" = "deny"
   "**/id_*" = "deny"
   "**/.aws/**" = "deny"
   "**/.kube/**" = "deny"

2. Añade rutas exactas de denegación para los directorios de credenciales conocidos, las claves de firma, la configuración de producción y los repositorios vecinos.

3. En el /etc/codex/config.toml del sistema o el ~/.codex/config.toml del usuario, reduce las variables de entorno que se pasan a los comandos iniciados:

   [shell_environment_policy]
   inherit = "core"
   ignore_default_excludes = false

   [shell_environment_policy.filters]
   "AWS_*" = "exclude"
   "AZURE_*" = "exclude"
   "GITHUB_*" = "exclude"
   "*_TOKEN" = "exclude"
   "*_SECRET" = "exclude"
   "*_PASSWORD" = "exclude"

Este es un valor predeterminado configurable por el usuario, no un requisito obligatorio. Reduce las variables heredadas, pero no impide el acceso a archivos de credenciales, asistentes, contenido de inicio del shell u otras identidades. Consulta Configuración avanzada.

4. En requirements.toml administrado por el administrador, selecciona el perfil restringido y permite únicamente ese perfil. Los perfiles integrados no heredan sus denegaciones de acceso a archivos de secretos:

   default_permissions = "corp-workspace"

   [allowed_permission_profiles]
   "corp-workspace" = true
   ":danger-full-access" = false

5. Elige el flujo de credenciales para tu entorno de Cloud:

   • En Codex Cloud actual, usa Secretos de red para las credenciales enviadas a un servicio HTTPS permitido. Los programas reciben un marcador de posición, y el proxy lo sustituye por el valor real para los destinos aprobados en el puerto 443 durante la configuración inicial y las tareas. La credencial sin procesar no se coloca en un proceso o archivo local. Las variables de entorno directas están disponibles para los programas. Consulta Variables de entorno y secretos de red.
   • En Codex Cloud (Legacy), los secretos permiten la autenticación durante la configuración inicial y se eliminan antes de la fase del agente; las variables de entorno permanecen durante todo el chat. Consulta Entornos de Legacy Cloud.

6. Si el agente necesita autenticación, usa un intermediario independiente para proporcionar credenciales de corta duración limitadas al destino y la acción exactos. Consulta Configuración recomendada.

Verifica

Crea archivos señuelo inofensivos:

.env.test
test-key.pem
.aws/credentials
.kube/config

Después, pide a Codex que:

• Lee un archivo normal.

• Lee cada archivo señuelo.

• Busque secretos de forma recursiva.

• Muestre el entorno de sus comandos.

• Lee un repositorio vecino.

Resultado esperado: La lectura de un archivo normal se completa correctamente; los archivos denegados y los repositorios vecinos siguen siendo inaccesibles, y las variables excluidas no aparecen en el entorno de los comandos.

Revierte los cambios

Restaura el perfil anterior, pero conserva las denegaciones de acceso a archivos de secretos que sean de alta confianza mientras investigas los fallos del flujo de trabajo.

Límites

Las denegaciones del sistema de archivos no eliminan los secretos que ya se hayan pegado en prompts, incorporado a código fuente legible, devuelto mediante conectores o escrito en registros accesibles para el modelo.

Usa esta receta cuando acciones como git push, los despliegues, las migraciones de bases de datos y los comandos de CLI de la nube necesiten aprobación antes de ejecutarse. Decide qué comandos deben solicitar revisión y cuáles deben estar prohibidos; después, configura reglas para esos comandos.

Resultado previsto

Los comandos sensibles se detienen sistemáticamente para solicitar aprobación o están prohibidos, incluso cuando el modelo considera que son apropiados.

Configura

1. Decide qué comandos requieren una solicitud de aprobación y cuáles están prohibidos.

2. Añade reglas de comandos impuestas por el administrador:

   [rules]
   prefix_rules = [
     { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating shared Git state." },
     { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Require review before infrastructure changes." },
     { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Require review before Kubernetes changes." },
     { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Destructive removal is not permitted in managed Codex workflows." },
   ]

Las reglas de requisitos pueden exigir una solicitud de aprobación o prohibir un comando; no pueden permitirlo. Consulta Configuración administrada.

3. Para los perfiles de alto riesgo, añade una entrada de envoltorio de shell al mismo array prefix_rules cuando los envoltorios puedan ocultar un comando sensible:

   { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Review shell wrappers that could obscure sensitive commands." },

La entrada de envoltorio de shell genera muchas solicitudes; úsala de forma selectiva.

4. Si una persona debe aprobar los comandos, impón estos ajustes:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]

La revisión automática cambia quién realiza la revisión; no es una garantía de seguridad determinista. Consulta Revisión automática.

5. Envía los eventos PermissionRequest, de decisión sobre herramientas y de resultado de herramientas al sistema de procesamiento de seguridad.

Verifica

• Ejecuta git status. Resultado esperado: No aparece ninguna solicitud de aprobación.

• Ejecuta git push. Resultado esperado: Aparece una solicitud de aprobación.

• Ejecuta terraform apply. Resultado esperado: Aparece una solicitud de aprobación.

• Ejecuta kubectl delete pod test. Resultado esperado: Aparece una solicitud de aprobación.

• Ejecuta rm -rf test-directory. Resultado esperado: El comando está prohibido.

• Deniega una solicitud de aprobación. Resultado esperado: El comando no se ejecuta y la denegación queda registrada.

• Reinicia el cliente y repite las comprobaciones. Resultado esperado: La regla sigue aplicándose.

Revierte los cambios

Restaura el paquete de requisitos anterior. Restringe un patrón de tokens demasiado amplio en lugar de eliminar toda una clase de comandos sensibles.

Límites

Las reglas de prefijos no constituyen un motor completo de políticas del sistema operativo. Combínalas con aislamiento, cuentas del sistema operativo con privilegios mínimos, restricciones de red, IAM de la nube, protección de ramas, aprobaciones de despliegue y autorización de bases de datos.

Usa estas recetas de configuración: Restringir los perfiles de permisos y el acceso completo; Proteger secretos y repositorios ajenos; Exigir aprobación para comandos sensibles.

Los desarrolladores tienen acceso legítimo a producción, pero quieres que Codex ayude con el desarrollo sin realizar cambios en producción que no se hayan revisado.

• Define un perfil de espacio de trabajo aprobado e impón los perfiles y las políticas de aprobación permitidos. Distribuye estos ajustes como requisitos impuestos por el administrador para impedir que los usuarios los anulen.

• Ejecuta Codex con una identidad separada y con menos privilegios, o en un entorno que no pueda acceder a credenciales de escritura en producción ni obtenerlas. Los desarrolladores pueden conservar su acceso a producción mediante un flujo de trabajo autorizado independiente.

• Minimiza las variables de entorno que se pasan a los comandos iniciados. Si el agente necesita autenticación, usa un intermediario independiente para proporcionar credenciales de corta duración limitadas al destino y la acción exactos.

• Decide qué comandos requieren una solicitud de aprobación y cuáles están prohibidos. Exige que una persona apruebe determinados comandos de alto impacto, como git push, terraform apply, los cambios en Kubernetes y las migraciones de bases de datos; prohíbe los comandos que nunca deban ejecutarse.

• Mantén aplicados de forma independiente de Codex el IAM de producción, la protección de ramas y las aprobaciones de despliegue.

Restringe los perfiles de permisos y exige una revisión humana

En requirements.toml administrado por el administrador, permite los perfiles integrados de espacio de trabajo y de solo lectura, y exige la revisión del usuario para las acciones que necesiten aprobación:

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

El perfil de espacio de trabajo permite trabajar en el espacio de trabajo dentro de su entorno aislado; el perfil de solo lectura está disponible para trabajos de alcance más limitado. Los perfiles de acceso completo no figuran en la lista de permitidos.

Establece approval_policy = "on-request" en la configuración del cliente si este necesita una opción compatible explícita. on-request permite solicitar aprobación cuando sea necesario; no la solicita para cada comando. Añade reglas explícitas para las acciones que necesiten revisión y conserva una autorización de producción independiente.

Las listas administradas de perfiles permitidos requieren Codex 0.138.0 o posterior; usa y prueba los requisitos documentados del modo de aislamiento heredado para los clientes anteriores.

Reinicia cada cliente piloto, verifica que el perfil aprobado funcione y comprueba que se rechace un perfil de acceso completo no permitido.

Separa la identidad de Codex de las credenciales de producción

En tu sistema de gestión de dispositivos o de aprovisionamiento de entornos de desarrollo, crea un usuario, contenedor o host de desarrollo dedicado a Codex con acceso únicamente al código fuente y a los servicios de desarrollo que necesite. No montes los archivos de credenciales de producción, los asistentes de tokens ni los llaveros del desarrollador en ese entorno, e impide que la identidad adquiera roles de escritura en producción.

Si el agente necesita acceso a servicios, configura el intermediario de credenciales de tu organización para que emita credenciales de corta duración restringidas al recurso y a la acción de desarrollo. El desarrollador puede usar su identidad habitual mediante un flujo de trabajo de producción autorizado independiente.

Por ejemplo, en AWS IAM, abre Roles, selecciona el rol de desarrollo de Codex y, en Permisos, añade una política en línea revisada como esta, sustituyendo la cuenta y el rol por los tuyos:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAssumeExampleProductionRole",
      "Effect": "Deny",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::111122223333:role/ExampleProductionRole"
    }
  ]
}

Este ejemplo deniega los intentos de asumir el rol indicado, pero no deniega los intentos de asumir otros roles. Elimina también los permisos directos de producción, restringe otros roles y fuentes de credenciales de producción, y revisa las políticas de confianza y los controles a nivel de la organización.

Prueba el rol de desarrollo con permisos representativos de desarrollo y producción sin realizar cambios en producción. Consulta Ejemplos de políticas de roles de AWS IAM.

Minimiza el entorno del shell

En /etc/codex/config.toml para una configuración inicial de todo el sistema, o en ~/.codex/config.toml para un usuario, configura qué variables de entorno heredan los comandos que se ejecutan:

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

Este es un valor predeterminado configurable, no una barrera de protección de credenciales obligatoria. La configuración del usuario, el inicio del shell o sus instantáneas, los asistentes de credenciales y otras fuentes de credenciales pueden seguir exponiendo credenciales.

En requirements.toml, usa las siguientes restricciones opcionales para deshabilitar los shells de inicio de sesión y las instantáneas del shell si son compatibles con tu flujo de trabajo:

allow_login_shell = false

[features]
shell_snapshot = false

Prueba esta configuración en un entorno piloto, ya que algunos flujos de trabajo dependen de la inicialización del shell de inicio de sesión.

Inicia Codex con variables sintéticas inocuas que coincidan con los filtros e inspecciona el entorno de un comando ejecutado; verifica también que se rechace una solicitud de shell de inicio de sesión si está deshabilitado. Verifica de forma independiente que la identidad de ejecución no pueda acceder a credenciales reales de producción. Consulta Política del entorno del shell.

Solicita aprobación para determinados comandos de alto impacto

Agrega reglas de requisitos para los comandos que utiliza tu organización. Por ejemplo:

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
  { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Review infrastructure changes." },
  { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Review cluster changes." },
  { pattern = [{ token = "python3" }, { token = "manage.py" }, { token = "migrate" }], decision = "prompt", justification = "Review database migrations." },
]

Usa forbidden para un comando que nunca deba ejecutarse; sustituye o agrega patrones para las herramientas de despliegue y migración que realmente utiliza.

Estas reglas comparan prefijos de comandos y no abarcan todas las acciones equivalentes. Prueba por separado las rutas absolutas, los envoltorios, los órdenes alternativos de argumentos, otros clientes y otras herramientas.

En un destino desechable, ejecuta un comando normal, solicita una acción de la lista, deniega la solicitud de aprobación y verifica que la acción no se haya ejecutado. Consulta Aplicación de reglas de comandos.

Exige aprobaciones de repositorios y despliegues fuera de Codex

En tu plataforma de control de versiones, protege las ramas de producción, como main: exige cambios revisados y las aprobaciones y comprobaciones de estado necesarias, y revisa qué roles pueden eludir esos requisitos. Configura la aprobación de despliegues en el sistema de despliegue correspondiente y los privilegios de la base de datos en la propia base de datos.

Usa un repositorio desechable para verificar que un cambio revisado funciona y que se rechaza un envío directo no autorizado. Estos controles se aplican independientemente de si la acción se solicitó a través de Codex.

Verifica

En un destino de prueba desechable:

• Ejecuta una tarea normal del espacio de trabajo. Resultado esperado: la tarea se completa correctamente.

• Intenta ejecutar un comando sensible representativo y deniega la solicitud de aprobación. Resultado esperado: el comando denegado no se ejecuta.

• Verifica que la identidad de Codex no pueda obtener acceso de escritura en producción.

• Reinicia el cliente y repita el proceso.

Límites

Las reglas de prefijos no constituyen un motor completo de políticas del sistema operativo. Combínalas con aislamiento, cuentas del sistema operativo con privilegios mínimos, restricciones de red, IAM en la nube, protección de ramas, aprobaciones de despliegues y autorización de bases de datos.

Utiliza estas recetas de configuración: Proteger secretos y repositorios ajenos; Restringir los destinos de red; Permitir solo MCP servers aprobados; Exigir aprobación para comandos sensibles.

Los desarrolladores utilizan Codex con repositorios internos, y quieres reducir el riesgo de que se envíe código a un repositorio público, un fragmento de código público u otro destino no aprobado.

• Agrega rutas exactas de denegación para directorios de credenciales conocidos y repositorios ajenos, y minimiza las variables de entorno que se pasan a los comandos ejecutados.

• Cuando se requiera acceso del agente a internet, usa una lista restringida de dominios aprobados. Permite solo nombres e identidades de MCP servers aprobados y exige revisión para determinados comandos de publicación o deniégalos, como git push.

• Usa hooks y permisos de control de versiones, políticas para repositorios públicos y fragmentos de código, y controles de prevención de pérdida de datos adecuados para tu organización.

Deniega el acceso a repositorios ajenos y archivos de credenciales

En requirements.toml, administrado por el administrador, agrega las rutas exactas que el agente local no debe leer:

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config", "/work/unrelated-repository"]

Sustituye los ejemplos por rutas presentes en tus dispositivos administrados. Esta denegación administrada se aplica a todos los perfiles de permisos permitidos; una denegación configurada únicamente dentro de un perfil personalizado no protege a los usuarios que seleccionan otro perfil. Prefiere rutas exactas conocidas y prueba cualquier patrón glob en los niveles de profundidad que necesites.

En Windows nativo, deny_read administrado abarca las herramientas de acceso directo a archivos, pero por sí solo no impide las lecturas desde subprocesos del shell; usa también identidades del sistema operativo y listas de control de acceso a archivos.

Crea archivos señuelo inocuos en las ubicaciones denegadas. Con cada perfil permitido, verifica que se denieguen tanto las lecturas directas como las realizadas desde el shell y que se pueda leer un archivo de código fuente aprobado. Consulta Requisitos administrados de denegación de lectura.

Minimiza las variables del shell que contienen credenciales

En /etc/codex/config.toml o ~/.codex/config.toml, define un entorno heredado restringido:

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

Esta configuración reduce las variables heredadas, pero el usuario puede configurarla y no impide el acceso a archivos de credenciales, asistentes, contenido de inicio del shell u otras identidades.

Cuando corresponda, un administrador también puede agregar estas restricciones a requirements.toml y probarlas en un entorno piloto para evaluar su efecto en los flujos de trabajo de los desarrolladores:

allow_login_shell = false

[features]
shell_snapshot = false

Prueba con variables señuelo sintéticas y una identidad de ejecución independiente con privilegios mínimos. No uses credenciales reales. Consulta Política del entorno del shell.

Permite solo destinos de red aprobados para los comandos locales

Si los comandos locales aislados necesitan acceso a la red, incorpora tanto el perfil como la configuración del proxy administrado que se muestran a continuación en requirements.toml y sustituye los dominios por los puntos de conexión aprobados:

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"
"registry.corp.example" = "allow"

El perfil con acceso a la red proporciona al comando aislado una vía de acceso a la red, mientras que el proxy administrado restringe sus destinos. Impleméntalos juntos; un perfil con acceso a la red sin el proxy administrado previsto no aplica las mismas restricciones de destino. Si no se necesita acceso a internet, mantén deshabilitado el acceso a la red.

No combines la tabla canónica domains con las opciones heredadas allowed_domains o denied_domains; migra y prueba la política existente.

Reinicia el cliente y verifica que un punto de conexión aprobado funcione y que uno no aprobado quede bloqueado.

Esta configuración es experimental; valida la compatibilidad del sistema operativo y del cliente, y configura por separado el acceso a redes privadas si un host aprobado se resuelve en una dirección privada. Una elevación aprobada a acceso completo fuera del entorno aislado puede eludir el proxy de comandos.

Este control de red para comandos locales no abarca por sí solo las búsquedas web, las aplicaciones, los MCP servers, la actividad del navegador ni los entornos en la nube, que necesitan políticas independientes. Un dominio de alojamiento aprobado también puede contener repositorios públicos o fragmentos de código públicos, por lo que una lista de destinos permitidos por sí sola no protege el contenido. Consulta Requisitos de acceso a la red.

Configura por separado la red del entorno en la nube

En la interfaz actual de Codex Cloud, abre la configuración del entorno. Mantén desactivada la opción Permitir que Codex acceda a internet. Si necesitas acceso a internet, actívala y elige Solo dominios personalizados, agrega los hosts exactos necesarios en Dominios permitidos adicionales y, a continuación, guarda la configuración, publica o vuelve a publicar el entorno y prueba una tarea nueva.

Revisa de forma independiente la autenticación y las capacidades de los servicios.

La versión heredada de Codex Cloud utiliza una configuración independiente de acceso del agente a internet por entorno, con controles para los dominios y métodos HTTP permitidos; los scripts de configuración tienen su propio comportamiento de acceso.

Prueba la versión del entorno que realmente utiliza. Consulta Conectarse a servicios y Configuración heredada de internet.

Restringe los MCP servers y solicita aprobación antes de los envíos de Git

Permite solo identidades de MCP servers locales aprobadas en requirements.toml. Por ejemplo:

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

Configura el servidor real por separado en el config.toml del usuario o de valores predeterminados administrados, utilizando el nombre y la URL coincidentes y la autenticación que requiera tu servidor:

[mcp_servers.internal]
url = "https://mcp.corp.example/mcp"

El requisito solo permite un servidor coincidente y no lo crea. Revisa el acceso y las herramientas del propio servidor.

Verifica que el servidor aprobado pueda conectarse y que no se permita un servidor con un nombre o una URL diferentes.

Agrega una regla de comandos administrada para solicitar una revisión antes de un comando de publicación representativo:

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review the destination before publishing." },
]

Combina esto con allowed_approval_policies = ["on-request"] y allowed_approvals_reviewers = ["user"] como requisitos de nivel superior si una persona debe realizar la revisión.

Deniega un envío de prueba y confirma que no se ejecuta.

La coincidencia de prefijos no abarca todos los envoltorios, clientes de API, aplicaciones ni vías de publicación alternativas.

Restringe la publicación pública con controles de control de versiones y DLP

En tu plataforma de control de versiones, restringe la creación de repositorios públicos y limita quién puede cambiar la visibilidad de los repositorios, cuando sea posible. Revisa los permisos de omisión de los usuarios con privilegios. Comprueba por separado las cuentas personales, los fragmentos de código, las organizaciones externas y el acceso mediante tokens: la configuración de la organización no rige todos los destinos.

En el repositorio correspondiente, exige cambios revisados y revisa la protección de ramas y los permisos de omisión.

En la consola de DLP de tu organización, configura una política piloto para contenido sensible de código fuente y los canales de carga o de repositorios que tu producto de DLP realmente abarque; establece la acción de bloqueo y prueba con un marcador sintético inerte.

Cuando la plataforma de control de versiones admita controles del lado del servidor, configura y aplica hooks revisados para los repositorios que reciben envíos.

Usa destinos de prueba autorizados y confirma el bloqueo antes de cualquier publicación.

Verifica

• Crea señuelos inocuos y confirma que fallen los intentos de leer archivos denegados.

• Si el acceso a la red está habilitado, comprueba que un destino aprobado funcione y que uno no aprobado quede bloqueado; de lo contrario, verifica que las solicitudes de red estén bloqueadas.

• Con un marcador inocuo y cuentas o destinos de prueba desechables, verifica que los intentos representativos de publicar contenido públicamente se bloqueen antes de la publicación.

Límites

Un dominio permitido puede seguir alojando contenido público. Configura por separado las búsquedas web, las aplicaciones, los MCP servers, la actividad del navegador y Codex Cloud; las reglas de aislamiento locales no los controlan.

Utiliza estas recetas de configuración: Restringir los perfiles de permisos y el acceso completo; Permitir solo MCP servers aprobados; Restringir los destinos de red; Proteger secretos y repositorios ajenos; Exigir aprobación para comandos sensibles.

Quieres que las restricciones que rigen Codex sigan vigentes cuando trabaje en un repositorio o cuando un usuario cambie la configuración local.

• Distribuye las restricciones compatibles de permisos, aprobaciones, MCP, red y comandos como requisitos impuestos por el administrador.

• Instala los scripts de hooks en un directorio administrado por el administrador y usa exclusivamente hooks administrados si deben ignorarse los hooks del usuario, del proyecto y de los plugins.

• Protege los archivos de políticas y la ruta de distribución de la configuración con controles del sistema operativo y de administración de dispositivos. Ejecuta Codex sin los privilegios necesarios para cambiar esas protecciones.

• Revisa la configuración efectiva de cada cliente y entorno incluido en el alcance.

Impón los perfiles, las aprobaciones, las identidades de servidor y los comandos permitidos

Incorpora la configuración revisada en el requirements.toml administrado por el administrador, en lugar de depender de la configuración editable de un usuario o repositorio. Por ejemplo:

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
]

Este ejemplo permite dos perfiles, exige un revisor humano cuando se necesita aprobación, permite una identidad MCP coincidente y solicita aprobación para un prefijo de comando concreto.

Configura el propio MCP server por separado y agrega los demás patrones de comandos sensibles de la organización. Agrega restricciones globales de archivos y restricciones de red cuando sea necesario; los requisitos limitan las opciones compatibles, pero no pueden sustituir los controles de identidad, servicios y destinos externos a Codex.

Las listas de perfiles administrados permitidos requieren Codex 0.138.0 o posterior.

En un cliente piloto, intenta seleccionar un perfil no permitido, cambiar una opción restringida del usuario o del proyecto y usar una identidad MCP que no esté en la lista de permitidas; verifica que cada intento se rechace o siga sujeto a restricciones después del reinicio. Deniega la aprobación de un comando de prueba y verifica que el comando no se ejecuta.

Agrega restricciones administradas del sistema de archivos y de la red

Para denegar el acceso a archivos locales sensibles en todos los perfiles permitidos, agrega la siguiente tabla a requirements.toml y sustituye los ejemplos por las rutas de tu organización:

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config"]

Cuando los comandos locales aislados necesiten acceso a la red, define conjuntamente un perfil permitido con acceso a la red y los destinos administrados:

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"

Elige esta política de perfiles en lugar del valor predeterminado anterior :workspace, o combina deliberadamente ambos nombres de perfil; no pegues claves ni tablas duplicadas. Si los comandos no necesitan la red, mantenla deshabilitada.

Verifica las rutas exactas denegadas con archivos inocuos y comprueba los destinos aprobados y no aprobados.

En Windows nativo, usa también listas de control de acceso a archivos, ya que deny_read administrado por sí solo no abarca las lecturas desde subprocesos del shell.

La red de comandos locales no rige otros clientes, aplicaciones, conectores ni la ejecución en la nube.

Instala y aplica hooks administrados por el administrador

Pide a un administrador que instale un programa de hook revisado en un directorio administrado por root, como /etc/codex/hooks/pre_tool_use_policy.py, e impida que el usuario de Codex modifique el archivo o su directorio. En requirements.toml, habilita los hooks e ignora los hooks del usuario, del proyecto, de la sesión y de los plugins:

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/etc/codex/hooks"

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "/usr/bin/python3 /etc/codex/hooks/pre_tool_use_policy.py"
timeout = 30
statusMessage = "Checking managed Bash command"

El requisito registra el hook, pero no lo instala. Para una prueba de integración local en macOS, guarda lo siguiente como pre_tool_use_policy.py y pide a un administrador que lo instale con los comandos que se muestran a continuación.

Solo bloquea el marcador sintético; sustitúyelo por una política revisada específica de la organización antes de confiar en él. Confirma que /usr/bin/python3 exista en el destino y ajusta la ruta del intérprete si es necesario:

import json
import sys

event = json.load(sys.stdin)
command = event.get("tool_input", {}).get("command", "")
if "CODEX_HOOK_TEST_DENY" in command:
    print("Synthetic test command blocked by managed hook.", file=sys.stderr)
    sys.exit(2)

sudo install -d -o root -g wheel -m 755 /etc/codex/hooks
sudo install -o root -g wheel -m 644 ./pre_tool_use_policy.py /etc/codex/hooks/pre_tool_use_policy.py

Reinicia el cliente local y, a continuación:

• Confirma que se ejecuta un comando Bash inocuo.

• Confirma que se bloquee un comando que contenga CODEX_HOOK_TEST_DENY.

• Verifica que el usuario de Codex no pueda cambiar la política ni sus dependencias.

allow_managed_hooks_only omite todos los hooks no administrados del usuario, del proyecto, de la sesión y de los plugins, y puede afectar a otros flujos de trabajo.

El comparador de Bash no abarca todas las herramientas ni las entradas proporcionadas posteriormente a un proceso existente; los errores, los tiempos de espera agotados o las respuestas de hooks con formato incorrecto pueden permitir que continúe una llamada a una herramienta.

Work orquestado en la nube utiliza otros controladores de hooks compatibles. Mantén protecciones independientes del sistema operativo y de los servicios. Consulta Hooks administrados y Comportamiento de los hooks.

Protege la política y su distribución

En macOS, un administrador puede desplegar un archivo de requisitos revisado y combinado en un directorio principal propiedad de root e impedir que el usuario de Codex escriba en el archivo:

sudo install -d -o root -g wheel -m 755 /etc/codex
sudo install -o root -g wheel -m 644 ./requirements.reviewed.toml /etc/codex/requirements.toml
ls -ld /etc/codex
ls -l /etc/codex/requirements.toml

En Linux, usa el grupo de administradores adecuado; en Windows, protege el directorio ProgramData y el archivo con listas de control de acceso administradas por el administrador. Restringe quién puede cambiar la política de MDM o de la nube, revisa los cambios y conserva una copia para revertirlos.

Con una cuenta piloto sin privilegios de administrador, verifica que la cuenta no pueda modificar la política, el directorio principal ni el programa de hook administrado; prueba una configuración menos restrictiva del usuario o del proyecto, reinicia Codex y verifica que el comportamiento impuesto persista.

Prueba cada cliente y entorno incluido en el alcance, en lugar de suponer que todos los clientes cargan la misma política.

Verifica

Con una identidad de prueba sin privilegios de administrador:

• Intenta editar la política administrada. Resultado esperado: el archivo administrado no se puede modificar.

• Intenta debilitar una restricción mediante la configuración del usuario o del proyecto. Resultado esperado: la configuración menos restrictiva se rechaza o sigue sujeta a restricciones.

• Reinicia el cliente y verifica que las restricciones sigan aplicándose.

Límites

Un usuario o agente con suficientes privilegios de administrador en el host puede cambiar las protecciones circundantes. La configuración editable por el usuario, por sí sola, no sustituye los requisitos administrados por el administrador.