Documentation ChatGPT
Français
Contact goolvyouyou@gmail.com

Agent Security

Gérer les stratégies Global et les paramètres d’environnement pour ChatGPT Work et Codex

Utilisez Agent Security dans la console d’administration pour gérer les stratégies et la configuration. Il remplace Policies & Configuration. Son déploiement est indépendant de l’accès à l’ordinateur local pour Work et les dots.

Lors de la migration des anciennes stratégies cloud éligibles, leurs paramètres sont transférés dans Global, en conservant les affectations et l’ordre des stratégies. Examinez les stratégies migrées dans Agent Security. L’accès à l’ordinateur local nécessite une activation distincte pour Work et pour les dots.

Où les paramètres s’appliquent

Chaque stratégie repose sur une base Global. Les paramètres de remplacement par environnement modifient les paramètres d’exécution pris en charge pour Local ou Codex Cloud. Lorsqu’un environnement ne définit aucun remplacement, il hérite des paramètres Global applicables de cette stratégie.

  • Global : définissez les contrôles de l’orchestrateur, notamment les approbations et la recherche web, ainsi que les paramètres d’exécution partagés.

  • Local : ajustez les paramètres d’exécution pris en charge pour le travail effectué sur un ordinateur connecté.

  • Codex Cloud : ajustez les paramètres d’exécution pris en charge pour les tâches cloud Codex. Vous pouvez configurer ces stratégies avant d’activer Codex Cloud, mais elles ne s’appliquent qu’après son activation sur la page des autorisations. Work Cloud dispose d’autorisations de fonctionnalités distinctes, décrites dans Comment Agent Security s’applique à Work Cloud.

Définir une base et ajouter des paramètres d’environnement

  1. Ouvrez Agent Security et examinez vos stratégies Global existantes, leurs affectations et leur ordre. Vérifiez qu’elles correspondent aux contrôles prévus par votre organisation. Cet examen n’active pas l’accès à l’ordinateur local avec Work Cloud.

  2. Examinez séparément les exigences et les valeurs par défaut. Les exigences fixent des limites que les utilisateurs ne peuvent pas outrepasser. Les valeurs par défaut définissent les valeurs initiales à l’intérieur de ces limites.

  3. Conservez les contrôles de l’orchestrateur dans Global. Ils comprennent les exigences d’approbation, les modes de recherche web autorisés et les contrôles des outils gérés.

  4. Ajoutez des paramètres d’environnement Local ou Codex Cloud pour les contrôles d’exécution pris en charge, tels que l’isolation en bac à sable, les autorisations du système de fichiers et la gestion du réseau d’exécution. Utilisez un remplacement propre au système d’exploitation lorsque cette portée est nécessaire.

  5. Enregistrez la stratégie et examinez les éventuels messages de validation concernant les paramètres saisis.

Choisir les contrôles et les champs de configuration

L’orchestrateur coordonne la tâche. Un exécuteur est l’ordinateur ou le conteneur cloud qui effectue une étape d’exécution. Configurez les contrôles de l’orchestrateur dans Global. Les paramètres d’environnement requirements.toml prennent uniquement en charge les contrôles d’exécution. Les paramètres de l’orchestrateur, tels que la stratégie d’approbation et la recherche web, restent dans Global et ne peuvent pas être remplacés par un environnement.

Contrôles de l’orchestrateur

Configurez ces contrôles dans Global. Pour Work avec accès local et les dots, la stratégie Global prise en charge s’applique par l’intermédiaire de l’orchestrateur cloud partagé lorsque la stratégie gérée est activée. Les remplacements par environnement s’appliquent aux paramètres d’exécution pris en charge et ne peuvent pas remplacer les contrôles de l’orchestrateur. Parmi les exigences d’approbation, de recherche web, d’applications, de MCP, de plugins et de règles répertoriées ci-dessous, seules les Stratégies d’approbation autorisées et les Modes de recherche web autorisés disposent de contrôles dédiés dans l’interface d’Agent Security. Configurez les autres champs en TOML.

Contrôle Ce que ce contrôle régit Champs requirements.toml
Stratégies d’approbation et examen Quand l’agent a besoin d’une approbation et qui examine la demande, y compris en cas d’examen automatique. allowed_approval_policies
allowed_approvals_reviewers
auto_review
guardian_policy_config
Modes de recherche web Les modes de recherche web que l’agent peut utiliser. allowed_web_search_modes
Applications, MCP servers et plugins Les applications, MCP servers et plugins disponibles, ainsi que leur configuration. apps
mcp_servers
plugins
Commandes : rules Les commandes que l’agent peut exécuter, celles qui nécessitent une approbation et celles qu’il ne peut pas exécuter. rules
Gestion de hooks Les actions définies par les administrateurs lors des événements de tâche et d’outil pris en charge. hooks
allow_managed_hooks_only

Hooks avec l’accès à l’ordinateur local via Work Cloud

Lorsque la stratégie gérée et les hooks distants sont activés, Work Cloud avec accès local et les dots utilisent des hooks MCP distants gérés par les administrateurs sur l’orchestrateur cloud. Configurez les gestionnaires mcp_tool dans requirements.toml au niveau Global. Work Cloud sans accès local et les comptes personnels n’utilisent pas ces hooks d’entreprise. Les gestionnaires de commande/shell, de prompt et d’agent ; les hooks issus de la configuration locale, de plugins ou de répertoires locaux ; les hooks limités à un environnement ; et les hooks MCP SessionEnd ne sont pas pris en charge avec l’orchestration cloud, même lorsque les outils s’exécutent localement. Lorsque l’orchestration et l’exécution sont toutes deux locales, les hooks existants pris en charge continuent de fonctionner dans les fils Work et Codex exclusivement locaux. Les administrateurs peuvent toujours configurer les hooks gérés pris en charge dans Agent Security pour ces workflows.

Avant de vous appuyer sur ces hooks, testez la connectivité des rappels, les événements requis et le comportement en cas d’échec. Un refus explicite pris en charge peut bloquer une action, mais une erreur de rappel PreToolUse, un dépassement du délai ou une réponse mal formée peuvent faire échouer le hook sans bloquer l’outil. Les hooks MCP ne fournissent pas de piste d’audit complète dans la Compliance API.

Global contient également des paramètres de bureau et de client. Certains ne s’appliquent qu’à l’application de bureau. Configurer un paramètre dans Global ne signifie pas qu’il s’applique partout. Consultez la référence de configuration pour connaître les usages pris en charge par chaque champ.

Contrôles d’exécution (exécuteur)

Ces champs contrôlent la façon dont le travail s’exécute sur un ordinateur ou dans un conteneur cloud. Définissez les valeurs partagées dans Global. Utilisez des remplacements Local ou Codex Cloud pour les paramètres pris en charge qui doivent différer dans cet environnement.

Contrôle Ce que ce contrôle régit Champs requirements.toml
Utilisation d’un shell de connexion La possibilité pour les outils shell de démarrer un shell de connexion. allow_login_shell
Modes de bac à sable autorisés Les modes de bac à sable que l’exécuteur peut utiliser. allowed_sandbox_modes
Profils d’autorisations et valeurs par défaut Les profils d’autorisations autorisés, leurs limites d’accès et le profil par défaut. allowed_permission_profiles
default_permissions
permissions
Configuration du bac à sable distant Les modes de bac à sable propres à chaque hôte, sélectionnés par nom d’hôte. remote_sandbox_config
Gestion du réseau d’exécution L’accès réseau géré, notamment les destinations autorisées et interdites. experimental_network
Paramètres d’exécution Windows Les paramètres d’exécution et de bac à sable propres à Windows. windows

Le tableau indique les groupes de champs qui prennent en charge les remplacements par environnement. Les options prises en charge dans chaque groupe peuvent varier selon la plateforme, et certaines exigences se combinent entre stratégies au lieu de se remplacer. Consultez la référence de configuration pour connaître les valeurs prises en charge et la configuration gérée pour les exceptions réseau.

Sur les chemins d’exécution gérés de Codex Cloud pris en charge, les exigences d’Agent Security limitent l’accès réseau des commandes. Les paramètres Internet de l’environnement Codex Cloud s’appliquent séparément. Un domaine autorisé dans Agent Security ne lève pas une restriction définie dans les paramètres Internet de l’environnement Cloud. Ces contrôles réseau des commandes ne désactivent pas, à eux seuls, la recherche web hébergée, les applications ou MCP. ChatGPT Work Cloud dispose d’autorisations de fonctionnalités distinctes et n’hérite pas de ces exigences d’Agent Security.

Une liste d’autorisation gérée pour les commandes s’applique aux commandes qui utilisent le proxy géré. Lorsque la stratégie permet une élévation complète hors du bac à sable et que celle-ci est approuvée, cette exécution peut contourner le proxy des commandes. Une autorisation réseau limitée est différente d’une élévation complète hors du bac à sable. Configurez des exigences obligatoires d’approbation et de bac à sable adaptées à la limite souhaitée, puis testez les commandes ordinaires et celles exécutées avec élévation.

Configurer le réseau dans l’interface

  1. Ouvrez Console d’administration > Agent Security. Sélectionnez une stratégie, puis choisissez Global, Local ou Codex Cloud. Utilisez Global pour la base partagée et un remplacement par environnement pour les différences prises en charge.
  2. Ouvrez Exigences et activez Gérer le réseau. Ajoutez les entrées de domaine nécessaires, puis choisissez Autoriser ou Refuser pour chacune. Activez Autoriser uniquement les domaines ajoutés par les administrateurs si la configuration utilisateur ordinaire et les approbations par domaine ne doivent pas pouvoir étendre la liste d’autorisation du proxy géré.
  3. Examinez les paramètres effectifs et les règles héritées avant d’enregistrer. Des paramètres d’environnement vides héritent de Global au lieu d’en effacer les valeurs. Vérifiez séparément la connectivité locale/privée pour Codex Cloud. Désactiver Gérer le réseau n’équivaut pas à désactiver l’accès Internet de l’environnement Cloud.
  4. Pour Codex Cloud, vérifiez également les paramètres d’accès Internet, de destination et de méthode de l’environnement. Enregistrez, puis testez une requête censée être autorisée et une autre censée être bloquée. Testez séparément toute élévation complète hors du bac à sable permise.

Aucune destination effectivement autorisée

Lorsque Gérer le réseau et Autoriser uniquement les domaines ajoutés par les administrateurs sont activés, les commandes gérées ordinaires ont besoin de destinations effectivement autorisées. Si aucune entrée Autoriser n’est configurée ou héritée, ces commandes n’ont aucune destination autorisée. Une stratégie contenant uniquement des refus n’autorise pas implicitement le reste d’Internet. Ajoutez les entrées Autoriser nécessaires et vérifiez les règles héritées avant d’enregistrer. Cette restriction s’applique au proxy des commandes gérées, et non à tous les outils ni aux élévations complètes hors du bac à sable approuvées.

Connectivité locale/privée de Codex Cloud

Une valeur explicite de désactivation de la connectivité locale/privée peut empêcher Codex Cloud d’atteindre son proxy amont, même lorsque le domaine de destination est autorisé. Vérifiez la valeur finale de allow_local_binding et identifiez la stratégie ou le paramètre qui la fournit. Sur le chemin de proxy Cloud pris en charge, la valeur par défaut est true uniquement lorsqu’aucune exigence applicable, aucun profil réseau sélectionné ni aucun paramètre de fonctionnalité proxy ne fournit de valeur. Une valeur false héritée est tout de même considérée comme un paramètre explicite. Lorsque cela est pris en charge, définissez un remplacement Cloud de priorité supérieure pour modifier cette valeur pour Codex Cloud sans changer la valeur Global utilisée par Local. Cela n’ajoute pas d’entrées de domaine Autoriser. Vérifiez la prise en charge par l’exécuteur avant de vous appuyer sur ce remplacement. N’appliquez pas cette valeur par défaut Cloud à Local.

Valeurs par défaut des environnements

L’éditeur des valeurs par défaut utilise les champs config.toml, qui diffèrent des contraintes requirements.toml. Les valeurs par défaut d’environnement de premier niveau prises en charge sont :

  • Comportement du shell : allow_login_shell et shell_environment_policy.

  • Bac à sable et autorisations : sandbox_mode, sandbox_workspace_write, default_permissions et permissions.

  • Exécution Windows : windows.

Une valeur par défaut ne remplace pas une exigence obligatoire. Conservez les valeurs par défaut de l’orchestrateur, notamment les paramètres d’approbation et de recherche web, dans Global.

Comprendre comment les stratégies se combinent

  • Entre stratégies, une stratégie de priorité supérieure l’emporte sur une stratégie de priorité inférieure, même lorsque cette dernière est plus spécifique.

  • Au sein d’une même stratégie, les paramètres d’exécution pris en charge sont résolus dans cet ordre : remplacement d’environnement propre au système d’exploitation, remplacement d’environnement pour tous les systèmes d’exploitation, puis Global.

  • Pour l’exécution locale, MDM et les anciennes exigences des appareils gérés ont priorité sur Agent Security. Le fichier d’exigences système de l’appareil a une priorité inférieure à Agent Security.

Pour une même règle de domaine au sein d’une stratégie, un remplacement d’environnement défini par un administrateur peut autoriser un domaine refusé dans Global ou refuser un domaine autorisé dans Global. Sans remplacement d’environnement, la règle Global est héritée. D’autres règles Refuser effectives ou contrôles d’accès peuvent toujours bloquer une requête.

Ces résultats comparent la même clé de domaine au sein d’une stratégie, sans qu’une stratégie de priorité supérieure ne modifie le résultat. Une valeur de priorité supérieure remplace la même clé. Les autres clés héritées sont conservées. Une règle Autoriser ne contourne pas une autre règle Refuser correspondante, telle qu’une règle héritée avec caractère générique. Une table d’environnement vide n’efface pas les règles héritées.

Comment Agent Security s’applique à Work Cloud

Configurez Utilisation du navigateur cloud et Accès réseau cloud sous Console d’administration > Autorisations et rôles > Fonctionnalités de l’espace de travail > Fonctionnalités des ordinateurs cloud. Ces fonctionnalités partagées sont disponibles pour Work Cloud et les dots, et peuvent être configurées indépendamment de l’accès à Work Cloud. Une tâche Work nécessite toujours l’accès à Work et l’autorisation d’utiliser chaque fonctionnalité dont elle a besoin. Examinez séparément l’accès au navigateur et l’accès réseau du code ou du shell. Désactiver l’un ne désactive pas automatiquement l’autre.

Les conteneurs Work Cloud et les ordinateurs cloud des dots utilisent leur propre configuration d’exécution et leurs propres exigences, plutôt que l’ensemble de paramètres d’environnement gérés utilisé par les autres types d’exécuteurs. Les restrictions locales sur les fichiers et le réseau ne s’appliquent pas automatiquement à ces ordinateurs cloud. La stratégie d’orchestrateur Global prise en charge a une portée distincte. Une stratégie Global ou un remplacement Codex Cloud ne configure pas les autorisations des fonctionnalités cloud partagées. Examinez ces autorisations séparément.

Lorsque vous vérifiez l’accès effectif d’un membre, examinez les valeurs par défaut de l’espace de travail, tous les rôles attribués directement ou par groupe, ainsi que les restrictions imposées séparément, telles que Lockdown Mode.

Avant d’activer Autoriser l’accès à l’ordinateur local sous Work Cloud, examinez la base Global et vérifiez sa compatibilité avec les contrôles sur lesquels votre organisation s’appuie. Utiliser Codex localement dans l’application de bureau ChatGPT n’est pas un prérequis. Si enforce_residency est activé dans une stratégie cloud quelconque, Autoriser l’accès à l’ordinateur local est désactivé pour Work comme pour les dots. Cette protection ne configure pas la résidence des données de l’espace de travail et ne désactive pas, à elle seule, Work Cloud ou les dots. Consultez Accès à l’ordinateur local pour Work Cloud et les dots pour connaître les étapes de configuration distinctes, les critères d’éligibilité et le comportement de connexion.

API de stratégies et Terraform

Utilisez l’API de stratégies pour gérer les paramètres Global. Pour gérer les paramètres Local ou Codex Cloud, utilisez l’interface d’Agent Security. Les workflows API Global existants restent disponibles après la migration. Testez vos scripts et vos intégrations Terraform, puis confirmez que les affectations et l’ordre des stratégies sont inchangés.

La migration des stratégies ne modifie ni la synchronisation des appartenances SCIM ni les rôles RBAC.

Guides associés