Accueil › Codex › Sécurité

Sécurité Codex : sandbox, approbations et contrôles d’accès

La sécurité de Codex repose sur deux couches complémentaires : le sandbox (limites techniques de ce que l’agent peut faire) et la politique d’approbation (quand l’agent doit demander avant d’agir). Par défaut, le réseau est bloqué et les écritures sont limitées au workspace. Ces contrôles s’appliquent sur toutes les surfaces : CLI, app desktop, extension IDE et cloud.

L’architecture de sécurité en deux couches

La sécurité de Codex combine deux mécanismes indépendants qui travaillent ensemble :

Le sandbox définit les limites techniques : quels fichiers l’agent peut modifier, si les commandes ont accès au réseau, et quels répertoires sont accessibles. C’est une contrainte appliquée au niveau du système d’exploitation. Même si l’agent « décide » d’écrire en dehors du workspace, le sandbox l’en empêche techniquement.

La politique d’approbation définit les points de contrôle humain : quand l’agent doit s’arrêter et demander votre permission avant d’exécuter une action. C’est une couche de gouvernance qui se superpose au sandbox.

Le sandbox s’applique aux commandes générées par le modèle (les sous-processus), pas uniquement aux opérations de fichiers intégrées de Codex. C’est un point important : le sandboxing couvre tout ce que l’agent exécute via le shell.

Les trois modes de sandbox

read-only

Le mode le plus restrictif. Codex peut lire des fichiers mais ne peut rien modifier sur le système de fichiers. Aucun accès réseau. C’est le mode par défaut de la configuration initiale. Utilisez-le pour les audits de code, les sessions de Q&A sur le codebase, et les phases d’exploration où vous ne voulez aucun changement.

sandbox_mode = "read-only"
approval_policy = "untrusted"

workspace-write (recommandé)

Codex peut lire partout et écrire dans le workspace courant. Le réseau est bloqué par défaut. Les répertoires .git/ et .codex/ sont automatiquement protégés contre les écritures, même dans ce mode. C’est le mode par défaut pour le développement quotidien et celui activé par le flag --full-auto.

sandbox_mode = "workspace-write"
approval_policy = "on-request"

# Optionnel : activer le réseau dans ce mode
[sandbox_workspace_write]
network_access = true

# Optionnel : ajouter des répertoires supplémentaires en écriture
# writable_roots = ["/home/user/shared-lib"]

Si vous avez besoin que Codex écrive dans plus d’un répertoire, utilisez writable_roots pour étendre les permissions sans désactiver le sandbox entièrement. C’est une meilleure approche que de passer en danger-full-access.

danger-full-access

Aucune restriction de sandbox. Codex peut modifier n’importe quel fichier, exécuter n’importe quelle commande, et accéder au réseau librement. Ce mode est explicitement nommé « danger » pour une raison : utilisez-le uniquement dans un container jetable, une VM dédiée, ou un runner CI isolé que vous pouvez détruire sans conséquence.

Les politiques d’approbation

Le mode granular permet d’autoriser ou de bloquer automatiquement des catégories spécifiques de prompts. Par exemple, vous pouvez laisser passer les demandes sandbox normales mais bloquer automatiquement les demandes de permissions élevées ou les scripts de skills non vérifiés :

approval_policy = { granular = {
  sandbox_approval = true,
  rules = true,
  mcp_elicitations = true,
  request_permissions = false,
  skill_approval = false
} }

Contrôle du réseau

Par défaut, les commandes exécutées par Codex n’ont pas accès au réseau. C’est une protection contre l’exfiltration de données, les injections de prompt via du contenu web, et les téléchargements non autorisés.

Pour les tâches qui nécessitent le réseau (installation de dépendances, appels API, déploiement) :

# Activer le réseau pour une exécution spécifique
codex -c 'sandbox_workspace_write.network_access=true' 
  "Installer les dépendances et lancer les tests"

# Ou dans la config permanente
# [sandbox_workspace_write]
# network_access = true

La recherche web est un cas spécial : elle est activée par défaut en mode cache (résultats pré-indexés par OpenAI). Ce mode réduit l’exposition aux injections de prompt depuis du contenu web arbitraire. En mode --yolo ou full access, la recherche web passe automatiquement en mode live. Vous pouvez aussi la désactiver complètement avec web_search = "disabled".

Réseau en mode cloud

Codex Cloud utilise un modèle en deux phases. La phase de setup a accès au réseau pour installer les dépendances. La phase agent s’exécute ensuite offline par défaut. Les secrets configurés pour les environnements cloud sont disponibles uniquement pendant le setup et sont supprimés avant le début de la phase agent. Vous pouvez activer l’accès Internet pour l’environnement cloud via une allowlist de domaines.

Les Rules : exceptions ciblées

Quand un workflow nécessite une exception spécifique (par exemple, autoriser npm test avec accès réseau sans donner un accès total), les rules permettent d’autoriser, demander, ou interdire des préfixes de commande en dehors du sandbox :

# Autoriser npm test et npm run build sans prompt
[[rules]]
prefix = "npm test"
action = "allow"

[[rules]]
prefix = "npm run build"
action = "allow"

# Demander confirmation pour les commandes git destructives
[[rules]]
prefix = "git push --force"
action = "prompt"

# Interdire rm -rf
[[rules]]
prefix = "rm -rf"
action = "deny"

Les rules sont souvent une meilleure solution que d’élargir le sandbox. Elles vous permettent d’accorder des permissions chirurgicales au lieu d’ouvrir les vannes.

Chemins protégés

Même en mode workspace-write, Codex protège automatiquement certains répertoires contre les écritures :

.git/ : protégé pour éviter la corruption du repo Git. Les opérations Git passent par les commandes Git habituelles, pas par des écritures directes dans .git.

.codex/ : protégé pour éviter que l’agent ne modifie sa propre configuration ou ses instructions.

Ces protections sont en place même si writable_roots inclut le répertoire parent. Elles ne sont désactivées qu’en mode danger-full-access.

Projets trusted vs untrusted

Quand vous ouvrez un projet dans Codex, vous pouvez le marquer comme trusted ou untrusted. Un projet untrusted est traité avec méfiance : Codex ignore les fichiers de configuration projet (.codex/config.toml) et se rabat sur vos configurations utilisateur, système et par défaut. C’est une protection contre les attaques via des fichiers de config malveillants dans un repo cloné.

Marquez toujours un projet comme untrusted la première fois que vous le clonez depuis une source inconnue. Reviewez les fichiers .codex/ avant de le passer en trusted.

Administration et enforcement organisationnel

requirements.toml

Pour les déploiements d’équipe et d’entreprise, les administrateurs peuvent imposer des contraintes de sécurité que les utilisateurs ne peuvent pas outrepasser. Le fichier requirements.toml définit les valeurs autorisées pour les paramètres sensibles :

# requirements.toml (admin-enforced)

# Interdire le mode full-access et la politique never
[allowed]
approval_policy = ["untrusted", "on-request"]
sandbox_mode = ["read-only", "workspace-write"]
web_search = ["disabled", "cached"]

# Épingler des feature flags
[features]
shell_tool = true
multi_agent = true

Avec cette configuration, aucun développeur de l’organisation ne peut passer en danger-full-access ou désactiver les approbations. C’est l’outil principal pour les équipes sécurité qui déploient Codex à grande échelle.

Les plans Business et Enterprise bénéficient aussi de politiques managées déployables depuis la page Codex Policies dans le dashboard admin, avec assignation par groupe d’utilisateurs et politique par défaut de fallback.

RBAC et gouvernance

Les plans Enterprise offrent un contrôle d’accès basé sur les rôles (RBAC) pour Codex, avec des rôles séparés pour l’administration Codex, l’accès aux analytiques, et l’accès aux données de conformité. Les audit logs et l’API de conformité permettent de tracer chaque action de l’agent pour les workflows d’investigation et de compliance.

OpenAI recommande de créer un groupe dédié « Codex Admin » plutôt que d’accorder l’administration Codex à une audience large.

Protection des données

Les plans Business et Enterprise garantissent que vos données ne sont pas utilisées pour entraîner les modèles d’OpenAI. Pour les organisations avec des exigences strictes de résidence des données, Codex cloud s’exécute dans des containers managés par OpenAI avec des contrôles définis dans la politique de l’espace de travail. Le Zero Data Retention (ZDR) est disponible pour les déploiements qui le nécessitent.

Codex Security : scan de vulnérabilités

Codex Security est un produit distinct (en bêta privée pour certains clients) qui scanne vos repos GitHub pour détecter des vulnérabilités. Il fonctionne différemment des outils SAST classiques :

Il construit d’abord un modèle de menaces spécifique à votre repo, en analysant la structure du code et les patterns de sécurité utilisés. Puis il vérifie les vulnérabilités probables contre ce contexte, en validant les findings dans un environnement isolé avant de les remonter. Ce processus réduit significativement le bruit (faux positifs) par rapport aux scanners traditionnels.

OpenAI rapporte avoir testé l’outil sur 1,2 million de commits en 30 jours, identifiant près de 800 vulnérabilités critiques et plus de 10 000 de haute sévérité dans des projets comme Chromium, OpenSSL, PHP, GOGS, et GnuTLS. L’outil a également découvert 14 CVE réels dans des projets open source.

Codex Security est accessible via Codex Web pour les repos GitHub connectés. L’accès est géré par OpenAI et nécessite une demande auprès de votre account team.

Observabilité et monitoring

Codex supporte l’export de logs via OpenTelemetry (OTel) pour tracer les exécutions de l’agent : requêtes API, événements SSE, prompts, décisions d’approbation des outils, et résultats. L’export est désactivé par défaut. Activez-le dans la configuration :

[otel]
environment = "production"
exporter = { otlp-http = {
  endpoint = "https://otel.exemple.com/v1/logs",
  headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }
} }
log_user_prompt = false  # Redact les prompts par défaut

Les événements émis incluent : démarrages de conversation, requêtes API (statut, durée, erreurs), événements de stream, décisions d’approbation des outils (autorisé/refusé, source config vs utilisateur), et résultats d’exécution (durée, succès, extrait de sortie). Les prompts utilisateur sont redactés par défaut. Activez log_user_prompt = true seulement si vous comprenez les implications pour la vie privée.

Sandbox par plateforme

macOS : Seatbelt

Sur macOS, Codex utilise Seatbelt (sandbox-exec), le mécanisme de sandboxing natif d’Apple. Il contraint les processus enfants (les commandes de l’agent) dans un profil de sécurité qui limite l’accès au filesystem et au réseau. Si vous rencontrez des erreurs sandbox-exec ENOENT, vérifiez que Xcode Command Line Tools est installé (xcode-select --install) et que les permissions de votre répertoire de travail sont correctes.

Linux : Landlock

Sur Linux, Codex utilise Landlock (le framework de sandboxing du kernel Linux) avec un pipeline bubblewrap optionnel pour une isolation plus poussée. Landlock nécessite un kernel récent. Sur WSL2, vérifiez que votre version est à jour si vous rencontrez des erreurs « Landlock unsupported ». En dernier recours dans un environnement isolé, --dangerously-bypass-approvals-and-sandbox contourne le sandbox, mais c’est fortement déconseillé en dehors d’un container jetable.

Windows

Le support Windows est expérimental pour la CLI. L’app desktop utilise un sandbox natif Windows avec des binaires helper dédiés (codex-windows-sandbox-setup.exe). Configurez le mode sandbox Windows dans la table [windows] de votre config : sandbox = "elevated" (recommandé, nécessite les droits admin) ou sandbox = "unelevated" (fallback sans admin).

Codex Cloud

En mode cloud, chaque tâche s’exécute dans un container isolé managé par OpenAI. Le container est préchargé avec votre repo et les dépendances installées pendant la phase de setup (avec réseau). Puis la phase agent commence avec le réseau désactivé. Les secrets sont supprimés entre les deux phases. C’est le modèle d’isolation le plus fort car l’agent n’a jamais accès à votre machine locale.

Bonnes pratiques de sécurité

Commencez restrictif, élargissez progressivement. Démarrez en read-only + untrusted pour comprendre le comportement de l’agent. Passez à workspace-write + on-request quand vous êtes à l’aise. N’utilisez danger-full-access que dans des environnements jetables.

Utilisez les rules plutôt que le full access. Si votre workflow nécessite seulement npm test et npm run build avec réseau, autorisez ces commandes spécifiques via les rules au lieu de donner un accès total.

Marquez les projets inconnus comme untrusted. Un repo cloné d’une source non vérifiée peut contenir un .codex/config.toml malveillant. Le mode untrusted ignore ces fichiers de config projet.

Contrôlez les variables d’environnement. Utilisez [shell_environment_policy] avec include_only pour limiter les variables transmises aux sous-processus. Évitez d’exposer des tokens API ou des secrets via les variables d’environnement de l’agent.

Désactivez les login shells. Mettez allow_login_shell = false pour empêcher les outils shell de demander des shells de connexion, ce qui durcit l’environnement d’exécution.