Sécurité locale de ChatGPT Work

ChatGPT Work peut utiliser des fichiers, des applications et des sessions de navigateur approuvés sur l’ordinateur d’un utilisateur pour effectuer des tâches locales. L’accès dépend des autorisations de l’espace de travail, des accès existants du compte de l’utilisateur, des autorisations du système d’exploitation, des approbations d’applications et des politiques d’appareil prises en charge.

Pour une vue d’ensemble des contrôles de sécurité, consultez le livre blanc sur la sécurité de ChatGPT Work en entreprise.

Les fonctionnalités locales dépendent de l’application de bureau et du système d’exploitation pris en charge, des droits de l’espace de travail, des autorisations du rôle, de la politique de l’appareil et du déploiement du produit.

La sécurité en bref

• Les étapes locales s’exécutent via l’application de bureau ChatGPT. Avec l’accès à l’ordinateur local via Work Cloud, le cloud d’OpenAI coordonne la tâche tandis que l’ordinateur connecté exécute les étapes qui le nécessitent.

• Les contrôles Work disponibles pour les environnements locaux et hébergés dépendent de la configuration et du déploiement de l’espace de travail.

• L’accès aux fichiers, Computer Use, les navigateurs et les applications connectées utilisent des autorisations et des approbations différentes.

• Un navigateur ou une application déjà connecté à un système de l’entreprise peut donner accès aux autorisations de ce compte existant.

• Les politiques prises en charge pour les appareils gérés peuvent restreindre les fonctionnalités locales sans remplacer les contrôles d’accès de l’espace de travail.

• Les données des espaces de travail Business, Enterprise et Edu traitées par les services OpenAI concernés sont chiffrées en transit et au repos et, par défaut, ne sont pas utilisées pour entraîner les modèles OpenAI.

• Les fichiers locaux, le contexte des tâches, les données de navigateur, les enregistrements des systèmes connectés et les événements d’audit peuvent obéir à des règles de stockage et de conservation différentes.

Où s’exécutent les tâches locales

L’exécution locale accède aux ressources autorisées via l’application de bureau sur l’ordinateur de l’utilisateur. Lorsque l’accès à l’ordinateur local via Work Cloud est activé, le cloud d’OpenAI coordonne la tâche et sollicite l’ordinateur connecté lorsqu’une étape nécessite une exécution locale. L’ordinateur doit être en ligne et connecté pour ces étapes.

L’accès à l’ordinateur local via Work Cloud s’applique uniquement aux tâches créées après l’activation de la synchronisation. Les tâches existantes, y compris celles des projets, conservent leur mode d’origine : uniquement en local, ou dans le cloud sans accès aux fichiers locaux. Démarrez une nouvelle tâche pour utiliser cette fonctionnalité.

Si l’ordinateur est indisponible au début d’un nouveau tour, une tâche existante éligible utilisant l’accès à l’ordinateur local via Work Cloud peut se poursuivre dans un conteneur cloud. Ce conteneur ne peut pas accéder aux fichiers ni aux outils de l’ordinateur indisponible. Il n’applique pas non plus les exigences d’entreprise de l’exécution locale. Une tâche ne peut pas passer de l’exécution locale au cloud au cours d’un tour.

Les fichiers locaux peuvent rester sur l’appareil, mais des extraits pertinents de fichiers, des prompts, des captures d’écran, du contenu de navigateur ou des résultats d’outils peuvent être envoyés aux services OpenAI afin d’accomplir une tâche. L’exécution locale ne signifie pas que l’inférence du modèle s’effectue hors ligne ou uniquement sur l’appareil.

Accès aux fichiers et à l’appareil

Une tâche locale peut utiliser les informations que l’utilisateur fournit ou rend accessibles, notamment les fichiers pris en charge, le contenu des applications, les sessions de navigateur et les systèmes connectés autorisés. L’accès dépend des privilèges existants de l’utilisateur et des contrôles régissant la fonctionnalité concernée.

Accorder un accès local à Work n’approuve pas automatiquement toutes les applications, n’accorde pas de droits d’administrateur et ne contourne pas les autorisations du compte utilisé pour accéder à un autre système. Une connexion partagée approuvée peut disposer de privilèges différents de ceux du compte personnel de l’utilisateur.

Les lectures et modifications directes de fichiers ainsi que les commandes shell respectent les paramètres de sandbox et d’approbation de la tâche. Computer Use accède au contenu par l’intermédiaire d’une application native approuvée, avec les autorisations de cette application. Une restriction de l’accès direct aux fichiers n’impose pas, à elle seule, la même restriction aux fichiers que l’application peut ouvrir.

Computer Use et approbations d’applications

Les autorisations de l’espace de travail déterminent qui peut utiliser Work Local. Les politiques des administrateurs peuvent restreindre davantage les applications natives que Computer Use peut utiliser et déterminer si les approbations d’applications peuvent être enregistrées pour les sessions futures. Les autorisations requises par le système d’exploitation et les approbations d’applications restent nécessaires. Lorsqu’une tâche utilise une application ou un compte connecté, les autorisations de ce compte déterminent les informations et les actions disponibles.

Autoriser une application au moyen d’une politique d’administration n’installe pas le plugin requis, n’accorde pas les autorisations du système d’exploitation et n’approuve pas une action qui nécessite encore un examen. Pour connaître les contrôles pris en charge et consulter des exemples de configuration, voir Contrôles administrés du navigateur et de Computer Use.

Sur macOS, l’autorisation d’enregistrement de l’écran permet à Computer Use de voir le contenu des applications, tandis que l’autorisation d’accessibilité lui permet de cliquer, de saisir du texte et de naviguer. Les tâches macOS prises en charge peuvent s’exécuter en arrière-plan. Sous Windows, Computer Use fonctionne sur le bureau actif et visible et ne peut pas s’exécuter en arrière-plan pendant que l’utilisateur continue d’utiliser cette même session.

Les utilisateurs peuvent arrêter une tâche à tout moment. Computer Use ne peut pas approuver les invites de sécurité du système d’exploitation, s’authentifier en tant qu’administrateur ni automatiser les applications de terminal ou ChatGPT lui-même.

Appareils verrouillés

Les configurations macOS prises en charge peuvent, en option, autoriser une tâche Computer Use approuvée à se poursuivre après le verrouillage du Mac. La disponibilité dépend de la version de l’application, du déploiement de la fonctionnalité, des exigences applicables et de l’éligibilité au contrôle à distance.

L’activation de Locked Use installe un plugin d’autorisation macOS qui peut déverrouiller temporairement le Mac pendant un tour Computer Use actif et approuvé comme fiable. ChatGPT masque tous les écrans pendant ce déverrouillage temporaire. S’il détecte une saisie au clavier ou une action du pointeur en local, il verrouille à nouveau le Mac et suspend le déverrouillage automatique jusqu’à ce que l’utilisateur le déverrouille manuellement. Voir Fonctionnement de Locked Use.

Les administrateurs peuvent empêcher les utilisateurs d’activer Locked Use sur les Mac administrés. Cette exigence ne désactive pas Locked Use si la fonctionnalité est déjà activée. Sous Windows, Computer Use nécessite un bureau actif et déverrouillé. Voir Restrictions de Locked Use.

Sessions de navigateur et connexions existantes

Work Local n’accède pas automatiquement à tous les navigateurs ni à tous les comptes de l’entreprise. L’accès dépend du navigateur utilisé, du compte connecté et des approbations requises pour cette expérience de navigation.

Les politiques Browser Use prises en charge peuvent restreindre l’accès aux sites, l’envoi et le téléchargement de fichiers, l’accès à l’historique du navigateur et l’accès complet à Chrome DevTools Protocol (CDP) pour le débogage du navigateur. Les administrateurs peuvent également restreindre l’examen automatique des demandes d’approbation, les approbations enregistrées et la durée de validité des approbations d’accès aux sites. Une approbation de l’utilisateur ne peut pas prévaloir sur un refus de l’administrateur. Voir Contrôles administrés du navigateur.

Un navigateur hébergé dans le cloud est distinct des navigateurs locaux de l’utilisateur et n’hérite pas automatiquement de leurs sessions déjà ouvertes. La connexion à des sites web depuis le navigateur cloud n’est pas disponible dans les espaces de travail Enterprise ou Edu.

Applications, plugins et comptes connectés

Une application connectée peut donner accès à des informations ou à des actions dans un autre système. Un plugin peut utiliser une application comme outil sous-jacent. Le fait de rendre un plugin disponible n’active pas automatiquement l’application requise, n’autorise pas un compte et ne permet pas toutes les actions.

Les paramètres par défaut des plugins et des applications dépendent de l’offre et du fait que l’espace de travail soit nouveau ou existant. Les nouveaux espaces de travail Enterprise et Edu disposent dès leur création d’un ensemble sélectionné d’applications activées ; ces paramètres par défaut ne modifient pas ceux des espaces de travail existants et ne s’appliquent pas aux espaces de travail Healthcare. En général, les nouveaux plugins et applications sont désactivés par défaut dans Enterprise et Edu. Les applications sont activées par défaut dans Business. Les administrateurs peuvent modifier leur disponibilité. Voir les paramètres par défaut actuels des plugins et des applications et la présentation de ChatGPT Work.

Avant qu’une tâche utilise un système connecté, vérifiez que l’espace de travail autorise l’application et tout plugin requis, que la connexion est autorisée et que le compte connecté peut accéder aux informations ou à l’action demandées. Les paramètres de lecture seule, les actions autorisées et les exigences de confirmation varient selon l’intégration.

Les plugins qui fournissent des fonctionnalités de navigateur ou de Computer Use nécessitent un examen spécifique de leur disponibilité et de leur installation. Rendre un plugin disponible ne permet pas de passer outre les politiques administrées du navigateur ou des applications natives, les autorisations du système d’exploitation ou les approbations requises. Les plugins réservés à l’application de bureau et les outils fournis localement peuvent suivre des procédures d’installation différentes. Voir Contrôles des plugins.

Connexions personnelles et partagées

Une connexion personnelle utilise les autorisations de l’utilisateur connecté dans le système source. Une connexion partagée ou appartenant à un agent utilise les autorisations du compte connecté, qui peuvent être plus étendues que les propres accès de l’utilisateur.

Limitez les comptes partagés aux données et actions nécessaires, restreignez les personnes autorisées à les utiliser et appliquez les contrôles d’action ou de confirmation pris en charge. Les enregistrements du système connecté restent soumis aux autorisations et aux politiques de conservation de ce système.

Accès administrateur et politiques des appareils gérés

Pour l’accès à l’ordinateur local via Work Cloud, examinez à la fois l’autorisation de synchronisation de l’espace de travail et les exigences d’Agent Security pour l’exécution locale.

Pour l’exécution locale, les exigences MDM et les anciennes exigences relatives aux appareils gérés sont prioritaires sur Agent Security. Le fichier d’exigences système de l’appareil a une priorité inférieure à Agent Security. Au sein d’une politique donnée, les dérogations d’environnement propres à un système d’exploitation sont prioritaires sur celles qui s’appliquent à tous les systèmes d’exploitation, puis viennent les paramètres Global. Une politique de priorité supérieure l’emporte même si une politique de priorité inférieure est plus spécifique. Certaines exigences suivent des règles de fusion propres à chaque champ.

Utilisez l’API de gestion des politiques 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, et vérifiez que les affectations et l’ordre des politiques n’ont pas changé.

Pour Work avec accès local et dots, la politique Global prise en charge s’applique via l’orchestrateur cloud partagé lorsque la politique gérée est activée. Les exigences locales applicables de requirements.toml régissent l’exécution sur un ordinateur connecté. Les conteneurs cloud Work et les ordinateurs cloud dots utilisent leur propre configuration et leurs propres exigences d’exécution, plutôt que l’ensemble de paramètres d’environnement gérés utilisé par les autres types d’exécuteurs. Les restrictions d’exécution locale ne s’appliquent pas automatiquement à ces ordinateurs cloud. Examinez les autorisations des fonctionnalités cloud et testez séparément l’exécution locale et l’exécution cloud.

Avant d’activer la synchronisation, examinez ces exigences :

• Politiques distribuées uniquement via MDM. MDM distribue les politiques aux appareils. Créez une configuration de référence Agent Security pour les exigences d’exécution locale prises en charge avant d’activer la synchronisation.

• Hooks d’entreprise. Lorsque cette fonctionnalité est activée pour votre espace de travail, l’accès à l’ordinateur local via Work Cloud prend en charge les hooks MCP définis par l’administrateur, qui s’exécutent sur le coordinateur cloud (orchestrateur) pour les événements de cycle de vie et d’outils pris en charge. Les hooks de commande et ceux issus de la configuration locale ou de plugins 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 exécutés uniquement en local. Les administrateurs peuvent toujours configurer les hooks gérés pris en charge dans Agent Security pour ces workflows.

• Audit. Avant de vous appuyer sur ces hooks, testez la connexion de rappel, confirmez les événements qu’elle reçoit et vérifiez l’incidence des échecs sur la tâche. Les hooks MCP ne fournissent pas de piste d’audit complète via la Compliance API.

Examinez les contrôles de Work disponibles dans Paramètres de l’espace de travail > Autorisations et rôles. L’affichage de Work local et hébergé sous forme d’autorisations distinctes dépend de la configuration de l’espace de travail et du déploiement. Pour en savoir plus, consultez la FAQ destinée aux administrateurs de Work.

Activez uniquement les environnements d’exécution approuvés pour chaque utilisateur ou groupe, puis vérifiez les accès effectifs après les modifications.

Les autorisations de l’espace de travail déterminent qui peut utiliser Work. Les administrateurs peuvent également restreindre les fonctionnalités de bureau prises en charge au moyen d’exigences imposées définies dans requirements.toml. Selon le déploiement, ces exigences peuvent être distribuées par l’intermédiaire d’une configuration gérée par l’espace de travail, d’un fichier de configuration au niveau du système ou d’outils de gestion des appareils mobiles macOS pris en charge.

Les utilisateurs individuels ne peuvent pas contourner les exigences imposées. À l’inverse, les valeurs par défaut gérées définissent des paramètres initiaux que les utilisateurs peuvent être autorisés à modifier. Ni les unes ni les autres ne remplacent les rôles de l’espace de travail ou les autorisations du système d’exploitation.

Pour les clients locaux qui utilisent le mécanisme de configuration locale existant, les exigences gérées sont chargées lors du chargement de la configuration. Une actualisation en arrière-plan peut préparer les exigences cloud pour un chargement ultérieur, et les modifications MDM de macOS sont lues au prochain lancement du client. Après une modification de la politique locale, redémarrez le client local concerné et vérifiez son fonctionnement.

La désactivation de l’accès à l’ordinateur local avec Work Cloud interrompt les tours en cours. Les utilisateurs peuvent lancer un nouveau tour dans une conversation cloud existante. Ce tour utilise automatiquement Work Cloud sans accès aux fichiers locaux.

Ce comportement de chargement local ne permet pas de déterminer quand une modification de politique cloud prend effet dans une tâche en cours utilisant l’accès à l’ordinateur local avec Work Cloud. Vérifiez les contrôles effectivement appliqués à la tâche avant de vous appuyer sur la mise à jour.

Il s’agit d’exemples de restrictions, et non d’une liste de paramètres activés par défaut. L’absence d’exigence pour une fonctionnalité laisse en vigueur les paramètres habituels du client, de la plateforme, du déploiement et de l’utilisateur. Les indicateurs de fonctionnalité de Browser Use, le volet du navigateur intégré et Computer Use natif sont des contrôles distincts. Vérifiez chaque mode d’accès au navigateur séparément.

Les paramètres et les modes de distribution disponibles dépendent du client, du système d’exploitation, de l’espace de travail et de la configuration du déploiement. Vérifiez les restrictions sur un appareil géré représentatif. Pour connaître les paramètres de politique pris en charge, consulter des exemples de configuration et obtenir les instructions de configuration MDM, consultez Configuration gérée.

Réseau local et ressources privées

Work Local peut accéder aux informations de l’entreprise par l’intermédiaire d’un navigateur, d’une application native, d’une application connectée ou d’un autre outil pris en charge. Les contrôles réseau s’appliquent différemment à chaque mode d’accès, et l’accès à un VPN d’entreprise n’autorise pas à lui seul une tâche à utiliser une ressource interne.

Les exigences réseau gérées et les politiques d’origine de Browser Use font l’objet de vérifications distinctes. Vérifiez les deux sur les versions de l’application et les systèmes d’exploitation de votre déploiement avant de vous appuyer sur une restriction réseau pour limiter Browser Use. Les vérifications des politiques du navigateur ne signifient pas que le trafic du navigateur passe par le proxy réseau des commandes, et les politiques de Browser Use ne régissent pas le trafic des applications natives.

Les exigences réseau administrées sous [experimental_network] sont expérimentales et peuvent évoluer. La prise en charge de Windows est limitée ; testez le client et l’environnement exacts avant de les appliquer aux utilisateurs Windows. Les règles de domaine seules n’activent pas le proxy administré ; experimental_network.enabled = true est requis et ne permet pas de passer outre une sandbox qui maintient l’accès réseau désactivé.

Examinez la connexion, le compte connecté, la destination et l’action nécessaires au workflow. Pour en savoir plus sur la configuration et les limites des plateformes, voir Exigences d’accès réseau.

Traitement et conservation des données

Avec l’accès à l’ordinateur local avec Work Cloud, la coordination cloud fait partie du flux de travail, même lorsqu’une étape s’exécute sur l’ordinateur. Examinez les données de conversation et le contexte de la tâche séparément des fichiers locaux utilisés par un outil. Ne déduisez pas d’une exécution locale que le stockage se limite à l’appareil ou que tous les fichiers d’un dossier sont téléversés.

L’accès à l’ordinateur local avec Work Cloud ne garantit pas une absence stricte de conservation des données. La résidence des données et la résidence de l’inférence couvrent uniquement les contenus admissibles ainsi que les charges de travail, régions et configurations prises en charge. Enterprise Key Management (EKM) couvre les contenus stockés pris en charge dans les espaces de travail admissibles. Work n’est pas pris en charge avec la résidence de l’inférence aux Émirats arabes unis. Confirmez la couverture de l’espace de travail en matière de stockage, de conservation et d’audit avant le déploiement. Si votre organisation exige ZDR, n’activez pas cette fonctionnalité. Si enforce_residency est activé dans une politique cloud, Autoriser l’accès à l’ordinateur local est désactivé pour Work comme pour dots. Cette protection ne configure pas la résidence de l’espace de travail et ne désactive pas, à elle seule, Work Cloud ou dots.

Appliquez les contrôles de votre organisation relatifs aux terminaux, à l’accès aux fichiers, aux proxys et à la prévention des pertes de données à l’appareil et au workflow concernés. Vérifiez si ces contrôles peuvent empêcher des informations sensibles d’entrer dans la tâche avant leur traitement. Les journaux d’audit et les exportations de conformité facilitent la surveillance et les enquêtes, mais ne bloquent pas le traitement à eux seuls.

Le stockage et la conservation dépendent de la catégorie d’informations et de l’emplacement où elles sont enregistrées.

Pour les espaces de travail Business, Enterprise et Edu pris en charge, les données professionnelles traitées par les services OpenAI concernés sont chiffrées en transit et au repos et, par défaut, ne sont pas utilisées pour entraîner ou améliorer les modèles OpenAI. Ces protections ne signifient pas qu’OpenAI régit tous les fichiers de l’appareil, toutes les applications tierces, tous les profils de navigateur ou tous les enregistrements du système source.

N’appliquez pas une période de conservation propre aux conversations hébergées, aux téléversements temporaires ou aux journaux de conformité à des enregistrements locaux sans vérifier qu’elle s’applique à la catégorie de données concernée.

Visibilité pour l’audit et la conformité

L’activation de l’accès à l’ordinateur local avec Work Cloud modifie ce que reçoit votre collecteur OpenTelemetry (OTel) existant. Votre exécuteur local peut toujours exporter les événements d’exécution pris en charge. Les événements d’orchestration cloud ne parviennent pas à votre collecteur OpenTelemetry existant.

Utilisez la Compliance API pour les enregistrements cloud pris en charge. Modifier le point de terminaison du collecteur ne rétablit pas les événements d’orchestration cloud. Les enregistrements de la Compliance API ne remplacent pas tous les événements de l’ancien flux OpenTelemetry. Consultez Examiner la couverture d’OpenTelemetry et de l’audit.

Les rapports disponibles dépendent du forfait de l’espace de travail, de l’expérience produit, de l’événement, de l’application connectée et de la configuration déployée. Vérifiez la couverture de Work Local avant de vous appuyer sur une exportation de l’espace de travail dans le cadre d’une réponse à un incident ou d’un contrôle réglementaire.

Dans les versions prises en charge, Browser Use peut émettre des événements OpenTelemetry lors des vérifications de fonctionnalités, notamment pour l’accès aux sites, l’envoi et le téléchargement de fichiers. Ces événements enregistrent la décision et sa source, ainsi que les détails de la politique lorsqu’ils sont disponibles. La source de la décision peut être inconnue. Lorsque l’exportation est configurée, ces événements sont envoyés au point de terminaison OpenTelemetry du client avec les autres données de télémétrie de l’environnement d’exécution local.

Configurez l’export OpenTelemetry séparément des enregistrements de la Compliance API. Ces événements ne constituent pas un historique complet de toutes les actions effectuées dans le navigateur ou les applications natives. Consultez Configuration d’OpenTelemetry.

Déterminez si les systèmes concernés enregistrent l’identité associée à la tâche, les prompts et réponses pris en charge, les appels aux applications connectées, les approbations dans le navigateur, les actions dans les applications, l’activité sur les fichiers locaux ou les événements des terminaux. Les enregistrements du système source et de l’appareil peuvent offrir une visibilité différente de celle des enregistrements de l’espace de travail ChatGPT.

OpenAI ne stocke pas d’enregistrement complet distinct des actions Chrome effectuées par l’intermédiaire de l’extension. Ne supposez pas que chaque opération sur un fichier local, capture d’écran, action dans le navigateur, approbation ou mise à jour externe apparaît dans la Compliance API.

Commencer par une tâche approuvée

Vérifiez le fonctionnement de Work en local sur les appareils gérés utilisés par vos équipes. Exécutez une tâche approuvée, par exemple la comparaison de classeurs financiers sélectionnés. Confirmez l’accès de chaque utilisateur à Work et fournissez uniquement les fichiers, applications, sessions de navigateur ou comptes connectés nécessaires à la tâche.

Vérifiez que les actions approuvées fonctionnent, que les actions restreintes sont bloquées et que les enregistrements disponibles répondent à vos besoins de surveillance. Demandez à l’utilisateur d’examiner les résultats et de confirmer que toute modification apportée aux fichiers ou aux systèmes connectés correspond à la demande.