Agent Security

Usa Agent Security en la consola de administración para gestionar las políticas y la configuración. Sustituye a Políticas y configuración. Su despliegue es independiente del acceso a computadoras locales para Work y dots.

Cuando se migran las políticas de nube heredadas que cumplen los requisitos, su configuración se transfiere a Global y se conservan las asignaciones y el orden de las políticas. Revisa las políticas migradas en Agent Security. El acceso a computadoras locales se activa por separado para Work y para dots.

Dónde se aplica la configuración

Cada política parte de una configuración base de Global. Las anulaciones por entorno cambian los ajustes de ejecución compatibles para Local o Codex Cloud. Cuando un entorno no tiene una anulación, hereda los ajustes de Global aplicables de esa política.

• Global: establece controles del orquestador, incluidas las aprobaciones y la búsqueda web, y ajustes de ejecución compartidos.

• Local: ajusta la configuración de ejecución compatible para el trabajo que se ejecuta en una computadora conectada.

• Codex Cloud: ajusta la configuración de ejecución compatible para las tareas de Codex en la nube. Puedes configurar estas políticas antes de habilitar Codex Cloud, pero solo se aplican después de habilitar Codex Cloud en la página de permisos. Work Cloud tiene permisos de capacidades independientes, descritos en Cómo se aplica Agent Security a Work Cloud.

Establece una configuración base y añade ajustes por entorno

1. Abre Agent Security y revisa las políticas, las asignaciones y el orden existentes de Global. Compáralos con los controles previstos por tu organización. Esta revisión no habilita el acceso a computadoras locales con Work Cloud.

2. Revisa Requisitos y Valores predeterminados por separado. Los requisitos establecen límites que los usuarios no pueden anular. Los valores predeterminados establecen valores iniciales dentro de esos límites.

3. Mantén los controles del orquestador en Global. Entre ellos se incluyen los requisitos de aprobación, los modos de búsqueda web permitidos y los controles de herramientas administradas.

4. Añade ajustes de entorno de Local o Codex Cloud para los controles de ejecución compatibles, como el aislamiento, los permisos del sistema de archivos y las redes de ejecución administradas. Usa una anulación específica del sistema operativo cuando necesites ese ámbito.

5. Guarda la política y revisa los mensajes de validación sobre los ajustes que hayas introducido.

Elige los controles y los campos de configuración

El orquestador coordina la tarea. Un ejecutor es la computadora o el contenedor en la nube que realiza un paso de ejecución. Configura los controles del orquestador en Global. Los ajustes requirements.toml del entorno solo admiten controles de ejecución. Los ajustes del orquestador, como la política de aprobación y la búsqueda web, permanecen en Global y no se pueden anular desde un entorno.

Controles del orquestador

Configura estos controles en Global. Para Work con acceso local y dots, la política de Global compatible se aplica a través del orquestador compartido en la nube cuando la política administrada está habilitada. Las anulaciones por entorno se aplican a los ajustes de ejecución compatibles y no pueden anular los controles del orquestador. De los requisitos de aprobación, búsqueda web, aplicaciones, MCP, plugins y reglas que se indican a continuación, solo Políticas de aprobación permitidas y Modos de búsqueda web permitidos tienen controles específicos en la interfaz de Agent Security. Configura los demás campos mediante TOML.

Hooks en el acceso a computadoras locales con Work Cloud

Cuando la política administrada y los hooks remotos están habilitados, Work Cloud con acceso local y dots usan hooks MCP remotos administrados por el administrador en el orquestador en la nube. Configura los controladores mcp_tool en requirements.toml de Global. Work Cloud sin acceso local y las cuentas personales no usan estos hooks empresariales. Los controladores de comandos/shell, prompts y agentes; los hooks de la configuración local, plugins o directorios locales; los hooks con ámbito de entorno; y los hooks MCP de SessionEnd no son compatibles con la orquestación en la nube, incluso cuando las herramientas se ejecutan localmente. Cuando tanto la orquestación como la ejecución son locales, los hooks compatibles existentes siguen funcionando en los hilos exclusivamente locales de Work y Codex. Los administradores pueden seguir configurando hooks administrados compatibles en Agent Security para esos flujos de trabajo.

Antes de depender de estos hooks, prueba la conectividad de las llamadas de retorno, los eventos requeridos y el comportamiento ante fallos. Una denegación explícita compatible puede bloquear una acción, pero un error de llamada de retorno de PreToolUse, un tiempo de espera agotado o una respuesta mal formada pueden hacer que el hook falle sin bloquear la herramienta. Los hooks MCP no proporcionan un registro de auditoría completo de Compliance API.

Global también contiene ajustes del escritorio y del cliente. Algunos de estos ajustes solo se aplican a la aplicación de escritorio. Configurar un ajuste en Global no significa que se aplique en todas partes. Consulta la Referencia de configuración para conocer los usos compatibles de cada campo.

Controles de ejecución (ejecutor)

Estos campos controlan cómo se ejecuta el trabajo en una computadora o en un contenedor en la nube. Establece los valores compartidos en Global. Usa anulaciones de Local o Codex Cloud para los ajustes compatibles que deban ser distintos en ese entorno.

La tabla muestra qué grupos de campos admiten anulaciones por entorno. Las opciones compatibles dentro de cada grupo pueden variar según la plataforma y algunos requisitos se combinan entre políticas en lugar de reemplazarse entre sí. Consulta la Referencia de configuración para conocer los valores compatibles y Configuración administrada para conocer las excepciones de red.

En las vías de ejecución administradas compatibles de Codex Cloud, los requisitos de Agent Security limitan el acceso de los comandos a la red. Los ajustes de Internet del entorno de Codex Cloud se aplican por separado. Un dominio permitido en Agent Security no anula una restricción de los ajustes de Internet del entorno de Cloud. Estos controles de red para comandos no deshabilitan por sí solos la búsqueda web alojada, las aplicaciones ni MCP. ChatGPT Work Cloud tiene permisos de capacidades independientes y no hereda estos requisitos de Agent Security.

Una lista administrada de comandos permitidos se aplica a los comandos que usan el proxy administrado. Cuando la política permite la elevación completa fuera del entorno aislado y esta se aprueba, esa ejecución puede omitir el proxy de comandos. Un permiso de red limitado es distinto de la elevación completa fuera del entorno aislado. Configura los requisitos obligatorios de aprobación y aislamiento para el límite previsto y prueba tanto los comandos ordinarios como los elevados.

Configura las redes en la interfaz

1. Abre Consola de administración > Agent Security. Selecciona una política y elige Global, Local o Codex Cloud. Usa Global para la configuración base compartida y una anulación por entorno para las diferencias compatibles.
2. Abre Requisitos y activa Administrar redes. Añade las entradas de dominio necesarias y elige Permitir o Denegar para cada una. Activa Permitir solo los dominios añadidos por administradores si la configuración ordinaria de los usuarios y las aprobaciones por dominio no deben ampliar la lista de dominios permitidos del proxy administrado.
3. Revisa los ajustes efectivos y las reglas heredadas antes de guardar. Los ajustes de entorno vacíos heredan Global en lugar de borrar su configuración. Comprueba por separado la conectividad local/privada para Codex Cloud. Desactivar Administrar redes no equivale a desactivar el acceso a Internet del entorno de Cloud.
4. Para Codex Cloud, comprueba también los ajustes de acceso a Internet, destinos y métodos del entorno. Guarda y prueba una solicitud que deba permitirse y otra que deba bloquearse. Prueba por separado cualquier elevación completa permitida fuera del entorno aislado.

Sin destinos permitidos efectivos

Cuando Administrar redes y Permitir solo los dominios añadidos por administradores están activados, los comandos administrados ordinarios necesitan destinos permitidos efectivos. Si no se configuran ni heredan entradas de Permitir, esos comandos no tienen destinos permitidos. Una política que solo contiene denegaciones no permite implícitamente el resto de Internet. Añade las entradas de Permitir necesarias y comprueba las reglas heredadas antes de guardar. Esta restricción se aplica al proxy de comandos administrado, no a todas las herramientas ni a la elevación completa aprobada fuera del entorno aislado.

Conectividad local/privada de Codex Cloud

Un valor explícito de Desactivado para la conectividad local/privada puede impedir que Codex Cloud acceda a su proxy ascendente, incluso cuando el dominio de destino está permitido. Comprueba el valor final de allow_local_binding e identifica qué política o ajuste lo proporciona. En la vía de proxy de Cloud compatible, el valor predeterminado es true solo cuando ningún requisito aplicable, perfil de red seleccionado o ajuste de función del proxy proporciona un valor. Un false heredado sigue contando como ajuste explícito. Cuando sea compatible, establece una anulación de Cloud de mayor prioridad para cambiar este valor en Codex Cloud sin cambiar el valor de Global que usa Local. Esto no añade entradas de dominio de Permitir. Verifica la compatibilidad del ejecutor antes de depender de la anulación. No apliques este valor predeterminado de Cloud a Local.

Valores predeterminados del entorno

El editor de Valores predeterminados usa campos de config.toml, que son distintos de las restricciones de requirements.toml. Los valores predeterminados de entorno de nivel superior compatibles son:

• Comportamiento del shell: allow_login_shell y shell_environment_policy.

• Aislamiento y permisos: sandbox_mode, sandbox_workspace_write, default_permissions y permissions.

• Ejecución de Windows: windows.

Un valor predeterminado no anula un requisito obligatorio. Mantén en Global los valores predeterminados del orquestador, incluidos los ajustes de aprobación y búsqueda web.

Comprende cómo se combinan las políticas

• Entre políticas, una política de mayor prioridad prevalece sobre otra de menor prioridad, incluso cuando la de menor prioridad es más específica.

• Dentro de una política, los ajustes de ejecución compatibles se resuelven en este orden: una anulación de entorno específica del sistema operativo, una anulación de entorno para todos los sistemas operativos y, por último, Global.

• Para la ejecución local, MDM y los requisitos heredados de dispositivos administrados tienen prioridad sobre Agent Security. El archivo de requisitos del sistema del dispositivo tiene una prioridad inferior a Agent Security.

Para una misma regla de dominio dentro de una política, una anulación de entorno del administrador puede permitir un dominio denegado en Global o denegar un dominio permitido en Global. Sin una anulación por entorno, se hereda la regla de Global. Otras reglas efectivas de Denegar o controles de acceso aún pueden bloquear una solicitud.

Estos resultados comparan la misma clave de dominio dentro de una política, sin que una política de mayor prioridad cambie el resultado. Un valor de mayor prioridad reemplaza la misma clave. Las demás claves heredadas se conservan. Una regla de Permitir no evita una regla de Denegar distinta que también coincida, como un comodín heredado. Un mapa de entorno vacío no borra las reglas heredadas.

Cómo se aplica Agent Security a Work Cloud

Configura Uso del navegador en la nube y Acceso a la red en la nube en Consola de administración > Permisos y roles > Capacidades del espacio de trabajo > Capacidades de computadoras en la nube. Estas capacidades compartidas están disponibles para Work Cloud y dots y pueden configurarse de forma independiente del acceso a Work Cloud. Una tarea de Work sigue necesitando acceso a Work y permiso para usar cada capacidad que requiera. Revisa por separado el acceso al navegador y el acceso a la red desde código o shell. Deshabilitar uno no deshabilita automáticamente el otro.

Los contenedores de Work Cloud y las computadoras en la nube de dots usan su propia configuración y sus propios requisitos de ejecución, en lugar del paquete de entorno administrado que usan otros tipos de ejecutores. Las restricciones locales de archivos y red no se aplican automáticamente a estas computadoras en la nube. La política compatible del orquestador de Global tiene un ámbito independiente. Una política de Global o una anulación de Codex Cloud no configura los permisos de capacidades compartidas en la nube. Revisa esos permisos por separado.

Comprueba el valor predeterminado del espacio de trabajo, todos los roles asignados directamente y mediante grupos, y las restricciones aplicadas por separado, como Lockdown Mode, al verificar el acceso efectivo de un miembro.

Antes de habilitar Permitir el acceso a computadoras locales en Work Cloud, revisa la configuración base de Global y comprueba la compatibilidad con los controles de los que depende tu organización. Usar Codex localmente en la aplicación de escritorio de ChatGPT no es un requisito previo. Si enforce_residency está habilitado en cualquier política de nube, Permitir el acceso a computadoras locales se deshabilita tanto para Work como para dots. Esta salvaguarda no configura la residencia del espacio de trabajo ni deshabilita por sí sola Work Cloud o dots. Consulta Acceso a computadoras locales para Work Cloud y dots para conocer los pasos de configuración independientes, los requisitos de elegibilidad y el comportamiento de la conexión.

API de políticas y Terraform

Usa la API de políticas para administrar los ajustes de Global. Para administrar los ajustes de Local o Codex Cloud, usa la interfaz de Agent Security. Los flujos de trabajo existentes de la API de Global siguen disponibles después de la migración. Prueba tus scripts e integraciones de Terraform y confirma que las asignaciones y el orden de las políticas no hayan cambiado.

La migración de políticas no cambia la sincronización de pertenencia de SCIM ni los roles RBAC.

Guías relacionadas

• Configuración administrada: distribución de políticas, precedencia y comportamiento de combinación específico de cada campo.

• Referencia de configuración: definiciones de campos y compatibilidad con Work.

• Acceso a computadoras locales para Work Cloud y dots: requisitos previos y pasos de configuración.

• Roles y permisos del espacio de trabajo: acceso a las capacidades de Work y Codex.