Los controles de seguridad adecuados para un flujo de trabajo de ciberseguridad dependen del modelo, de las acciones que puede realizar, de los sistemas a los que tiene acceso y de la sensibilidad de los datos que utiliza.
Para la mayoría de los flujos de trabajo con Daybreak Blue, las prácticas de seguridad que ya aplica tu organización, como el control de acceso, la protección de credenciales y la revisión de acciones sensibles, pueden ser suficientes.
Los flujos de trabajo con Daybreak Red, las pruebas de seguridad autónomas y las actividades que involucran sistemas de producción, datos sensibles o herramientas externas pueden requerir medidas de protección más estrictas. Las siguientes recomendaciones se dirigen principalmente a estos escenarios de mayor riesgo.
Es tu responsabilidad evaluar los riesgos de tu flujo de trabajo e implementar los controles de seguridad adecuados. Las medidas de protección del modelo y Trusted Access no sustituyen las prácticas de seguridad, monitoreo y supervisión de tu organización.
Trusted Access regula el acceso aprobado a los modelos, pero no configura tu entorno ni hace cumplir los límites que definen qué sistemas y acciones están autorizados. Tu equipo debe establecer controles adecuados de aislamiento, permisos, revisión, monitoreo y supervisión humana. Parte del supuesto de que un atacante podría comprometer el modelo, sus herramientas y cada sistema conectado. Configura el entorno para que, aun en ese caso, ninguno pueda acceder a sistemas no autorizados, exponer credenciales, desactivar las medidas de protección ni mantener el acceso una vez finalizado el trabajo.
Aísla el entorno
Realiza las tareas de seguridad ofensiva en un laboratorio o sandbox dedicado. Empieza sin acceso irrestricto a internet y sin acceso a sistemas de producción sensibles, redes corporativas, cargas de trabajo ajenas a la tarea ni interfaces de administración del host. Impide el acceso a secretos y credenciales, así como la posibilidad de mantener acceso persistente o realizar cambios duraderos en los sistemas, salvo que el trabajo aprobado lo requiera y lo autorice expresamente.
Para tareas de mayor riesgo o con menos medidas de protección, usa un entorno nuevo con aislamiento estricto en cada intento. Separa los recursos de cómputo, el almacenamiento, las redes y las identidades. Al terminar, destruye el entorno en lugar de restablecerlo o reutilizarlo.
Antes de iniciar tareas de mayor riesgo, verifica los límites de acceso al sistema de archivos y a la red. Incluye en las pruebas todos los hosts accesibles, las herramientas conectadas, los agentes a los que se delegan tareas y los servicios que intervienen en etapas posteriores. Mantén aislado el entorno del host incluso cuando el modelo o el revisor apruebe una acción concreta.
Define y aplica los límites autorizados
Antes de que el modelo empiece a trabajar, documenta los sistemas, las herramientas, las acciones y los límites de tiempo autorizados para la tarea. Incluye lo siguiente:
- Los sistemas, hosts y entornos autorizados como objetivos.
- Los sistemas excluidos, incluida la infraestructura de producción y la que no esté relacionada con la tarea.
- Las herramientas y los servicios conectados autorizados.
- Las acciones autorizadas y las prohibidas.
- Los horarios de inicio y finalización autorizados y los requisitos para el manejo de datos.
- Los procedimientos para divulgar vulnerabilidades, aprobar parches y coordinarse con quienes se encargan del mantenimiento.
- Las condiciones para detener el trabajo y las acciones que requieren aprobación humana explícita.
Proporciona al agente estos límites autorizados como parte del contexto de la tarea. Documentarlos no basta para que se cumplan. Siempre que sea viable, aplica controles independientes sobre el sistema de archivos, la red, las identidades y las herramientas para impedir las acciones no autorizadas.
Usa los perfiles de permisos de Codex para limitar el acceso a los privilegios mínimos necesarios. Elige :read-only si la tarea no requiere cambios o extiende :workspace si necesitas editar 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 restringe el acceso al dominio autorizado. Sin ella, network.enabled = true permite el acceso directo a la red y la lista de destinos permitidos del laboratorio no restringe las conexiones. La búsqueda web, las apps, los conectores, los servidores MCP, la actividad del navegador y Codex Cloud tienen controles independientes. Restringe o desactiva cada uno de estos medios de acceso que el flujo de trabajo autorizado no necesite.
Reemplaza lab.example.com por un destino autorizado. El límite de profundidad evita que se examine todo el espacio de trabajo en Linux, WSL y Windows. Si hay archivos sensibles a mayor profundidad, aumenta el límite o especifica las rutas exactas que quieres bloquear. No combines los perfiles de permisos con la configuración heredada de sandbox_mode. Sigue la guía de configuración de perfiles de permisos.
Si el nombre del host autorizado del laboratorio se resuelve en una dirección privada, Codex bloquea el acceso de forma predeterminada, incluso si el host está en la lista de destinos permitidos. Configura allow_local_binding = true solo para tareas en redes privadas que se hayan autorizado expresamente, limita la lista de destinos permitidos y consulta la guía sobre redes locales y privadas. También puedes agregar a la lista la dirección IP privada exacta que se autorizó.
Bloquea de forma predeterminada el acceso a la internet pública y a las redes de producción. Si necesitas acceso externo, canalízalo a través de una puerta de enlace o un proxy que aplique los controles de forma independiente, permita solo destinos específicos, inspeccione las solicitudes y mantenga registros. Aplica las mismas restricciones a las conexiones indirectas a través de gestores de paquetes, webhooks, servicios que recuperan contenido de URL, redireccionamientos, API de la nube y herramientas conectadas. Carga las dependencias antes de la ejecución o usa dependencias aprobadas por un administrador.
Protege las credenciales y los datos sensibles
Mantén las claves de API reutilizables, las credenciales de la nube, las contraseñas y los tokens de cuentas de servicio fuera de los prompts, los repositorios, las variables de entorno, los sistemas de archivos compartidos y los registros a los que pueda acceder el modelo. Cuando se requiera autenticación, usa un intermediario o una puerta de enlace independiente que proporcione credenciales de corta duración, válidas solo para el destino exacto y la acción permitida, sin exponerlas al modelo.
Proporciona únicamente los datos necesarios para la tarea autorizada. Elimina la información sensible innecesaria, bloquea los puntos de acceso que proporcionan metadatos de la nube o credenciales y trata los archivos generados por el modelo como archivos no confiables.
Evita :danger-full-access y --yolo en los flujos de trabajo de ciberseguridad. Acceso completo elimina los límites que impone el sandbox y de los que depende la Revisión automática. Las organizaciones con administración centralizada 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 que actives Acceso completo para un modelo de seguridad autorizado, la app de escritorio de ChatGPT muestra una advertencia específica del modelo sobre las acciones peligrosas. La advertencia recomienda usar Aprobar por mí y enlaza a la configuración de la política del revisor. La advertencia no restablece los límites del sandbox ni anula la política de la organización.
Usa la Revisión automática junto con el aislamiento del entorno, los permisos de mínimo privilegio, el monitoreo y la supervisión humana. Documenta también el alcance del trabajo autorizado.
Revisa las acciones sensibles de Codex
La Revisión automática envía a un revisor independiente las solicitudes de aprobación que cumplen los requisitos, antes de que se ejecute la acción propuesta. El revisor evalúa la acción, el contexto de la tarea y la política aplicable. Las organizaciones pueden reemplazar la política del revisor por otra que especifique los objetivos autorizados, las acciones prohibidas y los casos que requieren aprobación humana.
Exige aprobación humana explícita para las acciones que afecten a sistemas de producción, sistemas externos o datos sensibles, o que impliquen una elevación de privilegios, acceso persistente o cambios irreversibles. Trata como no confiables las instrucciones incluidas en sitios web, repositorios, documentos y resultados de herramientas. Esas instrucciones no pueden ampliar el alcance autorizado ni anular los controles de acceso.
En la app de escritorio de ChatGPT, cuando seleccionas un modelo Daybreak autorizado, el control de permisos cambia automáticamente a Aprobar por mí si el modo está disponible para tu cuenta y la política de la organización lo permite. Esto también ocurre cuando usas el comando /model de la app de escritorio. Si ese modo no está disponible, se mantiene el modo de permisos actual. Seleccionar un modelo nunca anula los requisitos que administra la organización.
Para que se ejecute la Revisión automática, mantén activos estos tres controles:
- Usa una política de aprobación interactiva como
approval_policy = "on-request". - Configura
approvals_reviewer = "auto_review". - Mantén límites que se puedan hacer cumplir mediante un sandbox o un perfil de permisos.
Las solicitudes dirigidas a un destino permitido por la lista de la red permanecen dentro de los límites de la red y no activan por sí solas la Revisión automática. Para revisar un comando sensible incluso cuando su destino esté en la lista, crea una regla de comandos explícita en ~/.codex/rules/:
prefix_rule(
pattern = ["curl"],
decision = "prompt",
justification = "Review requests to the approved cybersecurity target.",
)Reinicia Codex después de agregar la regla. Con approvals_reviewer = "auto_review", los comandos que coincidan con la regla se envían al revisor antes de ejecutarse. Agrega reglas que soliciten aprobación para cada comando sensible o usa approval_mode = "prompt" para herramientas MCP individuales. Las acciones que dependen de la decisión de una persona siguen requiriendo aprobación humana explícita.
La Revisión automática evalúa las acciones que requieren aprobación. Con approval_policy = "never" o con Acceso completo, una acción sensible podría ejecutarse sin que se solicite aprobación. Mantén controles de acceso y mecanismos de monitoreo independientes durante todo el trabajo autorizado.
Para definir una política con un alcance específico y hacerla cumplir en toda la organización, consulta Cómo configurar un flujo de trabajo de ciberseguridad autorizado.
Monitorea de forma independiente y detén el trabajo si fallan los controles
Registra las solicitudes del modelo, las llamadas a herramientas, la actividad de red, el uso de credenciales y los cambios relevantes para la seguridad. Mantén los registros y los sistemas de monitoreo fuera del entorno que controla el modelo. Configura alertas para detectar destinos no autorizados, solicitudes de red inesperadas, credenciales expuestas, cambios de política, registros faltantes e intentos de eludir las medidas de protección.
Mantén independientes del agente los mecanismos que hacen cumplir las políticas, los intermediarios de credenciales, los sistemas de revisión y los controles de apagado de emergencia. Detén el flujo de trabajo si falla un control esencial o un sistema de monitoreo.
Agrega medidas de protección a los flujos de trabajo personalizados de agentes
Si desarrollas con la API de Responses, el SDK de Agents u otro arnés de ejecución, incorpora una revisión justo antes de que se ejecuten las herramientas. Antes de ejecutar una acción sensible propuesta, comprueba que el sistema de destino y la acción estén autorizados y que se respeten los límites de tiempo. Deriva las acciones ambiguas o de alto riesgo a una persona, aplica restricciones independientes al sistema de archivos y a la red, conserva registros de auditoría y bloquea la ejecución 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 de ejecución externos. Consulta Medidas de protección y revisión humana para aplicar el patrón del SDK de Agents y usa como referencia la política de código abierto del revisor.
El entorno aislado y la revisión que ofrece Codex son independientes de las verificaciones de ciberseguridad de la API. Las medidas de protección de la API pueden devolver errores cyber_policy, y los valores de safety_identifier asignados a cada usuario pueden ayudar a limitar el impacto de una medida de protección cuando se activa.
Limpia el entorno y valida los resultados
Al finalizar el trabajo, revoca las credenciales temporales, termina los procesos en segundo plano, elimina el acceso persistente y destruye los entornos de mayor riesgo. Verifica que no queden conexiones de retorno, artefactos expuestos, estados compartidos ni vías de acceso entre ejecuciones. Mantén el aislamiento entre usuarios, entre sesiones y entre evaluaciones.
Valida los hallazgos antes de actuar, sigue las prácticas de divulgación coordinada y asegúrate de que haya personas responsables de corregir los problemas y de los cambios que se realicen.
Antes de empezar
Confirma qué sistemas y acciones están autorizados y que el modelo sea el adecuado. Verifica el aislamiento del entorno, los permisos de mínimo privilegio, las restricciones de acceso a la red, la protección de las credenciales, la revisión de las acciones, el monitoreo independiente, el mecanismo de parada de emergencia y el plan de limpieza. Las medidas de protección del modelo, el aislamiento, los permisos de alcance limitado, la revisión de acciones, el monitoreo y la supervisión humana se complementan. Ninguno de estos controles debe usarse como única medida de protección.