Sécurité et audit des accès

Leçon réécrite le 3 novembre 2026 d’après les pages Agent approvals & security, Rules, Compliance API and audit events et le manuel de Codex. L’ancienne version décrivait un fichier .codexignore qui n’existe pas, affirmait que Codex ne lance que les commandes citées dans AGENTS.md, citait un menu « Organization Settings → Audit Logs » et une certification SOC 2 Type II de Codex sans source. Sources : Agent approvals & security · Rules · Compliance API · Pricing.

Contrôler ce que Codex peut voir et faire

La sécurité devient un enjeu majeur dès lors qu’un agent IA accède à votre code source. Codex a été conçu avec des gardes-fous, mais leur configuration relève de votre responsabilité : le produit fournit l’isolation, vous fournissez le périmètre. Un repository connecté par commodité un soir de rush, un secret laissé dans un fichier de configuration oublié, et l’isolation technique ne protège plus grand-chose.

Le modèle de sécurité de Codex

Deux réglages, complémentaires, encadrent ce que l’agent peut faire : le bac à sable, qui fixe ce qu’il peut techniquement toucher, et la politique d’approbation, qui fixe quand il doit s’arrêter pour vous demander l’autorisation — pour sortir du bac à sable, utiliser le réseau ou lancer une commande hors de l’ensemble autorisé.

• En local (CLI, extension, application de bureau), des mécanismes du système d’exploitation appliquent le bac à sable. Par défaut, pas d’accès réseau, et l’écriture est limitée à l’espace de travail actif. Avec le préréglage courant --sandbox workspace-write --ask-for-approval on-request, Codex lit, modifie et exécute librement dans le dossier de travail, et demande avant d’écrire ailleurs ou d’utiliser le réseau. Le mode read-only (commande /permissions) permet de discuter et de planifier sans rien modifier.
• Dans le cloud, chaque tâche Codex Cloud a son propre espace de travail dans un environnement géré par OpenAI ; les identifiants et l’accès réseau se configurent par environnement, avec des secrets réseau limités aux services HTTPS autorisés.

Contrairement à ce qu’affirmait l’ancienne version de cette leçon, Codex n’est pas cantonné aux commandes citées dans AGENTS.md : il peut lancer des commandes, et c’est le couple bac à sable / approbations qui le borne. Pour aller plus loin, les règles encadrent les commandes autorisées hors du bac à sable : une règle de préfixe peut exiger une confirmation, ou interdire une commande.

# Fichier .rules (syntaxe Starlark)
prefix_rule(
    pattern = ["curl"],
    decision = "prompt",
    justification = "Toute requête réseau sortante doit être confirmée.",
)

Imposées par l’administrateur, ces règles ne peuvent que demander confirmation ou interdire, jamais autoriser.

Masquer ce qui ne doit pas être lu

Il n’existe pas de fichier .codexignore. Pour empêcher Codex de lire des fichiers sensibles, même versionnés, on utilise un profil de permissions et des règles deny sur des chemins exacts ou des motifs :

# ~/.codex/config.toml
[permissions.project-edit.filesystem]
glob_scan_max_depth = 3

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

Placée sous :workspace_roots, la règle s’applique à chaque racine d’espace de travail : les fichiers .env y deviennent illisibles, sans empêcher les écritures normales ailleurs. Les chemins exacts conviennent aux emplacements stables comme ~/.ssh ; les motifs, aux fichiers dont l’emplacement varie. Un administrateur peut imposer ces refus à toute l’organisation (permissions.filesystem.deny_read).

Deux limites sont documentées. Sous Linux, WSL et Windows, les correspondances d’un motif sont relevées au démarrage de chaque processus du bac à sable : un fichier correspondant créé ensuite reste lisible par un processus déjà lancé. Et un motif ** sans borne exige glob_scan_max_depth. Le plus sûr reste donc de ne pas laisser de secret dans le dépôt.

La même prudence s’applique à AGENTS.md, que Codex lit à chaque exécution. N’y placez jamais de secrets réels : des valeurs fictives suffisent à expliquer le format attendu par vos commandes de test.

## Variables d'environnement
Les commandes de test utilisent des variables fictives :
- DATABASE_URL=postgresql://test:test@localhost:5432/test_db
- AUTH_SECRET=test-secret-for-development-only

Tracer et surveiller

Dans les offres Enterprise et Edu, les journaux d’audit et le suivi de l’usage passent par la Compliance API. Elle sert aux usages de sécurité, juridiques et d’enquête qui exigent des enregistrements vérifiables : exporter les événements vers un SIEM ou un lac de données, appliquer vos durées de conservation et vos gels juridiques, croiser l’activité de Codex avec vos données d’identité. La documentation de l’API d’administration fait foi pour les événements couverts, les filtres et la rétention ; testez l’ingestion sur un système hors production avant de planifier une collecte continue.

Ce n’est pas un tableau de bord de productivité : OpenAI déconseille de s’en servir pour juger la qualité du code ou la performance individuelle, et renvoie pour l’adoption aux analyses de l’espace de travail et à l’Analytics API. Encore faut-il que quelqu’un exploite ces journaux autrement qu’après un incident : tenez-les hors de l’environnement contrôlé par l’agent, et alertez sur les échecs d’authentification répétés, les accès inhabituels et les modifications de configuration.

Conformité et réglementation

Si votre code traite des données personnelles européennes, quatre points relèvent de votre responsabilité et non de celle du fournisseur. Vérifiez que votre contrat OpenAI inclut le DPA (Data Processing Agreement) ; utilisez les contrôles de conservation et de résidence des données quand votre offre les propose (Enterprise et Edu) ; documentez l’utilisation de Codex dans votre registre des traitements ; informez enfin les équipes que leur code est traité par un service tiers. Dans l’offre Business, les données de l’entreprise ne servent pas à l’entraînement par défaut.

Pour un audit SOC 2 ou ISO 27001, appuyez-vous sur les documents publiés par OpenAI — dont le livre blanc sécurité de Codex, sur son portail de confiance — et vérifiez le périmètre et la date de chaque attestation : une attestation périmée, ou qui ne couvre pas le service utilisé, ne vaut rien devant un auditeur. Les exports de la Compliance API répondent aux exigences de traçabilité, à condition d’être collectés en continu et produits le jour où on vous les demande.

Bonnes pratiques de sécurité

Le partage de compte, dernier point de la colonne de droite, mérite une mention particulière : il annule d’un seul geste toute la valeur des logs d’audit, puisque plus aucune action ne peut être rattachée à une personne identifiable.

Points clés à retenir

• Le bac à sable borne ce que Codex peut toucher (en local : réseau coupé et écriture limitée à l’espace de travail par défaut) ; la politique d’approbation fixe quand il demande
• Les règles encadrent les commandes hors du bac à sable (prompt ou forbidden)
• .codexignore n’existe pas : interdisez la lecture des fichiers sensibles par des règles deny d’un profil de permissions
• Les journaux d’audit passent par la Compliance API (Enterprise et Edu)
• Vérifiez la conformité RGPD si vous traitez des données européennes
• Ne mettez jamais de vrais secrets dans AGENTS.md