Sécurité et audit des accès

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

Chaque tâche Codex s’exécute dans un sandbox isolé, ce qui recouvre quatre garanties. Il n’y a pas d’accès Internet pendant l’exécution, à l’exception des registres de packages pré-autorisés : Codex ne peut donc ni exfiltrer du code vers un service externe ni télécharger un binaire arbitraire. Il n’y a pas non plus d’accès aux autres repos, une tâche sur le repo A ne pouvant pas lire le repo B. Le sandbox ne persiste pas et disparaît à la fin de la tâche. Enfin, il n’y a pas d’exécution arbitraire : Codex ne lance que les commandes documentées dans AGENTS.md, ce qui confère à ce fichier un rôle de sécurité en plus de son rôle pédagogique.

Du côté de la lecture, Codex accède à tout le contenu du repository connecté — code, configurations, documentation —, à son historique Git et aux variables d’environnement non sensibles que vous configurez. Il ne voit ni les secrets de votre .env de production, ni les repositories non connectés, ni votre système de fichiers local, ni vos credentials de services tiers. Cette frontière est nette, mais elle ne vous dispense pas de savoir ce que contient réellement le repository que vous branchez.

Masquer ce qui ne doit pas être lu

Un fichier .codexignore placé à la racine du repo, avec la syntaxe d’un .gitignore, rend certains fichiers invisibles pour Codex même lorsqu’ils sont versionnés :

# .codexignore
.env*
secrets/
credentials/
*.pem
*.key
config/production.json

Écrivez-le avant de connecter un repository existant, jamais après. Sur un projet ancien, ce réflexe évite qu’une vieille clé de test oubliée dans un fichier de configuration de 2019 se retrouve dans le contexte d’une tâche.

La même prudence s’applique à AGENTS.md, que Codex lit intégralement à chaque exécution. N’y placez jamais de secrets réels : des valeurs fictives suffisent amplement à 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

Le plan Enterprise fournit des logs d’audit détaillés qui répondent aux cinq questions d’un auditeur : qui a lancé la tâche, quoi — sa description —, où, c’est-à-dire quel repository et quels fichiers ont été lus ou modifiés, quand, avec un horodatage précis, et le résultat : succès, échec ou rejet. Ces logs se consultent depuis Organization Settings → Audit Logs, se filtrent par utilisateur, repository, période et type d’action, et s’exportent en CSV.

Encore faut-il que quelqu’un les ouvre autrement qu’après un incident. Configurez des alertes sur les événements qui appellent une réaction immédiate : une tâche lancée sur un repo sensible, un volume anormal de tâches en une heure pour un même utilisateur, la modification d’un fichier de configuration comme package.json ou tsconfig.json, ou une tentative d’accès à un fichier listé dans .codexignore. Cette dernière alerte est la plus instructive de toutes, car elle admet deux lectures : soit une consigne mal formulée a envoyé l’agent au mauvais endroit, soit un fichier sensible n’aurait jamais dû se trouver dans ce repository.

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 plan OpenAI inclut le DPA (Data Processing Agreement) ; configurez la région de traitement sur l’Europe si l’option est disponible ; documentez l’utilisation de Codex dans votre registre des traitements ; informez enfin les équipes que leur code est analysé par un service tiers.

Pour les organisations certifiées SOC 2 ou ISO 27001, Codex est certifié SOC 2 Type II — vérifiez la date du dernier rapport, une certification périmée ne vaut rien devant un auditeur. Les logs d’audit répondent aux exigences de traçabilité, et l’isolation par sandbox à celles de séparation des environnements. Ces éléments constituent des preuves recevables, à condition d’être 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

• Codex fonctionne dans un sandbox isolé sans accès Internet
• Utilisez .codexignore pour masquer les fichiers sensibles
• Les logs d’audit tracent toutes les actions de Codex
• Vérifiez la conformité RGPD si vous traitez des données européennes
• Ne mettez jamais de vrais secrets dans AGENTS.md