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.

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 tâches locales s’exécutent par l’intermédiaire de l’application de bureau ChatGPT. Le fait d’ouvrir une tâche hébergée dans le cloud dans la même application ne la rend pas locale.
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

Work Local accède aux ressources approuvées par l’intermédiaire de l’application de bureau installée sur l’ordinateur de l’utilisateur. Work Cloud s’exécute sur une infrastructure gérée par OpenAI, même lorsqu’il est ouvert depuis la même application de bureau.

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.

Mode d’accès au navigateur	Session et périmètre de sécurité
Navigateur intégré à l’application de bureau	Utilise un profil distinct de celui du navigateur habituel de l’utilisateur. Les utilisateurs peuvent se connecter dans ce profil. Sur les clients pris en charge, les politiques administrées de Browser Use restreignent l’accès de l’agent aux sites et les fonctionnalités du navigateur disponibles. Le navigateur intégré ne peut pas automatiser l’envoi de fichiers.
Extension Chrome	Peut interagir avec les onglets existants et les comptes connectés lorsque l’extension et l’accès aux sites web sont approuvés. Sur les clients pris en charge, les mêmes politiques administrées de Browser Use s’appliquent aux actions de l’agent effectuées par l’intermédiaire de l’extension.
Navigateur piloté par Computer Use	Pilote le navigateur en tant qu’application native approuvée et peut utiliser les comptes déjà connectés. Les politiques de Browser Use relatives aux sites et aux fonctionnalités ne s’appliquent pas à ce mode d’accès. Les politiques relatives aux applications natives, les autorisations du système d’exploitation, les approbations d’applications et les autorisations du compte connecté restent applicables.

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

Examinez les contrôles Work disponibles dans Workspace settings > Permissions & roles. L’affichage distinct de Work local et hébergé dans les autorisations dépend de la configuration et du déploiement de l’espace de travail. Pour plus d’informations, consultez la FAQ de Work destinée aux administrateurs.

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.

Les clients locaux pris en charge chargent les exigences administrées lors du chargement de la configuration. Une actualisation en arrière-plan peut rendre de nouvelles exigences administrées dans le cloud disponibles pour un chargement ultérieur de la configuration ; elle ne prouve pas à elle seule qu’une tâche en cours utilise la nouvelle politique. Les modifications des exigences MDM de macOS sont lues au prochain lancement du client. Après avoir modifié les exigences administrées, redémarrez le client local concerné et vérifiez ses paramètres effectifs avant de vous fier à la restriction. Les modifications des autorisations de l’espace de travail peuvent suivre un autre processus d’activation. Voir Comment les clients locaux appliquent les exigences administrées dans le cloud.

Paramètre administré	Objectif de sécurité
`features.computer_use = false`	Désactiver les fonctionnalités natives de Computer Use.
`allow_appshots = false`	Empêcher la capture Appshot prise en charge.
`features.in_app_browser = false`	Désactiver le navigateur intégré à l’application de bureau.
`features.browser_use = false`	Désactiver les fonctionnalités Browser Use prises en charge ; Browser Use externe dispose d’un indicateur distinct.
`features.browser_use_external = false`	Désactiver Browser Use piloté par l’agent via les extensions de navigateur prises en charge.
`features.apps = false` ou `features.plugins = false`	Restreindre les applications connectées ou les plugins pris en charge.
`computer_use.allow_locked_computer_use = false`	Empêcher les utilisateurs d’activer Locked Use sur les Mac administrés ; ne désactive pas Locked Use si la fonctionnalité est déjà activée.

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é Browser Use, le volet du navigateur intégré et Computer Use natif sont des contrôles distincts ; validez chaque mode d’accès au navigateur séparément.

Les paramètres et méthodes de distribution disponibles dépendent du client, du système d’exploitation, de l’espace de travail et de la configuration du déploiement. Validez 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, reportez-vous à la 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 administrées et les politiques d’origine de Browser Use constituent des contrôles distincts. Validez les deux sur les versions d’application et les systèmes d’exploitation de votre déploiement avant de vous fier à 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 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

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.

Catégorie d’informations	Points à examiner
Enregistrements de conversations locales	La façon dont l’expérience de bureau stocke, supprime, sauvegarde ou partage les enregistrements locaux. Ne supposez pas que les paramètres de conservation des conversations hébergées s’appliquent à tous les artefacts locaux.
Fichiers locaux et résultats générés	Stockage sur l’appareil, politique des terminaux, téléversements autorisés par l’utilisateur, partage externe et éventuelles copies enregistrées séparément.
Prompts, extraits de fichiers et contexte des applications	Contenu fourni à un modèle ou à un service, conditions applicables de l’espace de travail et flux de données réel du workflow.
Voix et Appshots	Entrée du microphone, captures d’écran de la fenêtre au premier plan, texte accessible des applications, stockage de la session locale et tout contenu envoyé comme contexte de la tâche.
Données de navigateur	Profil de navigateur concerné, connexions existantes, historique de navigation, téléchargements, approbations de sites web et tout contenu de tâche stocké séparément.
Enregistrements des systèmes connectés	Autorisations et conservation du système source, identité du compte connecté et toute information enregistrée séparément dans la conversation ou à une autre destination.
Enregistrements de conformité et d’activité	Les événements Work Local disponibles pour l’espace de travail, l’intégration prise en charge et la politique de conservation du système destinataire.

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é

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.

L’exportation OpenTelemetry est distincte des enregistrements de la Compliance API et doit être configurée séparément. Ces événements ne constituent pas un journal exhaustif de toutes les actions effectuées dans le navigateur ou les applications natives. Voir 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

Commencez avec un petit groupe utilisant des appareils gérés et choisissez une tâche approuvée, par exemple la comparaison de classeurs financiers sélectionnés. Vérifiez l’accès à Work de chaque utilisateur 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 à un utilisateur d’examiner les résultats et toutes les modifications externes avant d’étendre l’accès.

Recherches récentes

Recherches suggérées

Navigation de la documentation