Configuración recomendada

Los controles de seguridad adecuados para un flujo de trabajo de ciberseguridad dependen del modelo, de las acciones que pueda realizar, de los sistemas a los que pueda acceder y de la sensibilidad de los datos implicados.

Para la mayoría de los flujos de trabajo de Daybreak Blue, las prácticas de seguridad existentes de su organización —como los controles de acceso, la protección de credenciales y la revisión de acciones sensibles— pueden ser suficientes.

Los flujos de trabajo de Daybreak Red, las pruebas de seguridad autónomas y las actividades que impliquen sistemas de producción, datos sensibles o herramientas externas pueden requerir medidas de protección más estrictas. Las recomendaciones siguientes están dirigidas principalmente a estos escenarios de mayor riesgo.

Trusted Access regula el acceso aprobado a los modelos, pero no configura su entorno ni aplica límites a los sistemas y acciones aprobados. Su equipo debe configurar controles adecuados de aislamiento, permisos, revisión, supervisión y vigilancia humana. Parta de la premisa de que el modelo, sus herramientas y todos los sistemas conectados podrían verse comprometidos y, a continuación, configure el entorno para que aun así no puedan acceder a sistemas no autorizados, exponer credenciales, desactivar medidas de protección ni mantener su presencia una vez finalizado el trabajo.

Aísle el entorno

Ejecute los trabajos de seguridad ofensiva en un laboratorio o entorno aislado específico. Comience sin acceso sin restricciones a Internet ni acceso a sistemas de producción sensibles, redes corporativas, cargas de trabajo no relacionadas o interfaces de administración del host. Mantenga fuera de alcance los secretos, las credenciales, el acceso persistente y los cambios duraderos en el sistema, salvo que el trabajo aprobado los requiera y autorice explícitamente.

Para trabajos de mayor riesgo o con medidas de protección reducidas, utilice un entorno nuevo y muy aislado en cada intento. Separe los recursos informáticos, el almacenamiento, las redes y las identidades, y destruya el entorno después en lugar de restablecerlo o reutilizarlo.

Pruebe los límites del sistema de archivos y de la red antes de comenzar trabajos de mayor riesgo. Incluya todos los hosts accesibles, las herramientas conectadas, los agentes delegados y los servicios posteriores. Mantenga aislado el entorno host incluso cuando el modelo o el revisor aprueben una acción concreta.

Defina y aplique los límites aprobados

Antes de iniciar el modelo, documente los sistemas, las herramientas, las acciones y los límites de tiempo aprobados para su trabajo. Incluya:

• Los sistemas, hosts y entornos de destino aprobados.
• Los sistemas excluidos, incluidos los de producción y la infraestructura no relacionada.
• Las herramientas y los servicios conectados aprobados.
• Las acciones aprobadas y prohibidas.
• Las horas de inicio y finalización aprobadas y los requisitos de tratamiento de datos.
• La divulgación de vulnerabilidades, la aprobación de parches y la coordinación con los responsables del mantenimiento.
• Las condiciones de detención y las acciones que requieran aprobación humana explícita.

Proporcione al agente estos límites aprobados como contexto de la tarea. La documentación por sí sola no los aplica: utilice controles independientes del sistema de archivos, la red, la identidad y las herramientas para impedir las acciones no autorizadas siempre que resulte práctico.

Utilice los perfiles de permisos de Codex para crear un límite de privilegio mínimo. Elija :read-only cuando la tarea no requiera cambios o amplíe :workspace cuando el trabajo requiera modificar el espacio de trabajo. Por ejemplo:

approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = "cyber-lab"

[features]
network_proxy = true

[permissions.cyber-lab]
description = "Limit security testing to the approved lab and workspace."
extends = ":workspace"

[permissions.cyber-lab.filesystem]
glob_scan_max_depth = 3

[permissions.cyber-lab.filesystem.":workspace_roots"]
"**/.env*" = "deny"
"**/*.pem" = "deny"

[permissions.cyber-lab.network]
enabled = true
# Uncomment only for an approved host that resolves to a private address.
# allow_local_binding = true

[permissions.cyber-lab.network.domains]
"lab.example.com" = "allow"

La función network_proxy aplica el dominio aprobado. Sin ella, network.enabled = true permite el acceso directo a la red y la lista de permitidos del laboratorio no restringe los destinos. La búsqueda web, las aplicaciones, los conectores, los servidores MCP, la actividad del navegador y la nube de Codex utilizan controles independientes; restrinja o desactive cada superficie que su flujo de trabajo aprobado no necesite.

Sustituya lab.example.com por un destino aprobado. El análisis acotado del sistema de archivos está diseñado para evitar buscar en todo el espacio de trabajo en Linux, WSL y Windows; aumente la profundidad o utilice rutas de denegación exactas si hay archivos sensibles a mayor profundidad. No combine perfiles de permisos con configuraciones sandbox_mode heredadas; siga las indicaciones para configurar perfiles de permisos.

Si el host de laboratorio aprobado se resuelve en una dirección privada, Codex lo bloquea de forma predeterminada aunque esté en la lista de permitidos. Establezca allow_local_binding = true únicamente para trabajos en redes privadas aprobados explícitamente, mantenga restringida la lista de destinos permitidos y consulte las indicaciones sobre redes locales y privadas. También puede añadir a la lista de permitidos la dirección IP privada exacta aprobada.

Bloquee de forma predeterminada el acceso a Internet abierto y a las redes de producción. Si el acceso externo es necesario, canalícelo a través de una puerta de enlace o proxy aplicado de forma independiente, con listas de permitidos restringidas, inspección de solicitudes y registro. Aplique las mismas restricciones a las conexiones indirectas mediante gestores de paquetes, webhooks, servicios de obtención de URL, redirecciones, API en la nube y herramientas conectadas. Cargue las dependencias antes de la ejecución o utilice dependencias aprobadas por un administrador.

Proteja las credenciales y los datos sensibles

Mantenga las API key reutilizables, las credenciales de la nube, las contraseñas y los tokens de cuentas de servicio fuera de los prompts, repositorios, variables de entorno, sistemas de archivos compartidos y registros accesibles para el modelo. Cuando se requiera autenticación, utilice un intermediario o una puerta de enlace independiente para proporcionar credenciales de corta duración, limitadas al destino exacto y a la acción permitida, sin exponerlas al modelo.

Proporcione únicamente los datos necesarios para la tarea aprobada. Elimine la información sensible innecesaria, bloquee el acceso a los metadatos de la nube y a los endpoints de credenciales, y trate los archivos generados por el modelo como no confiables.

Evite :danger-full-access y --yolo en los flujos de trabajo de ciberseguridad. Full Access elimina el límite de aislamiento aplicable del que depende la revisión automática. Las organizaciones administradas pueden excluir :danger-full-access y --yolo, limitar las políticas de aprobación permitidas y exigir la revisión automática mediante la configuración administrada por la empresa.

Antes de habilitar Full Access para un modelo de seguridad aprobado, la aplicación de escritorio de ChatGPT muestra una advertencia específica del modelo sobre acciones peligrosas. La advertencia recomienda utilizar Approve for me y proporciona un enlace a la configuración de la política del revisor. La advertencia no restaura el límite de aislamiento ni anula la política de la organización.

Las medidas de protección añaden una revisión basada en políticas a un flujo de trabajo de ciberseguridad controlado. No sustituyen el aislamiento del entorno, los permisos de privilegio mínimo, los límites claramente definidos, la supervisión ni la vigilancia humana.

Revise las acciones sensibles de Codex

La revisión automática dirige las solicitudes de aprobación aptas relacionadas con los límites del aislamiento a un revisor independiente antes de ejecutar la acción propuesta. El revisor evalúa la acción propuesta, el contexto acotado de la tarea y la política aplicable y, a continuación, permite o deniega la solicitud. Las organizaciones pueden personalizar esa política en función de sus destinos aprobados, acciones prohibidas y condiciones que requieran revisión humana.

Exija aprobación humana explícita para las acciones que afecten a la producción, sistemas externos, datos sensibles, elevación de privilegios, acceso persistente o cambios irreversibles. Considere no confiables las instrucciones integradas en sitios web, repositorios, documentos y resultados de herramientas; estas no pueden ampliar el ámbito autorizado ni anular los controles de acceso.

En la aplicación de escritorio de ChatGPT, al seleccionar un modelo Daybreak aprobado, el control de permisos cambia automáticamente a Approve for me cuando ese modo está disponible para su cuenta y lo permite la política de la organización. Esto también se aplica cuando utiliza el comando /model de la aplicación de escritorio. Si ese modo no está disponible, el modo de permisos actual permanece sin cambios. La selección del modelo nunca anula los requisitos administrados de la organización.

Para que se ejecute la revisión automática, mantenga los tres controles siguientes:

1. Utilice una política de aprobación interactiva, como approval_policy = "on-request".
2. Establezca approvals_reviewer = "auto_review".
3. Mantenga un límite aplicable de aislamiento o de perfil de permisos.

Las solicitudes dirigidas a un destino incluido en la lista de red permitida permanecen dentro del límite de la red y no activan automáticamente la revisión automática. Para revisar un comando sensible incluso cuando su destino esté en la lista de permitidos, cree una regla de comandos explícita en ~/.codex/rules/:

prefix_rule(
    pattern = ["curl"],
    decision = "prompt",
    justification = "Review requests to the approved cybersecurity target.",
)

Reinicie Codex después de añadir la regla. Con approvals_reviewer = "auto_review", los comandos coincidentes se envían al revisor antes de ejecutarse. Añada las reglas de prompt correspondientes para cada comando sensible o utilice approval_mode = "prompt" para herramientas MCP individuales. Las acciones que requieran la decisión de una persona siguen necesitando aprobación humana explícita.

La revisión automática no inspecciona las acciones rutinarias que ya están permitidas dentro del entorno aislado. Con approval_policy = "never" o Full Access, una acción sensible podría no generar una solicitud de aprobación revisable. La revisión automática puede cometer errores y no sustituye el aislamiento, los límites claramente definidos, la supervisión ni la vigilancia humana explícita.

Para obtener una política acotada y aplicarla en toda la organización, consulte Configurar un flujo de trabajo de ciberseguridad autorizado.

Supervise de forma independiente y detenga el proceso ante fallos

Registre las solicitudes del modelo, las llamadas a herramientas, la actividad de red, el uso de credenciales y los cambios relevantes para la seguridad. Mantenga los registros y los sistemas de supervisión fuera del entorno controlado por el modelo. Genere alertas ante destinos no autorizados, solicitudes de red inesperadas, credenciales expuestas, cambios de políticas, registros ausentes e intentos de eludir las medidas de protección.

Mantenga la aplicación de políticas, los intermediarios de credenciales, los sistemas de revisión y los controles de apagado de emergencia independientes del agente. Detenga el flujo de trabajo si falla un control o sistema de supervisión esencial.

Añada medidas de protección a los flujos de trabajo de agentes personalizados

Si desarrolla con Responses API, Agents SDK u otro arnés, añada una revisión en el límite de ejecución de las herramientas. Antes de ejecutar acciones sensibles propuestas, compárelas con los sistemas, las acciones y los límites de tiempo aprobados; remita las acciones ambiguas o de alto riesgo a una persona; aplique restricciones independientes del sistema de archivos y de la red; conserve registros de auditoría; y detenga el proceso de forma segura si el revisor o la política no están disponibles.

La revisión automática de Codex no protege automáticamente las herramientas personalizadas ni los arneses externos. Utilice Medidas de protección y revisión humana para el patrón de Agents SDK y la política de revisión de código abierto como referencia.

El aislamiento y la revisión del producto Codex son independientes de las comprobaciones de ciberseguridad de la API. Las medidas de protección de la API pueden devolver errores cyber_policy, y los valores safety_identifier por usuario pueden ayudar a limitar el impacto de una acción de protección.

Limpie y valide los resultados

Una vez finalizado el trabajo, revoque las credenciales temporales, termine los procesos en segundo plano, elimine el acceso persistente y destruya los entornos de mayor riesgo. Compruebe que no queden callbacks, artefactos expuestos, estados compartidos ni accesos entre ejecuciones, y mantenga aislados los usuarios, las sesiones y las evaluaciones.

Valide los hallazgos antes de actuar sobre ellos, siga prácticas coordinadas de divulgación y mantenga la responsabilidad de las personas sobre las correcciones y los cambios.

Antes de comenzar

Confirme los sistemas y las acciones aprobados, el modelo adecuado, el entorno aislado, los permisos de privilegio mínimo, el acceso restringido a la red, las credenciales protegidas, la revisión de acciones, la supervisión independiente, el mecanismo de detención de emergencia y el plan de limpieza. Las medidas de protección del modelo, el aislamiento, los permisos acotados, la revisión de acciones, la supervisión y la vigilancia humana se complementan entre sí; ninguno debe ser el único control.