Révision automatique

La révision automatique transmet les demandes d’approbation admissibles à un agent de révision distinct. Votre bac à sable, vos règles de commande et les paramètres de vos outils déterminent quelles actions nécessitent une approbation. L’agent de révision décide si ces actions peuvent être exécutées.

Dans l’application de bureau ChatGPT, lorsque vous sélectionnez un modèle Daybreak approuvé, le sélecteur d’autorisations passe automatiquement à Approuver pour moi si ce mode est disponible pour votre compte et si la politique de votre organisation l’autorise. Cela vaut également lorsque vous utilisez la commande /model de l’application de bureau. Si ce mode est indisponible, le mode d’autorisation actuel reste en vigueur. Le choix du modèle ne prévaut jamais sur les exigences définies par l’organisation.

Avant d’activer Accès complet pour un modèle de sécurité approuvé, l’application de bureau ChatGPT affiche un avertissement propre au modèle concernant les actions dangereuses. Cet avertissement recommande d’utiliser Approuver pour moi et renvoie à la configuration de la politique de révision. Il ne rétablit pas les limites du bac à sable et ne prévaut pas sur la politique de l’organisation.

Sélectionner la révision automatique

Dans l’application de bureau, choisissez Approuver pour moi dans le sélecteur d’autorisations sous la zone de saisie. Vérifiez que ce mode est sélectionné pour la discussion en cours. Consultez la page Autorisations pour choisir un mode ou résoudre un problème.

Pour la CLI ou une configuration locale de Codex, définissez approvals_reviewer = "auto_review" et utilisez une politique d’approbation interactive admissible, par exemple approval_policy = "on-request". Modifier uniquement la politique d’approbation ne suffit pas à sélectionner l’agent de révision. Les administrateurs peuvent imposer la révision automatique à leur organisation.

Fonctionnement de la révision automatique

1. L’agent principal propose une action, par exemple l’exécution d’une commande.
2. Si l’action nécessite une approbation, Codex crée une demande.
3. Si approvals_reviewer = "auto_review", Codex transmet la demande à un agent de révision distinct sans attendre une intervention humaine.
4. L’agent de révision décide si l’action peut être exécutée et motive sa décision.
5. Si l’action est approuvée, l’exécution se poursuit. En cas de refus, l’agent principal reçoit pour instruction de trouver une solution nettement plus sûre ou de s’arrêter et de consulter l’utilisateur.

Déclenchement de la révision automatique

La révision automatique examine les demandes d’approbation qui, autrement, suspendraient l’exécution en attendant une décision humaine. Cela comprend les cas suivants :

• Appels d’outils shell ou exec qui demandent des autorisations supérieures à celles du bac à sable.
• Commandes qui correspondent à une règle de commande avec decision = "prompt", y compris celles exécutées dans le bac à sable.
• Requêtes réseau vers des destinations qui nécessitent une approbation. Une règle réseau de refus explicite bloque la requête.
• Modifications de fichiers en dehors des répertoires racines autorisés en écriture.
• Appels d’outils MCP ou d’applications qui nécessitent une approbation selon les annotations de l’outil ou le mode d’approbation configuré.

Les actions déjà autorisées s’exécutent sans révision.

Pour la fonctionnalité Utilisation de l’ordinateur, les demandes d’accès aux applications sont présentées directement à l’utilisateur. Les appels d’outils admissibles de cette fonctionnalité peuvent, indépendamment de ces demandes, déclencher la révision automatique.

Actions bloquées par la révision automatique

La révision automatique est conçue pour bloquer notamment les actions suivantes :

• envoyer des données privées, des secrets ou des identifiants à des destinations non fiables
• rechercher des identifiants, des tokens, des cookies ou des données de session
• affaiblir la sécurité à grande échelle ou de façon persistante
• effectuer des actions destructrices présentant un risque important de dommages irréversibles

Consultez la section Configuration pour connaître les règles par défaut et savoir comment les personnaliser.

Informations accessibles à l’agent de révision

L’agent de révision examine l’action précise qui a déclenché la demande d’approbation.

Il reçoit une transcription condensée et la demande d’approbation exacte. Il y trouve généralement les messages de l’utilisateur, les mises à jour affichées par l’assistant, les appels d’outils pertinents et leurs résultats, ainsi que l’action soumise à son approbation. Il peut aussi effectuer des vérifications en lecture seule, par exemple inspecter un répertoire avant d’en approuver la suppression.

Le raisonnement caché de l’assistant est exclu de la transcription. La révision automatique a accès aux éléments conservés de la discussion et aux informations fournies par les outils. Le raisonnement détaillé (« chain-of-thought ») reste privé.

Refus et gestion des échecs

Codex traite un refus explicite différemment d’une erreur ordinaire du bac à sable. Il transmet le motif du refus à l’agent principal et lui donne des instructions plus strictes :

• Ne cherchez pas à obtenir le même résultat par un moyen détourné, par une exécution indirecte ou en contournant la politique.
• Poursuivez uniquement si vous disposez d’une solution nettement plus sûre.
• Dans les autres cas, arrêtez-vous et consultez l’utilisateur.

Pour la plupart des modèles, la CLI de Codex interrompt le tour après 3 refus consécutifs ou 10 refus parmi les 50 dernières révisions du même tour. Pour les modèles destinés à la cybersécurité, la CLI interrompt le tour dès le premier refus.

Tout résultat de révision autre qu’un refus remet à zéro le compteur de refus consécutifs. Lorsque Codex atteint l’un des seuils de refus, il affiche un avertissement et interrompt le tour.

Les dépassements de délai sont signalés séparément des refus explicites. L’agent principal est informé qu’un dépassement de délai ne suffit pas à établir qu’une action est dangereuse.

Codex permet aussi à l’utilisateur de demander explicitement une nouvelle tentative après un refus. Dans l’interface en mode texte open source actuelle, exécutez /approve pour ouvrir la liste Auto-review Denials, puis sélectionnez une action récemment refusée pour en approuver une seule nouvelle tentative. Codex conserve jusqu’à 10 refus récents par tâche. Cette approbation porte uniquement sur l’action précise qui a été refusée et ne s’étend pas aux actions similaires à venir. Elle est enregistrée pour une seule nouvelle tentative dans le même contexte, et cette tentative reste soumise à la révision automatique. En interne, Codex insère un marqueur d’approbation au niveau développeur pour cette action précise. L’agent de révision voit alors la dérogation explicite de l’utilisateur dans son contexte. Il continue toutefois d’appliquer la politique et peut à nouveau refuser l’action si la politique ne permet pas à l’utilisateur de passer outre cette catégorie de refus.

Configuration

Le gabarit de révision indique à l’agent de révision comment évaluer une action. Codex y insère la politique de sécurité et définit séparément le format de réponse. La CLI utilise la politique par défaut du modèle chargé de la révision lorsqu’elle est disponible. À défaut, elle utilise la politique fournie avec la CLI (policy.md).

Pour remplacer la politique, copiez l’intégralité de la politique que vous souhaitez adapter. Si vous utilisez la politique par défaut fournie avec la CLI, copiez tout le contenu de policy.md. Modifiez les règles souhaitées, puis placez le texte intégral dans le paramètre local [auto_review].policy ou le paramètre géré guardian_policy_config. Les règles que vous omettez ne s’appliquent plus. Codex continue d’utiliser le gabarit et le format de réponse de l’agent de révision.

Le paramètre géré guardian_policy_config prime sur le paramètre local [auto_review].policy. Codex ignore les valeurs vides de ces paramètres.

Pour une configuration à l’échelle de l’organisation, consultez la section Configurer la politique de révision automatique.

Configurer une mission de cybersécurité autorisée

Pour des travaux de sécurité autorisés, associez la révision automatique à un périmètre d’intervention défini par écrit et à un profil d’autorisations qui respecte le principe du moindre privilège. Utilisez une cible de laboratoire approuvée et documentez les actions ainsi que la période d’intervention. Sauf autorisation explicite, excluez du périmètre les systèmes de production, les hôtes sans rapport avec la mission, les identifiants et les modifications persistantes.

Cet exemple de fichier config.toml local active la révision automatique et sélectionne le profil d’autorisations de l’espace de travail.

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

Faites respecter les restrictions sur les cibles au moyen de règles indépendantes pour le système de fichiers et le réseau. L’exemple suivant de fichier requirements.toml géré impose la révision automatique et limite les profils d’autorisations disponibles.

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

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

allowed_permission_profiles détermine quels profils d’autorisations actuels sont autorisés. allowed_sandbox_modes empêche également l’accès complet dans les déploiements qui utilisent encore l’ancien paramètre sandbox_mode.

Conservez approval_policy = "on-request" ou une autre politique d’approbation interactive admissible, ainsi que des limites de bac à sable que le système peut faire respecter. Avec approval_policy = "never", :danger-full-access ou --yolo, une action peut ne pas déclencher la demande d’approbation dont dépend la révision automatique en cas de franchissement des limites du bac à sable.

La présence d’une destination réseau dans la liste d’autorisation ne déclenche pas à elle seule une révision. Lorsque certaines actions au sein du bac à sable doivent tout de même être soumises à révision, ajoutez des règles de commande explicites avec decision = "prompt" ou configurez les outils MCP sensibles pour qu’ils exigent une approbation.

Consultez les pages Modèles et accès de confiance et Configuration recommandée pour en savoir plus sur l’accès aux modèles, la préparation des missions et les workflows d’agents personnalisés. Pour les harnais personnalisés utilisant l’API ou le SDK Agents, consultez la page Garde-fous et révision humaine.

Réduire le nombre de révisions sans affaiblir la sécurité

La révision automatique fonctionne mieux lorsque le bac à sable permet déjà d’exécuter vos workflows courants et sûrs. Si trop d’actions ordinaires nécessitent une révision, ajustez d’abord les limites du bac à sable pour éviter de devoir faire approuver indéfiniment les mêmes demandes d’élévation de privilèges par l’agent de révision.

En pratique, les changements les plus efficaces sont les suivants :

• Ajoutez des entrées writable_roots limitées aux répertoires temporaires ou aux dépôts voisins que vous utilisez délibérément.
• Ajoutez des règles de préfixe de portée limitée. Préférez des préfixes de commande précis comme ["cargo", "test"] ou ["pnpm", "run", "lint"] à des motifs génériques comme ["python"] ou ["curl"]. Les règles trop larges suppriment souvent la limite que la révision automatique est censée protéger. Pour les modèles de cybersécurité, la CLI ignore les règles de préfixe allow et applique les règles prompt et forbidden.

Par défaut, les transcriptions des sessions de révision automatique sont conservées dans ~/.codex/sessions. Vous pouvez demander à Codex d’y analyser les demandes passées avant de modifier la politique ou les autorisations.

Limites

La révision automatique améliore les conditions d’exécution par défaut des tâches de longue durée confiées aux agents, sans offrir de garantie de sécurité déterministe.

• Elle examine uniquement les demandes d’approbation admissibles, y compris celles que déclenchent des règles de commande explicites ou les paramètres d’approbation des outils.
• Elle peut commettre des erreurs, en particulier dans des situations inhabituelles ou face à une tentative de manipulation.
• Elle doit compléter un bac à sable bien conçu, des mécanismes de surveillance et une politique propre à l’organisation, sans s’y substituer.

Pour connaître les motivations de ces travaux de recherche et les résultats d’évaluation publiés, consultez l’article d’Alignment Research sur la révision automatique.