Révision automatique

La révision automatique remplace l’approbation manuelle aux limites du bac à sable par un agent réviseur distinct. L’agent Codex principal continue de s’exécuter dans le même bac à sable, avec la même politique d’approbation et les mêmes restrictions d’accès au réseau et au système de fichiers. La différence réside dans l’identité de la personne ou de l’agent qui examine les demandes d’élévation admissibles.

Fonctionnement de la révision automatique

Dans les grandes lignes, le processus est le suivant :

1. L’agent principal travaille dans read-only ou workspace-write.
2. Lorsqu’il doit franchir les limites du bac à sable, il demande une approbation.
3. Si approvals_reviewer = "auto_review", Codex achemine cette demande d’approbation vers un agent réviseur distinct au lieu de s’arrêter pour solliciter une personne.
4. Le réviseur décide si l’action doit être exécutée et fournit une justification.
5. Si l’action est approuvée, l’exécution se poursuit. Si elle est refusée, l’agent principal reçoit l’instruction de trouver une approche sensiblement plus sûre ou de s’arrêter et de demander à l’utilisateur.

La révision automatique remplace le réviseur, elle n’accorde pas d’autorisation. Elle n’étend pas writable_roots, n’active pas l’accès au réseau et n’assouplit pas les chemins protégés. Elle modifie uniquement la manière dont Codex traite les actions qui nécessitent déjà une approbation.

Conditions de déclenchement

La révision automatique évalue les demandes d’approbation qui, autrement, seraient suspendues dans l’attente d’une intervention humaine. Cela comprend :

• Les appels à l’outil shell ou exec qui demandent des autorisations élevées dans le bac à sable.
• Les requêtes réseau bloquées par le bac à sable ou la politique en vigueur.
• Les modifications de fichiers en dehors des racines autorisées en écriture.
• Les appels aux outils MCP ou d’application qui nécessitent une approbation en fonction de leurs annotations ou du mode d’approbation configuré.
• L’accès de Computer Use à un nouveau site web ou domaine.

La révision automatique ne s’exécute pas pour les actions courantes déjà autorisées dans le bac à sable. Si une commande peut s’exécuter avec le sandbox_mode actif, ou si un appel d’outil reste conforme à la politique autorisée, l’agent principal poursuit sans révision.

Computer Use constitue un cas distinct. Les approbations d’application pour Computer Use sont toujours présentées directement à l’utilisateur ; la révision automatique ne remplace donc pas ces demandes au niveau de l’application.

Ce que bloque la révision automatique

Dans les grandes lignes, la révision automatique est conçue pour bloquer des actions telles que :

• l’envoi de données privées, de secrets ou d’identifiants vers des destinations non fiables ;
• la recherche d’identifiants, de jetons, de cookies ou de données de session ;
• un affaiblissement généralisé ou persistant de la sécurité ;
• des actions destructrices présentant un risque important de dommages irréversibles.

La politique exacte se trouve dans le dépôt open source de Codex : policy_template.md et policy.md. Cette politique peut être personnalisée pour chaque entreprise avec guardian_policy_config ou pour chaque utilisateur avec un fichier [auto_review].policy local.

Ce que voit le réviseur

Le réviseur est lui-même un agent Codex dont la mission est plus restreinte que celle de l’agent principal : décider si une action précise franchissant une limite doit être exécutée.

Le réviseur voit une transcription synthétique ainsi que la demande d’approbation exacte. Celle-ci comprend généralement les messages de l’utilisateur, les mises à jour visibles de l’assistant, les appels d’outils et leurs résultats pertinents, ainsi que l’action dont l’approbation est maintenant proposée. Il peut également effectuer des vérifications en lecture seule pour recueillir le contexte manquant, mais il le fait rarement.

Le raisonnement masqué de l’assistant n’est pas inclus. La révision automatique voit les éléments de conversation conservés et les éléments probants issus des outils, pas la chaîne de pensée privée.

Refus et comportement en cas d’échec

Un refus explicite n’est pas traité comme une erreur ordinaire du bac à sable. Codex transmet la justification de la révision à l’agent principal et ajoute une instruction plus stricte :

• Ne cherchez pas à atteindre le même résultat au moyen d’une solution de contournement, d’une exécution indirecte ou d’un contournement de la politique.
• Ne poursuivez qu’avec une solution sensiblement plus sûre.
• Sinon, arrêtez-vous et demandez à l’utilisateur.

Codex applique également un coupe-circuit en cas de refus pour chaque tour. Dans l’implémentation open source actuelle, la révision automatique interrompt le tour après 3 refus consécutifs ou 10 refus dans une fenêtre glissante correspondant aux 50 dernières révisions du même tour.

Tout résultat autre qu’un refus réinitialise le compteur de refus consécutifs. Lorsque le coupe-circuit se déclenche, Codex émet un avertissement et interrompt le tour en cours au lieu de laisser l’agent multiplier les tentatives d’élévation.

Les expirations de délai sont signalées séparément des refus explicites, et l’agent principal est informé qu’une expiration de délai ne prouve pas à elle seule que l’action est dangereuse.

Il existe également une procédure explicite de dérogation pour les actions refusées. Dans la TUI open source actuelle, exécutez /approve pour ouvrir le sélecteur Refus de la révision automatique, puis sélectionnez une action récemment refusée afin de l’approuver pour une nouvelle tentative. Codex conserve jusqu’à 10 refus récents par tâche. Cette approbation est ciblée : elle s’applique à l’action refusée exacte, et non à des actions futures similaires ; elle est enregistrée pour une seule nouvelle tentative dans le même contexte ; et cette tentative passe toujours par la révision automatique. En interne, Codex injecte un marqueur d’approbation de portée développeur pour cette action exacte. Le réviseur voit alors cette dérogation explicite de l’utilisateur dans le contexte, mais il continue de respecter la politique et peut de nouveau refuser si celle-ci stipule que l’utilisateur ne peut pas passer outre cette catégorie de refus.

Configuration

Pour plus de détails sur la configuration, consultez Configuration gérée.

La politique par défaut du réviseur se trouve dans le dépôt open source de Codex : core/src/guardian/policy.md. Les entreprises peuvent remplacer sa section propre au locataire par guardian_policy_config dans les exigences gérées. Les utilisateurs individuels peuvent également définir un fichier [auto_review].policy local dans leur config.toml, mais les exigences gérées sont prioritaires :

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

Pour personnaliser la politique, commencez par copier l’intégralité du texte de la politique par défaut, puis faites-la évoluer en fonction de votre propre profil de risque.

Réduire le volume des révisions sans affaiblir la sécurité

La révision automatique fonctionne mieux lorsque le bac à sable couvre déjà vos processus sûrs courants. Si trop d’actions ordinaires nécessitent une révision, corrigez d’abord la limite au lieu d’apprendre au réviseur à approuver indéfiniment des demandes d’élévation superflues.

En pratique, les modifications ayant le plus d’impact sont les suivantes :

• Ajoutez des writable_roots restreintes pour les répertoires temporaires ou les dépôts voisins que vous utilisez intentionnellement.
• Ajoutez des règles de préfixe à portée restreinte. Préférez des préfixes de commande précis tels que ["cargo", "test"] ou ["pnpm", "run", "lint"] aux motifs généraux tels que ["python"] ou ["curl"]. Les règles générales effacent souvent précisément la limite que la révision automatique est censée protéger.

Les transcriptions des sessions de révision automatique sont conservées par défaut dans ~/.codex/sessions, afin que vous puissiez demander à Codex d’y analyser l’activité passée avant de modifier la politique ou les autorisations.

Limites

La révision automatique améliore le mode de fonctionnement par défaut pour les tâches agentiques de longue durée, mais elle ne constitue pas une garantie de sécurité déterministe.

• Elle évalue uniquement les actions qui demandent à franchir une limite.
• Elle peut toujours commettre des erreurs, en particulier dans des contextes hostiles ou inhabituels.
• Elle doit compléter, et non remplacer, une bonne conception du bac à sable, une surveillance et une politique propre à l’organisation.

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