Revisión automática

La revisión automática sustituye la aprobación manual en los límites del sandbox por un agente revisor independiente. El agente principal de Codex sigue ejecutándose dentro del mismo sandbox, con la misma política de aprobación y los mismos límites de red y del sistema de archivos. La diferencia radica en quién revisa las solicitudes de escalamiento que cumplen los requisitos.

En la aplicación de escritorio de ChatGPT, al seleccionar un modelo Daybreak aprobado, el control de permisos cambia automáticamente a Aprobar por mí 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 no cambia. La selección del modelo nunca anula los requisitos administrados de la organización.

Antes de habilitar Acceso completo 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 Aprobar por mí en su lugar e incluye un enlace a la configuración de la política del revisor. La advertencia no restablece el límite del entorno aislado ni anula la política de la organización.

Cómo funciona la revisión automática

A grandes rasgos, el flujo es el siguiente:

1. El agente principal trabaja dentro de read-only o workspace-write.
2. Cuando necesita cruzar los límites del sandbox, solicita aprobación.
3. Si approvals_reviewer = "auto_review", Codex dirige esa solicitud de aprobación a un agente revisor independiente en lugar de detenerse para que intervenga una persona.
4. El revisor decide si la acción debe ejecutarse y devuelve una justificación.
5. Si se aprueba la acción, la ejecución continúa. Si se rechaza, se indica al agente principal que busque una alternativa sustancialmente más segura o que se detenga y consulte al usuario.

La revisión automática sustituye al revisor, pero no concede permisos. No amplía writable_roots, habilita el acceso a la red ni debilita las rutas protegidas. Solo cambia la forma en que Codex gestiona las acciones que ya requieren aprobación.

Cuándo se activa

La revisión automática evalúa las solicitudes de aprobación que, de otro modo, se pausarían para que intervenga una persona. Entre ellas se incluyen:

• Llamadas a herramientas de shell o ejecución que solicitan permisos elevados del sandbox.
• Solicitudes de red bloqueadas por el sandbox o la política actuales.
• Ediciones de archivos fuera de las raíces con permiso de escritura.
• Llamadas a herramientas de MCP o de aplicaciones que requieren aprobación según sus anotaciones de herramienta o el modo de aprobación configurado.
• Acceso de Computer Use a un sitio web o dominio nuevo.

La revisión automática no se ejecuta para las acciones rutinarias que ya están permitidas dentro del sandbox. Si un comando puede ejecutarse con el sandbox_mode activo, o una llamada a una herramienta se mantiene dentro de la política permitida, el agente principal continúa sin revisión.

Computer Use es un caso independiente. Las aprobaciones de aplicaciones para Computer Use se siguen mostrando directamente al usuario, por lo que la revisión automática no sustituye esas solicitudes de las aplicaciones.

Qué bloquea la revisión automática

A grandes rasgos, la revisión automática está diseñada para bloquear acciones como las siguientes:

• enviar datos privados, secretos o credenciales a destinos que no son de confianza
• buscar credenciales, tokens, cookies o material de sesión
• debilitar la seguridad de forma amplia o persistente
• realizar acciones destructivas con un riesgo significativo de daños irreversibles

La política exacta se encuentra en el repositorio de código abierto de Codex: policy_template.md y policy.md. Esa política se puede personalizar para cada empresa con guardian_policy_config o para cada usuario con el archivo [auto_review].policy local.

Qué ve el revisor

El propio revisor es un agente de Codex con una tarea más específica que la del agente principal: decidir si debe ejecutarse una acción concreta que cruza un límite.

El revisor ve una transcripción compacta junto con la solicitud de aprobación exacta. Esto suele incluir los mensajes del usuario, las actualizaciones visibles del asistente, las llamadas a herramientas y sus resultados pertinentes, y la acción que se propone ahora para su aprobación. También puede realizar comprobaciones de solo lectura para obtener el contexto que falte, aunque rara vez lo hace.

No se incluye el razonamiento oculto del asistente. La revisión automática ve los elementos conservados del chat y las evidencias de las herramientas, no la cadena de pensamiento privada.

Rechazos y comportamiento ante errores

Un rechazo explícito no se trata como un error normal del sandbox. Codex devuelve la justificación de la revisión al agente principal y añade una instrucción más estricta:

• No intentar conseguir el mismo resultado mediante una solución alternativa, una ejecución indirecta o la elusión de la política.
• Continuar únicamente con una alternativa sustancialmente más segura.
• De lo contrario, detenerse y consultar al usuario.

Codex también aplica un disyuntor de rechazos en cada turno. En la implementación actual de código abierto, la revisión automática interrumpe el turno después de 3 rechazos consecutivos o 10 rechazos dentro de una ventana móvil de las últimas 50 revisiones del mismo turno.

Cualquier resultado que no sea un rechazo reinicia el contador de rechazos consecutivos. Cuando se activa el disyuntor, Codex emite una advertencia e interrumpe el turno actual, en lugar de permitir que el agente siga intentando realizar más escalamientos en bucle.

Los tiempos de espera agotados se muestran por separado de los rechazos explícitos, y se informa al agente principal de que un tiempo de espera agotado no demuestra por sí solo que la acción no sea segura.

También existe una vía explícita para anular acciones rechazadas. En la TUI actual de código abierto, ejecuta /approve para abrir el selector Rechazos de la revisión automática y, a continuación, selecciona una acción rechazada recientemente para aprobar un nuevo intento. Codex registra hasta 10 rechazos recientes por tarea. Esa aprobación tiene un alcance limitado: se aplica a la acción rechazada exacta, no a acciones futuras similares; se registra para un único intento en el mismo contexto; y el nuevo intento sigue pasando por la revisión automática. Internamente, Codex inserta un marcador de aprobación con alcance de desarrollador para esa acción exacta. El revisor ve entonces esa anulación explícita del usuario como contexto, pero sigue cumpliendo la política y puede volver a rechazarla si la política indica que el usuario no puede anular ese tipo de rechazo.

Configuración

Para obtener información sobre la configuración, consulta Configuración administrada.

La política predeterminada del revisor se encuentra en el repositorio de código abierto de Codex: core/src/guardian/policy.md. Las empresas pueden sustituir su sección específica para el inquilino por guardian_policy_config en los requisitos administrados. Los usuarios individuales también pueden configurar un archivo [auto_review].policy local en su config.toml, pero los requisitos administrados tienen prioridad:

[auto_review]
policy = """
YOUR POLICY GOES HERE
"""

Para personalizar la política, copia primero el texto completo de la política predeterminada y, a continuación, adáptalo según tu perfil de riesgo individual.

Configurar un trabajo de ciberseguridad autorizado

Para realizar trabajos de seguridad autorizados, combine la revisión automática con un alcance de trabajo por escrito y un perfil de permisos con privilegios mínimos. Utilice un objetivo de laboratorio aprobado, documente las acciones y el periodo del trabajo, y mantenga fuera del alcance los sistemas de producción, los hosts no relacionados, las credenciales y los cambios persistentes, salvo que estén autorizados explícitamente.

Tanto [auto_review].policy como guardian_policy_config sustituyen su política actual del revisor. No se combinan con las políticas incluidas con su modelo ni con las administradas por su organización. Las instrucciones de revisión integradas y el formato de respuesta siguen aplicándose. Antes de utilizar cualquiera de los ejemplos, copie la política actual completa, conserve todas las reglas existentes y añada las reglas para el trabajo aprobado. Sustituya el marcador de posición en mayúsculas por esa política completa. Si no puede acceder a la política actual, no la sustituya.

La siguiente plantilla local de config.toml habilita la revisión y añade condiciones delimitadas después de la política del revisor existente:

approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = ":workspace"

[auto_review]
policy = """
PASTE THE COMPLETE ACTIVE REVIEWER POLICY HERE BEFORE USING THIS EXAMPLE.

## Environment Profile
- Authorized target: lab.example.com.
- Approved actions: inspect the target, reproduce authorized vulnerabilities,
  and validate fixes within the documented engagement window.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Allow only actions against the approved target that match the documented
  engagement scope and approved actions.
- Deny out-of-scope or unknown hosts, production access, credential theft,
  persistence, data exfiltration, destructive operations, and policy bypass.
- Deny ambiguous actions and high-impact changes until a human explicitly
  approves the exact target, action, and side effects.
"""

Sustituya el objetivo y las acciones permitidas del ejemplo por el alcance aprobado real. Aplique las restricciones del objetivo mediante reglas independientes del sistema de archivos y de la red; las instrucciones del revisor no sustituyen esos límites.

Las organizaciones pueden aplicar las mismas condiciones en un archivo requirements.toml administrado:

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
default_permissions = ":workspace"

guardian_policy_config = """
PASTE THE COMPLETE ACTIVE REVIEWER POLICY HERE BEFORE USING THIS EXAMPLE.

## Environment Profile
- Authorized target: lab.example.com.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Allow only approved actions against the documented engagement target.
- Deny out-of-scope hosts, production access, credential theft, persistence,
  data exfiltration, destructive operations, and attempts to bypass policy.
- Deny ambiguous or high-impact actions until a human explicitly approves the
  exact target, action, and side effects.
"""

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# ":danger-full-access" is omitted, so it is denied.

allowed_permission_profiles controla los perfiles de permisos actuales. allowed_sandbox_modes también impide el acceso completo en las implementaciones que aún utilizan el sandbox_mode heredado.

El valor de guardian_policy_config administrado tiene prioridad sobre el valor local [auto_review].policy del usuario. Mantenga approval_policy = "on-request" u otra política de aprobación interactiva apta y conserve un límite de entorno aislado aplicable. Con approval_policy = "never", :danger-full-access o --yolo, una acción puede evitar la creación de la solicitud de aprobación para cruzar el límite que requiere la revisión.

Un destino de red incluido en la lista de permitidos no activa la revisión por sí solo. Añade reglas de comandos explícitas con decision = "prompt", o configura las herramientas MCP sensibles para que requieran aprobación, cuando las acciones dentro del entorno aislado aún deban llegar al revisor.

Consulta Modelos y Trusted Access y la configuración recomendada para obtener información sobre el acceso a modelos, la configuración de actividades y los flujos de trabajo con agentes personalizados. Consulta Configuración administrada para conocer la precedencia empresarial y las versiones de cliente compatibles. Para implementaciones personalizadas con API o Agents SDK, usa Medidas de protección y revisión humana.

Reduce el volumen de revisiones sin debilitar la seguridad

La revisión automática funciona mejor cuando el sandbox ya abarca tus flujos de trabajo seguros habituales. Si demasiadas acciones rutinarias necesitan revisión, corrige primero los límites en lugar de enseñar al revisor a aprobar indefinidamente escalamientos innecesarios.

En la práctica, los cambios de mayor impacto son los siguientes:

• Añade writable_roots específicos para los directorios temporales o repositorios vecinos que utilizas intencionalmente.
• Añade reglas de prefijos con un alcance limitado. Prefiere prefijos de comandos precisos como ["cargo", "test"] o ["pnpm", "run", "lint"] frente a patrones amplios como ["python"] o ["curl"]. Las reglas amplias suelen eliminar precisamente el límite que la revisión automática debe proteger.

Las transcripciones de las sesiones de revisión automática se conservan de forma predeterminada en ~/.codex/sessions, por lo que puedes pedir a Codex que analice allí el tráfico anterior antes de cambiar la política o los permisos.

Limitaciones

La revisión automática mejora el punto de operación predeterminado para el trabajo prolongado de agentes, pero no constituye una garantía de seguridad determinista.

• Solo evalúa las acciones que solicitan cruzar un límite.
• Puede cometer errores, especialmente en contextos adversos o inusuales.
• Debe complementar, no sustituir, un buen diseño del sandbox, la supervisión y la política específica de la organización.

Para consultar la justificación de la investigación y los resultados publicados de la evaluación, consulta la publicación de Alignment Research sobre la revisión automática.