Accès à l’ordinateur local pour Work Cloud et les dots

Work et les dots peuvent utiliser les fichiers et outils autorisés sur un ordinateur connecté pendant que le cloud d’OpenAI coordonne la tâche. Activez l’accès à l’ordinateur local séparément pour chaque fonctionnalité.

Consultez d’abord les consignes communes ci-dessous sur les politiques, la compatibilité et l’audit. Suivez ensuite les instructions de configuration et d’utilisation de la fonctionnalité que vous souhaitez activer, Work ou les dots.

Ce guide aide les propriétaires d’espaces de travail Enterprise à vérifier les exigences des politiques et à activer l’accès à l’ordinateur local pour Work et les dots. La disponibilité dépend de votre espace de travail et de l’avancement du déploiement.

Consultez Sécurité des agents pour connaître les paramètres de référence de Global, les dérogations par environnement et les listes de champs de l’orchestrateur et de l’exécuteur.

Avantages de l’accès à l’ordinateur local

L’accès à l’ordinateur local permet aux équipes de poursuivre leur travail d’un appareil à l’autre avec ces fonctionnalités. Dans Sécurité des agents, les administrateurs peuvent gérer de manière centralisée les exigences prises en charge pour l’exécution sur un ordinateur local. Ces exigences ne s’appliquent pas lorsque Work utilise un conteneur cloud ou qu’un dot utilise un ordinateur cloud. L’exécution dans le cloud dispose de contrôles distincts pour l’accès au navigateur, l’accès au réseau et l’utilisation de l’ordinateur.

Work

Les membres peuvent poursuivre une tâche Work d’un appareil à l’autre et utiliser les ressources locales approuvées via un ordinateur connecté. Les administrateurs peuvent gérer les exigences d’exécution locale dans Sécurité des agents et examiner séparément l’exécution dans le cloud.

dots

• Effectuez vos tâches de développement en local. Analysez des bugs, implémentez des modifications et lancez des builds à l’aide des dépôts locaux, des outils de développement et des skills autorisés.

• Coordonnez les tâches de programmation. Créez des fils de discussion locaux dans Work ou Codex et pilotez les fils Codex locaux existants.

• Utilisez les applications de bureau et le navigateur local pour les tâches prises en charge, notamment celles qui nécessitent une authentification locale lorsque le navigateur cloud ne peut pas les mener à bien.

Avant et après l’activation de l’accès à l’ordinateur local avec Work Cloud

Une tâche comporte deux volets : la coordination et l’exécution. La coordination détermine les étapes à suivre et fait avancer la conversation. L’exécution correspond au travail qu’effectue un outil, par exemple lorsqu’il lance une commande shell. Cette fonctionnalité transfère la coordination vers le cloud d’OpenAI. Les outils et fichiers ne quittent pas tous l’ordinateur pour autant.

Configuration de l’accès à l’ordinateur local

Vérifiez votre politique dans Sécurité des agents

Où consulter les paramètres

Ouvrez Console d’administration → Sécurité des agents. Cette rubrique remplace Politiques et configuration. Son déploiement est indépendant de celui de l’accès à l’ordinateur local pour Work et les dots.

• Paramètres des politiques : vérifiez les paramètres de référence de Global et les éventuelles dérogations définies dans Local. Conservez dans Global les contrôles de l’orchestrateur, notamment les approbations et la recherche web. Les environnements ne peuvent pas y déroger. Utilisez les contrôles dédiés de l’interface lorsqu’ils sont disponibles, notamment Politiques d’approbation autorisées et Modes de recherche web autorisés, et utilisez TOML pour les autres champs pris en charge. Consultez les contrôles de l’orchestrateur et de l’exécuteur pour savoir où s’applique chaque paramètre.

• Exigences et valeurs par défaut : les exigences fixent des limites auxquelles les utilisateurs ne peuvent pas déroger. Les valeurs par défaut fournissent des valeurs initiales dans ces limites et ne peuvent pas prévaloir sur une exigence.

• Accès aux fonctionnalités : ouvrez Console d’administration → Autorisations. L’accès à l’ordinateur local s’active séparément pour Work et pour les dots.

Paramètres conservés lors de la migration

Lors de la migration des anciennes politiques cloud éligibles, leurs paramètres sont repris dans Global. Les affectations et l’ordre des politiques sont conservés. Examinez les politiques migrées dans Sécurité des agents, puis utilisez le tableau ci-dessous pour vérifier votre configuration actuelle. Si vous automatisez les mises à jour des politiques, consultez également la dernière ligne. Pour plus de détails sur la migration, consultez Sécurité des agents.

Ordre de priorité des politiques

Ces règles s’appliquent à différents niveaux. Les flèches ci-dessous indiquent l’ordre de priorité décroissant.

• Entre plusieurs politiques : la politique de priorité supérieure l’emporte, même si la politique de priorité inférieure est plus spécifique.

• Au sein d’une politique : pour les paramètres d’exécution pris en charge, l’ordre est le suivant : dérogation de l’environnement → Global. En l’absence de dérogation, l’environnement hérite du paramètre applicable de Global.

• Exigences locales : exigences MDM de macOS → anciens champs de managed_config.toml interprétés comme des exigences → exigences de Sécurité des agents gérées dans le cloud → fichier système requirements.toml. Le niveau MDM s’applique sur macOS. Les valeurs par défaut suivent des règles de configuration distinctes.

Certaines exigences suivent des règles de fusion propres à chaque champ. Consultez la configuration gérée et la référence de configuration pour connaître la portée des politiques, les champs pris en charge et les environnements d’exécution concernés.

Application des politiques à Work et aux dots

Avec l’accès local, Work et les dots appliquent les mêmes règles aux niveaux suivants :

• Coordination des tâches : lorsque la gestion des politiques est activée, le service cloud qui coordonne la tâche applique les exigences prises en charge définies dans Global dans Sécurité des agents, notamment les exigences d’approbation et les modes de recherche web autorisés.

• Exécution locale : lorsqu’un outil s’exécute sur un ordinateur connecté, il applique les exigences d’exécution locale prises en charge de Sécurité des agents et les politiques applicables à l’appareil, y compris celles distribuées par MDM lorsque ce mode de distribution est pris en charge. Elles peuvent notamment restreindre l’accès au système de fichiers et au réseau. Seuls les champs pris en charge par l’exécuteur local s’appliquent. Configurer un champ dans le MDM ou dans le fichier requirements.toml local ne garantit pas son application en local.

• Exécution dans le cloud : les conteneurs cloud de Work et les ordinateurs cloud des dots utilisent des contrôles d’exécution distincts. Les restrictions locales relatives au système de fichiers et au réseau ne s’appliquent pas automatiquement à ces environnements cloud.

Vérifiez la compatibilité et les exigences relatives aux données

Avant d’activer l’une ou l’autre fonctionnalité, vérifiez les critères d’éligibilité, les données couvertes et les contrôles sur lesquels s’appuie votre organisation. Même si Work et les dots partagent une infrastructure, ils ne prennent pas en charge exactement les mêmes fonctionnalités.

Vérifiez les critères d’éligibilité pour Work et les dots

• Work : la résidence s’applique uniquement aux contenus éligibles et aux charges de travail, régions et configurations prises en charge. EKM couvre les contenus stockés pris en charge dans les espaces de travail éligibles. Vérifiez la couverture de votre workflow, sans présumer qu’elle englobe chaque étape utilisant l’accès local ou chaque intégration connectée. Work ne prend pas en charge la résidence de l’inférence aux Émirats arabes unis. Consultez Résidence des données et résidence de l’inférence et Sécurité de Work dans le cloud.

• Résidence pour les dots : pendant la bêta Enterprise, les dots ne prennent en charge ni la résidence des données ni celle de l’inférence. Les espaces de travail éligibles peuvent activer les dots après avoir confirmé qu’ils ont pris connaissance de ces limites. L’activation des dots ne rend pas leurs données ni leur traitement conformes aux exigences de résidence.

• Exclusions pour les dots : les dots ne sont pas disponibles dans les espaces de travail FedRAMP, ceux qui utilisent EKM ou ceux dont la résidence de l’inférence est définie sur AE (Émirats arabes unis). Les espaces de travail HIPAA peuvent participer s’ils remplissent les autres critères d’éligibilité.

Vérifiez le traitement des données et la protection qui encadre l’accès local

• Traitement dans le cloud : le cloud continue de coordonner les tâches de Work avec accès local et celles des dots. Les conversations, les résultats des outils et les autres éléments de contexte de la tâche ne restent pas exclusivement sur l’ordinateur connecté.

• Protection liée à la résidence : si une politique cloud active enforce_residency, l’option Autoriser l’accès à l’ordinateur local est indisponible pour Work comme pour les dots. Cette protection ne définit pas la résidence de l’espace de travail et ne désactive pas à elle seule Work Cloud ou les dots. Les espaces de travail éligibles peuvent toujours activer les dots après avoir confirmé qu’ils ont pris connaissance des limites de la bêta en matière de résidence. L’accès local reste bloqué.

• Conservation des données et accès aux données : aucune des deux fonctionnalités ne garantit une politique stricte de non-conservation des données. La politique de non-conservation des données de l’API est un contrôle propre à l’API. Les engagements de « non-consultation humaine » et les contrôles de surveillance des abus sont également distincts de la non-conservation des données. Si un workflow exige qu’aucune donnée ne soit conservée, ne l’activez pas pour ces fonctionnalités.

Avant le déploiement, vérifiez les règles de conservation et de suppression ainsi que la couverture d’audit pour les données et les outils effectivement utilisés. Dans Work, les conversations, l’état d’exécution hébergé, les fichiers et les données des applications connectées peuvent suivre des cycles de vie différents. Supprimer une conversation n’efface pas toutes les copies associées.

Vérifiez la compatibilité des hooks et du réseau

• Compatibilité des hooks : avant d’activer l’accès local, consultez les éventuels avertissements de compatibilité dans le paramètre de l’espace de travail et dans Sécurité des agents. Comparez les hooks nécessaires à votre workflow aux hooks pris en charge avec l’orchestration cloud. Si votre workflow dépend d’un hook qui exécute une commande locale ou d’un hook de plugin, continuez de l’exécuter entièrement en local.

• Gestion des échecs et couverture d’audit : testez la connexion utilisée pour les rappels, les événements requis et le comportement de l’outil lorsqu’un rappel échoue ou dépasse le délai imparti. Si un hook PreToolUse échoue, l’outil peut quand même s’exécuter. Les hooks ne couvrent pas tous les chemins d’exécution internes des sous-agents. Examinez séparément les enregistrements d’audit disponibles.

• Contrôles du réseau et des applications : vérifiez le champ, le mode de distribution et l’environnement d’exécution dans la référence de configuration. Les contrôles appliqués par l’application ou l’appareil peuvent rester en vigueur même si l’orchestrateur cloud n’utilise pas un paramètre. L’environnement d’exécution cloud ne prend en charge ni les ports d’écoute HTTP/SOCKS gérés ni les proxys à l’écoute sur une adresse autre qu’une adresse de bouclage. La prise en charge des règles de socket dépend du chemin d’exécution. Consultez Priorité des politiques réseau et limites de l’environnement d’exécution, puis testez les actions autorisées et bloquées ainsi que les connexions requises.

Pour toute question sur les fichiers locaux, l’exécution dans le cloud ou l’ordre de priorité des politiques, consultez la FAQ Work pour les administrateurs, la sécurité de Work en local et la sécurité de Work dans le cloud.

Activez l’accès à l’ordinateur local

Accordez l’accès à l’ordinateur local séparément pour Work et pour les dots. Utilisez les paramètres par défaut de l’espace de travail et les rôles personnalisés pris en charge pour accorder l’accès aux utilisateurs ou aux groupes concernés.

Avant le déploiement, vérifiez les politiques et les exigences de compatibilité ci-dessus. Il est recommandé d’examiner ou de créer des politiques dans Sécurité des agents, mais la procédure de confirmation n’exige pas la création de politiques avant l’activation de l’accès. La migration des politiques n’accorde pas l’accès à l’ordinateur local.

Work

1. En tant que propriétaire de l’espace de travail, ouvrez Console d’administration > Autorisations.

2. Activez Work Cloud pour les utilisateurs concernés. L’option Utiliser Codex en local dans l’application de bureau ChatGPT n’est pas requise pour cette fonctionnalité.

3. Sous Work Cloud, activez Autoriser l’accès à l’ordinateur local. Lisez la boîte de dialogue de confirmation, puis ouvrez Sécurité des agents pour examiner ou définir des politiques, ou confirmez pour activer l’accès.

4. Demandez aux utilisateurs de mettre à jour l’application de bureau ChatGPT vers la version 26.929 ou ultérieure. Cette mise à jour est nécessaire pour que l’accès à l’ordinateur local avec Work Cloud prenne effet.

5. Demandez à un membre disposant des autorisations prévues de sélectionner Cloud dans la zone de saisie de l’application de bureau et de lancer une nouvelle tâche. Poursuivez la tâche depuis un autre appareil pris en charge et vérifiez qu’elle peut accéder à un fichier ou à un outil local approuvé pendant que l’ordinateur est connecté.

dots

1. En tant que propriétaire de l’espace de travail, ouvrez Console d’administration > Autorisations et activez les dots pour les utilisateurs concernés, sous réserve des critères d’éligibilité ci-dessus.

2. Sous Utiliser les dots, activez Autoriser l’accès à l’ordinateur local. Lisez la boîte de dialogue de confirmation, puis ouvrez Sécurité des agents pour examiner ou définir des politiques, ou confirmez pour activer l’accès.

3. Demandez aux utilisateurs de mettre à jour l’application de bureau ChatGPT vers la version 26.929 ou ultérieure. Cette mise à jour est nécessaire pour que l’accès à l’ordinateur local prenne effet.

4. Demandez aux utilisateurs de connecter leur ordinateur en suivant les instructions destinées aux utilisateurs de dots ci-dessous.

5. Demandez à un membre disposant des autorisations prévues et d’un ordinateur connecté de tester une tâche locale avec son dot.

Vérifiez la couverture d’OpenTelemetry et de l’audit

Lorsque vous examinez la couverture d’OpenTelemetry (OTel) pour Work avec accès local et pour les dots, distinguez la télémétrie d’exécution locale des enregistrements d’audit du cloud. Votre exécuteur local peut toujours exporter les événements d’exécution pris en charge. Votre collecteur OpenTelemetry existant ne reçoit pas les événements d’orchestration cloud.

Utilisez l’API de conformité pour accéder aux enregistrements cloud pris en charge. Modifier le point de terminaison du collecteur ne rétablit pas la réception des événements d’orchestration cloud. Les enregistrements de l’API de conformité ne remplacent pas tous les événements du flux OpenTelemetry antérieur.

Pour les dots, utilisez l’API d’analyse pour les données d’utilisation et l’API de conformité pour les enregistrements d’audit pris en charge. Vérifiez à la fois la disponibilité des enregistrements nécessaires à votre workflow et la réception des événements par le collecteur local. Les hooks MCP ne remplacent pas la couverture d’audit.

Pour connaître la couverture d’audit dans le cloud, consultez Sécurité de Work dans le cloud.

Utilisation de l’accès local

Pour Work comme pour les dots, les étapes locales nécessitent que l’ordinateur concerné soit en ligne et connecté. L’application de bureau ChatGPT doit y être ouverte, avec une session active dans le compte et l’espace de travail appropriés.

Work

Les membres doivent se connecter avec ChatGPT à l’espace de travail souhaité. Les clés API et les tokens d’accès Codex ne permettent pas d’activer cette fonctionnalité. Partagez le guide Poursuivre une tâche Work d’un appareil à l’autre pour indiquer aux membres comment lancer une tâche éligible et la poursuivre lorsque l’ordinateur est hors ligne. Avant de désactiver la fonctionnalité, consultez les instructions de retour à la configuration précédente.

dots

• Connectez un ordinateur. Ouvrez la fiche du dot dans l’application de bureau ChatGPT, puis choisissez Ordinateurs. Repérez Votre ordinateur (ou le nom de l’ordinateur), sélectionnez Autoriser, puis confirmez avec Autoriser l’accès. Le dot peut alors utiliser cet ordinateur pour les tâches locales prises en charge.

• Ordinateur hors ligne. L’autorisation d’accès enregistrée reste valide, mais les tâches qui nécessitent cet ordinateur ne peuvent pas avancer tant qu’il est indisponible. L’état Hors ligne ne signifie pas que l’accès a été révoqué.

• Révoquez l’accès. Choisissez Révoquer l’accès et confirmez pour retirer au dot son autorisation d’accès à cet ordinateur. L’état Déconnecté indique que l’accès a été retiré. Il se distingue de l’état Hors ligne.

• Modification de l’accès par un administrateur. Si un administrateur désactive l’accès à l’ordinateur local pour les dots, une tâche locale déjà autorisée peut encore être en train de se terminer. Ne partez pas du principe que les échanges en cours sont immédiatement interrompus comme dans Work.

• Tâches en cours. Une tâche locale en cours ne migre pas automatiquement vers le cloud. Les changements de connexion peuvent interrompre la tâche ou entraîner le rechargement de l’environnement d’exécution. Le dot peut effectuer les travaux suivants sur son ordinateur cloud. Toutefois, une sous-tâche locale qui a perdu l’accès à l’ordinateur local ne peut pas y reprendre et n’est pas automatiquement transférée vers le cloud.