Guide de configuration HIPAA pour Codex

À qui s'adresse ce guide

Ce guide s’adresse aux administrateurs informatiques et aux professionnels de la conformité qui souhaitent se familiariser avec la responsabilité partagée relative à la gestion des informations de santé protégées (PHI) dans Codex. Codex comprend l’app de bureau ChatGPT, l’extension Codex pour IDE et Codex CLI, qui s’exécutent sur les ordinateurs de vos utilisateurs. Il n’inclut pas l’utilisation de Codex dans le cloud.

Si vous utilisez ChatGPT for Healthcare, ChatGPT for Clinicians ou un espace de travail Regulated, disposez d’un accord d’association commerciale OpenAI (BAA) applicable et bénéficiez de l’accès requis à Codex, OpenAI traite les PHI reçues de Codex conformément au BAA. OpenAI traite de manière sécurisée les prompts, fichiers et autres entrées reçus dans le cadre de votre utilisation de Codex, puis vous renvoie les sorties de manière sécurisée.

OpenAI et votre organisation partagent la responsabilité de la sécurisation des services OpenAI. Il vous incombe de configurer de manière sécurisée les postes de travail locaux, les dépôts de code source, la conservation locale, les serveurs MCP locaux, les activités Browser Use et Computer Use, les apps de bureau et les services tiers tels que les plugins et les apps.

OpenAI fournit des ressources pour vous aider à configurer Codex, notamment notre page web, la documentation et le livre blanc sur la sécurité de Codex disponible sur le Trust Portal. Consultez ces ressources avant d’autoriser l’utilisation de Codex avec des PHI. Ce guide fournit des exemples d’utilisation de certains de ces outils.

Responsabilité partagée

Comme pour la plupart des solutions cloud, le fournisseur de services cloud et le client partagent la responsabilité de la conformité. ChatGPT Enterprise stocke les entrées et les sorties dans le cloud OpenAI. Les postes de travail de vos utilisateurs conservent les entrées et les sorties de Codex. Codex envoie à OpenAI des entrées, telles que des prompts et des fichiers, à des fins d’inférence, puis OpenAI renvoie les sorties. Pour les utilisations authentifiées via ChatGPT, OpenAI conserve les journaux d’audit pendant une durée maximale de 30 jours afin que vous puissiez les récupérer via la Compliance API. OpenAI n’utilise pas les données de ChatGPT Enterprise ni celles de Codex pour entraîner ses modèles.

La configuration de vos postes de travail locaux, en particulier leurs fichiers de politique TOML, régit les opérations que Codex peut effectuer sur la machine d’un utilisateur. Elle détermine notamment si Codex peut lire et écrire des fichiers, exécuter des commandes, accéder au réseau, appeler des plugins ou des connecteurs, appeler des outils MCP, ouvrir des interfaces de navigateur et conserver des transcriptions locales.

Ces paramètres ne modifient pas les obligations d’OpenAI au titre du BAA, mais ils sont essentiels à vos mesures de protection HIPAA. Il vous incombe de les configurer conformément à vos politiques de traitement des PHI.

Programme de sécurité d'OpenAI

OpenAI maintient un programme de sécurité d’entreprise conçu pour protéger les données traitées par les services OpenAI et aider les organisations réglementées à respecter leurs obligations de conformité. Vous trouverez plus d’informations sur le programme de sécurité d’OpenAI sur le Trust Portal.

OpenAI déploie un programme de gestion des risques d'entreprise et une structure formelle de gouvernance des risques qui prévoit la communication d'informations aux comités du conseil d'administration. Les activités d'assurance produit contribuent à garantir que les lancements de produits préservent des mesures de protection telles que le chiffrement, les accès selon le principe du moindre privilège et une journalisation granulaire afin de favoriser la conformité HIPAA. Les évaluations des risques liés aux produits, la surveillance des contrôles et les examens de conformité permettent d'identifier les risques raisonnablement prévisibles pour vos données, d'évaluer l'efficacité des mesures de protection et de soutenir l'amélioration continue des contrôles utilisés par ChatGPT Enterprise, la plateforme API et les services liés à Codex.

Les mesures de protection du développement sécurisé et de la CI/CD contribuent à réduire le risque que des modifications apportées aux services liés à Codex introduisent des accès non autorisés, des fuites de données ou des problèmes d'intégrité. Ces mesures comprennent un accès contrôlé au code source, la revue par les pairs, des tests automatisés, des contrôles de sécurité dans les workflows de compilation et de déploiement, des contrôles de gestion des secrets et des processus de déploiement surveillés. Un processus contrôlé de livraison logicielle protège la couche de services OpenAI, tandis que vous restez responsable de la bonne gestion des dépôts locaux, de la sécurité des postes de travail et des comportements autorisés par la configuration des fichiers de politiques locaux.

Le programme de gestion des vulnérabilités d'OpenAI comprend des analyses continues, des examens des dépendances et de l'infrastructure, un tri selon la gravité, le suivi des corrections et la validation de celles-ci. OpenAI fait également appel à des équipes rouges internes et externes, à des tests de sécurité indépendants et à des canaux de divulgation responsable afin d'identifier et de corriger les faiblesses de sécurité avant qu'elles ne puissent affecter vos données.

Les contrôles de protection des données comprennent le chiffrement de vos données en transit et au repos, des contrôles d'identité et d'accès, une administration fondée sur les rôles, la journalisation et des contrôles de conservation conformes aux paramètres applicables de l'organisation ChatGPT Enterprise ou API.

Connexion à Codex

Codex prend en charge deux méthodes de connexion à OpenAI lors de l’utilisation de modèles OpenAI : la connexion avec ChatGPT pour l’accès par abonnement et la connexion avec une API key pour l’accès facturé à l’usage. La connexion avec ChatGPT nécessite un compte éligible à HIPAA, le BAA OpenAI applicable, ainsi que l’accès requis à Codex et les autorisations requises dans l’espace de travail. Pour la connexion avec une API key, le BAA couvre les données traitées par OpenAI uniquement s’il inclut les API Services avec Modified Retention en tant qu’Eligible Service. OpenAI doit également configurer l’organisation API avec Modified Retention, sauf indication contraire dans le BAA. Pour en savoir plus, consultez Produits et fonctionnalités éligibles à HIPAA. Il vous incombe de conclure un BAA avec tout tiers susceptible d’accéder à des PHI via un plugin ou une app installée.

Avec la connexion ChatGPT, l'utilisation de Codex suit les autorisations de l'espace de travail ChatGPT de l'utilisateur, le contrôle d'accès fondé sur les rôles (RBAC), ainsi que les paramètres de conservation et de résidence des données de ChatGPT Enterprise. Avec la connexion par API key, l'utilisation de Codex suit les paramètres de conservation, de partage des données et d'administration de l'organisation OpenAI API plutôt que ceux de l'espace de travail ChatGPT. La connexion par API key est couramment utilisée pour les workflows Codex CLI programmatiques, tels que les tâches CI/CD de confiance, mais vous ne devez pas exposer d'API keys dans des environnements d'exécution publics ou non fiables.

Vos responsabilités

Vous restez responsable des postes de travail sur lesquels Codex s’exécute. Réalisez votre propre analyse des risques liés à l’utilisation locale de Codex, notamment concernant des contrôles tels que la configuration des postes de travail, la sécurité du système d’exploitation, le chiffrement des disques, la protection contre les logiciels malveillants, la gestion des appareils, l’application des correctifs, l’accès des utilisateurs, le stockage sécurisé des identifiants et la conservation locale.

Vous déterminez quels utilisateurs peuvent utiliser Codex, quelles méthodes de connexion ils peuvent employer, à quels espaces de travail ils peuvent accéder, s’ils peuvent se connecter avec une API key, quels dépôts et dossiers peuvent contenir des PHI et si Codex peut utiliser des services externes.

Vous êtes également responsable des services tiers activés et des utilisateurs qui y ont accès. Si votre organisation active une destination de navigateur, un plugin, un connecteur ou un serveur MCP pour Microsoft SharePoint, Google Drive, GitHub ou un autre service dans un environnement contenant des PHI, vérifiez qu'elle autorise l'utilisation de ce service pour les PHI et dispose d'un BAA approprié ou d'un avenant comparable relatif aux données de santé. Le BAA d'OpenAI ne fait pas d'un autre fournisseur une destination conforme à HIPAA.

Les sections suivantes expliquent comment utiliser le fichier de configuration de politique requirements.toml et les paramètres associés pour contrôler le fonctionnement de Codex. Consultez la documentation OpenAI pour découvrir les autres paramètres et réexaminez-les régulièrement à mesure que les fonctionnalités de Codex évoluent.

Activer Codex

Suivez les instructions de configuration de Codex Enterprise pour les administrateurs afin d’activer Codex Local pour votre espace de travail, puis vérifiez que les utilisateurs disposent des autorisations requises et que vous avez conclu un BAA avec OpenAI.

Le BAA ne couvre pas Codex cloud. N'utilisez pas Codex cloud avec des PHI.

Configurer le contrôle d'accès fondé sur les rôles

Vous pouvez personnaliser l’accès à Codex et à sa configuration à l’aide du RBAC. Par exemple, les utilisateurs qui ne manipulent pas de PHI peuvent recevoir une configuration plus permissive, tandis que ceux qui en manipulent peuvent recevoir la configuration présentée dans ce guide. Gérez l’accès à Codex à l’échelle de l’organisation depuis la page des autorisations et des rôles d’administration de ChatGPT. Pour gérer l’accès d’utilisateurs spécifiques, créez des groupes et modifiez leurs autorisations.

Examiner les plugins et les connecteurs

Codex dans l'application de bureau ChatGPT et Codex CLI prennent en charge les plugins, qui peuvent inclure des connecteurs et des skills. Les plugins ne sont pas disponibles dans l'extension IDE. Les connecteurs vous permettent d'échanger des données avec des sources de données tierces. Avant d'activer un plugin doté d'un connecteur, déterminez si vous avez besoin d'un BAA avec tout tiers recevant des données par son intermédiaire. Les skills sont des instructions qui s'exécutent dans le cadre de la configuration des politiques. Vérifiez qu'ils sont adaptés à l'usage prévu, comme vous le feriez pour tout autre script.

Les administrateurs de l’espace de travail doivent rendre un plugin disponible au moyen des contrôles des plugins, puis activer séparément ses connecteurs avant que les utilisateurs puissent s’en servir. Configurez l’accès aux connecteurs dans les paramètres des connecteurs.

Configurer les exigences gérées et les valeurs par défaut

Les exigences et les valeurs par défaut gérées définies dans les fichiers de configuration TOML régissent le comportement de Codex. Pour définir des contraintes imposées par les administrateurs que les utilisateurs ne peuvent pas remplacer, utilisez les exigences gérées dans requirements.toml. OpenAI recommande d’utiliser une configuration gérée pour faire respecter vos exigences de traitement des données relatives aux PHI.

Les administrateurs peuvent configurer des exigences gérées dans le cloud sur la page de configuration gérée de Codex en utilisant une syntaxe compatible avec requirements.toml. Ils peuvent également distribuer les exigences au moyen d’une solution de gestion des appareils telle que macOS MDM. Codex applique les exigences par ordre de priorité croissante : le fichier requirements.toml du système, les exigences gérées dans le cloud, les exigences de l’ancien fichier managed_config.toml, puis les exigences macOS MDM. Les couches de priorité supérieure remplacent les valeurs scalaires et les listes ordinaires ; certaines exigences suivent un comportement de fusion propre à leurs champs.

Pour limiter les workflows traitant des PHI à un espace de travail ChatGPT approuvé, déployez allowed_login_methods = ["chatgpt"] et allowed_chatgpt_workspaces = ["<workspace-id>"] par l'intermédiaire de requirements.toml système ou de MDM. Les exigences gérées dans le cloud ignorent ces deux paramètres, et les restrictions d'espace de travail seules ne bloquent pas la connexion par API key. Les workflows utilisant une API key nécessitent également des exigences système ou MDM, car ils ne reçoivent pas les exigences gérées dans le cloud de l'espace de travail.

Les valeurs par défaut gérées sont distinctes des exigences. Elles définissent la configuration initiale avec laquelle Codex démarre, mais les utilisateurs peuvent modifier ces paramètres pendant une session. Codex réapplique les valeurs par défaut lors de son prochain démarrage. Utilisez les valeurs par défaut gérées à des fins de standardisation, et non pour imposer strictement la conformité. Vous pouvez, par exemple, définir un modèle, un profil d'autorisation ou un autre comportement local privilégié par défaut. Si un paramètre ne doit pas pouvoir être contourné pour les workflows traitant des PHI, placez-le plutôt dans les exigences. Pour les valeurs par défaut gérées, les préférences gérées macOS MDM ont la priorité la plus élevée, suivies de managed_config.toml système, puis de config.toml local de l'utilisateur.

Le tableau suivant récapitule certains paramètres disponibles pour configurer Codex. Consultez ces paramètres ainsi que les ressources de la section Références afin de configurer Codex conformément à vos besoins de conformité.

1. La valeur "granular" permet aux administrateurs d’autoriser des politiques d’approbation granulaires. Dans allowed_approval_policies, encodez-la sous forme de table en ligne définissant chaque catégorie d’approbation :

   allowed_approval_policies = [
     "on-request",
     "untrusted",
     "never",
     { granular = { sandbox_approval = true, rules = true, mcp_elicitations = true, request_permissions = true, skill_approval = true } },
   ]

Pour sélectionner une politique granulaire dans config.toml, configurez approval_policy avec la même structure de table en ligne. Lorsqu’une catégorie vaut false, Codex rejette ces demandes au lieu de solliciter une approbation.

2. Les listes d’autorisation des profils d’autorisation nécessitent Codex 0.138.0 ou une version ultérieure. Pour appliquer la restriction indiquée dans le tableau, incluez la liste d’autorisation complète dans requirements.toml :

   default_permissions = ":workspace"

   [allowed_permission_profiles]
   ":read-only" = true
   ":workspace" = true

Lorsque [allowed_permission_profiles] est présent, les profils omis sont refusés. L’omission de :danger-full-access empêche donc les utilisateurs de sélectionner l’accès complet.

Conservez untrusted dans allowed_approval_policies pour préserver la politique d’approbation plus stricte que Codex déduit pour les projets avec trust_level = "untrusted". Ne définissez pas approval_policy = "untrusted" directement ; Codex et ChatGPT Work ne prennent plus en charge ce paramètre. Consultez Migrer depuis l’ancienne politique d’approbation untrusted retirée.

Exemple 1 : activer le plugin Google Drive

N'activez Google Drive que pour un groupe approuvé, après avoir vérifié ses flux de données, ses portées OAuth, ses contrôles d'accès et la situation du BAA du tiers. Le BAA d'OpenAI régit le traitement des PHI par OpenAI ; il ne couvre pas automatiquement Google en tant que destinataire ou détenteur de PHI.

Ce connecteur géré par l’espace de travail nécessite une connexion à ChatGPT et n’est pas disponible avec une authentification par API key.

Codex utilise la clé de configuration apps pour les paramètres des connecteurs. Cet exemple définit des valeurs locales par défaut pour le connecteur Google Drive. Remplacez <approved-google-drive-app-id> par l’ID d’application exact de votre installation approuvée ; un nom d’affichage ou un ID supposé ne permettra pas d’appliquer la configuration.

# Example config.toml change for a group approved to use
# the Google Drive connector with PHI, after legal and security review.
[features]
apps = true
[apps."<approved-google-drive-app-id>"]
enabled = true
destructive_enabled = false
default_tools_approval_mode = "prompt"

Ces valeurs par défaut configurables par l'utilisateur bloquent les outils de connecteur marqués comme destructifs et demandent une approbation, sauf si des paramètres propres à l'application ou à l'outil les remplacent. Elles ne constituent pas des contrôles administratifs impossibles à contourner. Utilisez les contrôles de l'espace de travail et le RBAC pour restreindre l'accès, et les exigences gérées pour désactiver une application ou imposer une approbation à certains outils approuvés. Consultez les journaux d'audit Google Workspace relatifs à l'activité des connecteurs lorsqu'ils sont disponibles.

Exemple 2 : utiliser GitHub localement

Pour le développement local, de nombreuses équipes utilisent Git ou GitHub CLI depuis le poste de travail du développeur. Cette approche diffère de Codex cloud. Si des dépôts, issues, pull requests ou commentaires peuvent contenir des PHI, vérifiez que votre organisation approuve l'environnement GitHub pour ces données avant d'activer cette possibilité.

# Example requirements.toml addition for local GitHub use.
# This doesn't enable Codex cloud. It keeps repository actions reviewable.
[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before changing repository history." },
  { pattern = [{ token = "gh" }], decision = "prompt", justification = "Require review before using GitHub CLI." },
]

Cette politique ne bloque pas l'utilisation de GitHub. Elle crée un point de contrôle avant que Codex ne modifie l'historique du dépôt ou n'utilise des commandes GitHub CLI.

Facultatif : utiliser un serveur MCP GitHub approuvé

Si votre équipe utilise un serveur MCP GitHub plutôt que de simples commandes Git locales, ajoutez l'identité exacte du serveur approuvé à la liste d'autorisation et limitez ses outils au plus petit ensemble approuvé.

# Optional: allow a vetted GitHub MCP server.
# Use the exact approved server identity for your environment.
# requirements.toml
[mcp_servers.github]
identity = { url = "https://github-mcp.example.com/mcp" }
# config.toml
[mcp_servers.github]
url = "https://github-mcp.example.com/mcp"
enabled = true
default_tools_approval_mode = "prompt"
enabled_tools = ["<approved-read-tools>", "<approved-pr-tools>"]

Étapes pratiques du déploiement

1. Sélectionnez la méthode de connexion approuvée. Décidez si les utilisateurs vont s'authentifier auprès de Codex Local avec ChatGPT, utiliser des API keys ou employer les deux pour des workflows distincts.
2. Confirmez le BAA avec OpenAI. Vérifiez que votre BAA couvre vos méthodes de connexion approuvées. Pour les workflows utilisant une API key, confirmez qu'il inclut les API Services avec Modified Retention en tant qu'Eligible Service et qu'OpenAI a configuré l'organisation API avec Modified Retention. Contactez votre responsable de compte OpenAI afin d'activer la prise en charge HIPAA de Codex pour un espace de travail ChatGPT.
3. Activez Codex Local et définissez les groupes RBAC. Utilisez la configuration de Codex Enterprise pour les administrateurs afin d'activer Codex Local, de créer un petit groupe d'administrateurs Codex et d'accorder l'accès à Codex par l'intermédiaire de groupes RBAC tels que Codex Users et Codex PHI Users.
4. Déployez le fichier requirements.toml imposé par les administrateurs et les valeurs par défaut gérées. Utilisez les exigences gérées dans le cloud, MDM ou la configuration système pour les paramètres pris en charge de la politique de démarrage. Utilisez la configuration système ou MDM pour les restrictions de connexion, l'épinglage de l'espace de travail et les workflows utilisant une API key. Configurez les profils d'autorisation, les politiques d'approbation, les modes de recherche web, les restrictions de fonctionnalités, les exigences réseau, les règles de commande et les listes d'autorisation MCP.
5. Formez les utilisateurs aux approbations et aux limites du bac à sable. Utilisez Approbations des agents et sécurité pour expliquer quand Codex peut agir dans le bac à sable, quand il demande une approbation et pourquoi les utilisateurs doivent examiner les actions impliquant le réseau, le transfert de fichiers, l'écriture dans les dépôts et les connecteurs tiers.
6. Examinez les plugins tiers avant toute utilisation avec des PHI. Avant d'activer des plugins dotés de connecteurs tels que Google Drive et GitHub, des destinations de navigateur ou des serveurs MCP, vérifiez que votre organisation approuve tout tiers recevant des PHI et dispose d'un BAA approprié avec celui-ci.
7. Suivez, examinez et actualisez le déploiement. Utilisez les exportations de la Compliance API, les données analytiques de l'espace de travail, les journaux des terminaux, les journaux d'audit des plugins et des services connectés, ainsi que les journaux d'audit des dépôts, afin de vérifier que la configuration déployée reste conforme à vos politiques internes.

Références

• Authentification de Codex
• Principes de base de la configuration de Codex
• Configuration de Codex Enterprise par les administrateurs
• Configuration gérée de Codex
• Approbations des agents et sécurité
• Model Context Protocol de Codex
• Gouvernance de Codex
• Autorisations de Codex
• Consultez les fonctionnalités de ChatGPT Healthcare et de Regulated Workspace.
• Consultez ChatGPT for Clinicians.
• Consultez l’article sur le Business Associate Agreement pour les services de l’API OpenAI.
• Consultez le livre blanc sur la sécurité de Codex.