Checklist gouvernance & sécurité (OpenAI)

Ceci est une checklist par couches pour déployer les produits OpenAI en toute sécurité dans une organisation, tirée de la documentation OpenAI publiée sur les contrôles entreprise, la sécurité et l’administration de Codex. C’est une préparation indépendante, pas un cadre de conformité officiel — vérifiez chaque contrôle contre les docs OpenAI actuelles et vos propres obligations réglementaires avant de vous y fier.

Les couches, en un coup d’œil

        ┌───────────────────────────────────────┐
        │ Identity & access  (who can call)      │
        ├───────────────────────────────────────┤
        │ Network            (from where)        │
        ├───────────────────────────────────────┤
        │ Data               (what is stored)    │
        ├───────────────────────────────────────┤
        │ Safety             (what is allowed)   │
        ├───────────────────────────────────────┤
        │ Operations         (limits & audit)    │
        ├───────────────────────────────────────┤
        │ Codex              (agent-specific)    │
        └───────────────────────────────────────┘
     Each layer fails independently; secure all of them.

Couche 1 — Identité et accès

Contrôlez qui peut s’authentifier et ce que chaque identité peut faire.

• SSO — SAML SSO pour le workspace afin que l’accès suive votre fournisseur d’identité, et non des mots de passe autonomes.
• SCIM — provisioning automatisé et, surtout, dé-provisioning pour qu’un partant perde l’accès immédiatement.
• RBAC — rôles et permissions de workspace accordés au moindre privilège ; tout le monde n’a pas besoin d’être admin.
• Service accounts — identités non humaines pour l’automatisation, séparées des utilisateurs individuels, pour qu’un départ ne casse pas un pipeline.
• Workload identity federation — pour les appelants automatisés, fédérez depuis votre plateforme (Kubernetes, AWS, Azure, GCP, OCI, GitHub Actions, SPIFFE, X.509) au lieu de clés statiques longue durée.
• Personal access tokens (PATs) — restreints et rotés ; traitez un PAT fuité comme un incident ; préférez la fédération ou les service accounts aux tokens personnels pour l’automatisation.
• Vérification de domaine — vérifiez vos domaines pour que l’appartenance au workspace corresponde à votre organisation.

Couche 2 — Réseau

Contrôlez d’où proviennent les appels et comment le trafic est protégé.

• Private Link — connectivité privée pour que le trafic ne traverse pas l’internet public là où c’est proposé.
• IP allowlist — restreignez l’accès aux plages d’egress corporate connues.
• Mutual TLS (mTLS) — authentification mutuelle pour les appels service-à-service à haute assurance.
• IP egress ranges — épinglez les plages d’egress publiées par la plateforme dans vos règles de pare-feu pour les webhooks et callbacks entrants.
• Provider Terraform — gérez ce qui précède en code pour que la posture réseau soit revue et reproductible, non configurée au clic.

Couche 3 — Données

Contrôlez ce qui est stocké, où et pour combien de temps.

• Région de résidence — choisissez une région de résidence des données qui satisfait votre obligation. La résidence des données ChatGPT enterprise est disponible dans dix régions : US, EU, UK, JP, CA, KR, SG, IN, AU, UAE.
• No-training par défaut — confirmez que les données business et enterprise ne sont pas utilisées pour entraîner les modèles par défaut ; c’est le comportement par défaut pour ces tiers.
• Rétention — réglez la rétention au minimum dont le cas d’usage a besoin ; loguez et revoyez.
• Zero Data Retention (ZDR) — là où c’est disponible et requis, pour que le contenu des requêtes éligibles ne soit pas retenu.
• Chiffrement — TLS 1.2 en transit et AES-256 au repos sont le socle de la plateforme ; EKM (enterprise key management) là où vous devez détenir les clés.
• Contrôles de vos données — appliquez les contrôles de données documentés pour ce qui est stocké, partagé et exporté.

Couche 4 — Sécurité

Contrôlez ce que le système est autorisé à produire et à faire.

• Safety classifiers — appliquez les safety classifiers documentés aux entrées et aux sorties.
• Moderation — filtrez le contenu utilisateur et la sortie du modèle pour les violations de politique avant qu’ils n’atteignent les utilisateurs ou les systèmes.
• Red teaming — sondez le déploiement de façon adversariale avant et après le lancement ; documentez les constats et les correctifs.
• Surveillance de désalignement — surveillez tout comportement dérivant des objectifs visés, en particulier dans les déploiements agentiques.
• Provenance du contenu — appliquez des signaux de provenance pour le contenu généré là où la divulgation importe.
• Guidance sous-18 ans — suivez la guidance documentée sur les moins de 18 ans pour tout déploiement accessible aux mineurs.
• Guidance CSAM — suivez la guidance CSAM documentée ; c’est non négociable et à signaler.
• Contrôles cybersécurité — appliquez les contrôles de cybersécurité documentés ; les modèles spécialisés en sécurité sont réservés au travail de sécurité autorisé uniquement.

Couche 5 — Opérations

Contrôlez le coût, le débit et l’auditabilité.

• Rate limits — posez des rate limits par projet pour qu’une charge de travail n’affame pas une autre.
• Spend limits — posez des spend limits et des alertes pour qu’un job emballé ne devienne pas une facture emballée.
• Admin API — gérez le workspace, les membres, les projets et les clés de façon programmatique.
• Analytics API — récupérez les analytics d’usage pour l’attribution de coût et le reporting d’adoption.
• Compliance API et audit events — exportez les audit events vers votre SIEM pour que chaque action d’administration et d’accès soit loguée et revue.
• Gestion des erreurs — gérez les codes d’erreur documentés avec backoff sur les erreurs transitoires ; ne retentez pas aveuglément les 4xx.

Couche 6 — Contrôles propres à Codex

Codex agit sur du code, il lui faut donc une gouvernance propre aux agents au-delà des couches ci-dessus.

• Permission modes et profiles — réglez le permission mode par environnement ; l’agent ne devrait pas avoir de droits d’écriture ou d’exécution en bloc.
• Sandboxing — exécutez l’agent en sandbox (y compris le Windows sandbox et WSL le cas échéant) ; accès réseau contrôlé.
• Contrôles d’accès internet du cloud — restreignez ce qu’un environnement Codex cloud peut atteindre.
• Approvals — exigez des approvals d’agent et une revue humaine pour les actions sensibles ; n’auto-approuvez pas les opérations destructives.
• Auto-review et Codex Security — activez l’auto-review ; utilisez Codex Security (plugin, CLI, cloud) pour les scans, deep scans, le security workbench, le triage, les correctifs et les rapports de vulnérabilité, câblés dans la CI ou GitLab CI.
• Configuration managée — imposez un config.toml managé et des règles AGENTS.md pour que les individus ne puissent pas élargir silencieusement les permissions.
• Auth pour les agents — utilisez la workload identity, les service accounts ou des personal access tokens restreints ; notez que certains modèles à connexion ChatGPT sont retirés selon un calendrier (par exemple gpt-5.4 et gpt-5.4-mini sont retirés de Codex avec connexion ChatGPT le 31 août 2026) tandis que la connexion par clé API n’est pas affectée.
• Groupes, provisioning et cycle de vie — gérez les utilisateurs Codex via des groupes, du provisioning et un processus de user-lifecycle, avec rôles et permissions de workspace.
• Contrôles sectoriels — appliquez la configuration HIPAA et des intégrations comme Prisma AIRS là où le secteur l’exige.

Qui valide quoi

Un contrôle n’est réel que si quelqu’un en est propriétaire. Cette matrice est un point de départ ; adaptez-la à votre organisation.

Une séquence de go-live minimale

1. L’identité d’abord — SSO et SCIM en place, RBAC au moindre privilège, automatisation sur service accounts ou fédération, aucun compte partagé.
2. Décisions de données enregistrées — région de résidence choisie, no-training par défaut confirmé, rétention réglée, ZDR ou EKM décidés là où requis (et la contrainte de résidence de l’Agents-harness notée).
3. Réseau clôturé — allowlist, Private Link ou mTLS selon le niveau d’assurance demandé, géré en code.
4. Sécurité câblée — moderation et classifiers sur entrées et sorties, constats de red-team traités, guidance sous-18 et CSAM appliquée là où c’est accessible.
5. Opérations instrumentées — rate et spend limits posés, audit events remontant au SIEM, gestion des erreurs avec backoff.
6. Codex gouverné — permission modes, sandboxing, approvals, auto-review et config managée en place avant que les agents ne touchent un vrai repo.
7. Sign-off enregistré — chaque ligne de la matrice a un propriétaire nommé et une approbation datée.

Idées reçues fréquentes

Points clés à retenir

• Sécurisez chaque couche indépendamment : identité, réseau, données, sécurité, opérations et Codex — une faille dans l’une défait les autres.
• Imposez avec des contrôles de plateforme (accès, résidence, rétention, moderation, sandboxing), jamais avec du texte de prompt.
• Préférez SSO, SCIM, RBAC, service accounts et workload identity federation aux clés personnelles longue durée.
• Confirmez le no-training-par-défaut et choisissez résidence, rétention, ZDR et EKM selon votre obligation.
• Le managed Agents harness est US-only sans ZDR ; routez ailleurs les charges ZDR ou non-US.
• Gouvernez Codex comme un agent : permission modes, sandboxing, approvals, auto-review et une configuration managée.
• Chaque contrôle a besoin d’un propriétaire nommé et d’un sign-off daté, et les audit events doivent atteindre votre SIEM.