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

Work et 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é.

Commencez par les recommandations communes ci-dessous concernant les politiques, la compatibilité et l’audit, puis suivez les instructions de configuration et d’utilisation de Work ou de dots pour la fonctionnalité que vous souhaitez activer.

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

Consultez Agent Security pour connaître la configuration de base 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’activation de l’accès à l’ordinateur local dans ces fonctionnalités aide les équipes à poursuivre leur travail sur plusieurs appareils. Les administrateurs peuvent gérer de manière centralisée dans Agent Security les exigences prises en charge pour l’exécution sur un ordinateur local. Ces exigences d’exécution ne s’appliquent pas lorsque Work utilise un conteneur cloud ou qu’un dot utilise un ordinateur cloud. L’exécution dans le cloud utilise des contrôles distincts pour l’accès au navigateur, l’accès au réseau et l’utilisation de l’ordinateur.

Work

• Poursuivez une même conversation Work sur plusieurs appareils. Commencez sur un ordinateur, puis consultez les résultats ou donnez des instructions complémentaires depuis le Web ou l’application mobile. Les tâches qui accèdent à l’ordinateur local avec Work Cloud utilisent une coordination dans le cloud.

• Utilisez les ressources approuvées sur votre ordinateur. Une tâche utilisant cette fonctionnalité peut exploiter les fichiers et outils locaux autorisés via un ordinateur connecté pendant que vous suivez sa progression depuis un autre appareil. Gardez cet ordinateur en ligne et connecté pour les étapes qui en ont besoin.

• Gérez les exigences d’exécution locale de manière centralisée. Définissez dans Agent Security les exigences d’entreprise prises en charge pour l’exécution locale. Examinez séparément les politiques de Work Cloud pour l’exécution dans le cloud.

Dots

• Effectuez des 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, outils de développement et skills autorisés.

• Coordonnez le travail de programmation. Créez des fils de discussion locaux Work ou Codex et contrôlez les fils de discussion locaux Codex existants.

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

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

Une tâche comprend deux parties : la coordination et l’exécution. La coordination détermine les étapes à suivre et fait avancer la conversation. L’exécution correspond au travail effectué par un outil, comme le lancement d’une commande shell. Cette fonctionnalité déplace la coordination vers le cloud d’OpenAI. Elle ne déplace pas tous les outils ni tous les fichiers hors de l’ordinateur.

Configurer l’accès à l’ordinateur local

Examiner votre politique dans Agent Security

Où effectuer cet examen

Ouvrez la console d’administration → Agent Security. Cette section remplace Politiques et configuration. Son déploiement est indépendant de celui de l’accès à l’ordinateur local pour Work et dots.

• Paramètres des politiques : Examinez la configuration de base Global et les éventuelles dérogations Local. Conservez les contrôles de l’orchestrateur, notamment les approbations et la recherche Web, dans Global ; 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 TOML pour les autres champs pris en charge. Consultez les contrôles de l’orchestrateur et de l’exécuteur pour savoir où chaque paramètre s’applique.

• 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 déroger à une exigence.

• Accès aux fonctionnalités : Utilisez Paramètres de l’espace de travail → Autorisations et rôles. L’accès à l’ordinateur local doit être activé séparément pour Work et pour dots.

Ce qui est conservé

Lors de la migration des anciennes politiques cloud admissibles, leurs paramètres sont transférés dans Global, en conservant les affectations et l’ordre des politiques. Examinez les politiques migrées dans Agent Security et utilisez le tableau ci-dessous pour vérifier votre configuration actuelle. Si vous automatisez les mises à jour des politiques, examinez également la dernière ligne. Consultez Agent Security pour obtenir des conseils sur la migration.

Quelle politique est prioritaire

Ces règles s’appliquent à différents niveaux. Chaque flèche ci-dessous va de la priorité la plus élevée à la plus faible.

• Entre les politiques : Une politique de priorité supérieure l’emporte sur une politique de priorité inférieure, même lorsque cette dernière est plus spécifique.

• Au sein d’une politique : Pour les paramètres d’exécution pris en charge, dérogation de l’environnement → Global. Un environnement sans dérogation hérite du paramètre Global applicable.

• Exigences locales : Exigences MDM de macOS → anciens champs managed_config.toml interprétés comme des exigences → exigences gérées dans le cloud par Agent Security → requirements.toml système. La couche MDM s’applique sur macOS ; les valeurs par défaut suivent des règles de configuration distinctes.

Certaines exigences obéissent à des règles de fusion propres à chaque champ. Consultez 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 la portée d’exécution.

Application des politiques à Work et dots

Le comportement commun à Work et dots avec accès local couvre les périmètres suivants :

• Coordination des tâches : Lorsque la politique gérée est activée, le service cloud qui coordonne la tâche applique les exigences prises en charge provenant de Global dans Agent Security, comme 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 d’Agent Security et les politiques applicables à l’appareil, y compris celles distribuées via MDM lorsque cette option est prise en charge. Elles peuvent inclure des restrictions concernant le système de fichiers et le réseau. Seuls les champs pris en charge par l’exécuteur local s’appliquent ; configurer un champ dans MDM ou dans le fichier local requirements.toml 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 concernant le système de fichiers et le réseau ne s’appliquent pas automatiquement à ces environnements cloud.

Pour configurer les fonctionnalités cloud partagées, accédez à Console d’administration → Autorisations et rôles → Fonctionnalités de l’espace de travail → Fonctionnalités de l’ordinateur cloud. Ces autorisations couvrent à la fois Work Cloud et dots. Examinez séparément Utilisation du navigateur cloud et Accès au réseau cloud ; configurer l’une ne configure pas l’autre. Les politiques Global et les dérogations Codex Cloud ne configurent pas ces autorisations.

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

Examinez l’admissibilité, la couverture des données et les contrôles dont dépend votre organisation avant d’activer l’une ou l’autre fonctionnalité. Une infrastructure commune ne signifie pas que Work et dots offrent une prise en charge identique.

Examiner l’admissibilité de Work et dots

• Work : La résidence des données s’applique uniquement aux contenus admissibles et aux charges de travail, régions et configurations pris en charge. EKM couvre les contenus stockés pris en charge dans les espaces de travail admissibles. Confirmez la couverture de votre workflow plutôt que de supposer que chaque étape avec accès local ou chaque intégration connectée est couverte. Work n’est pas pris en charge avec la résidence d’inférence aux Émirats arabes unis. Consultez Résidence des données et résidence d’inférence et Sécurité de Work dans le cloud.

• Résidence des données pour dots : Pendant la bêta Enterprise, dots ne prend en charge ni la résidence des données ni la résidence d’inférence. Les espaces de travail admissibles peuvent activer dots après avoir pris acte de ces limites ; l’activation de dots ne rend pas ses données ni leur traitement conformes aux exigences de résidence.

• Exclusions pour dots : Dots n’est pas disponible pour les espaces de travail FedRAMP, ceux qui utilisent EKM et ceux dont la résidence d’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’admissibilité.

Vérifier le traitement des données et la protection relative à l’accès local

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

• Protection relative à la résidence des données : Si une politique cloud active enforce_residency, Autoriser l’accès à l’ordinateur local est indisponible pour Work comme pour dots. Cette protection ne définit pas la résidence des données de l’espace de travail et ne désactive pas à elle seule Work Cloud ou dots. Les espaces de travail admissibles peuvent toujours activer dots après avoir pris acte des limites de résidence de la bêta ; l’accès local reste bloqué.

• Conservation et accès aux données : Aucune des deux expériences ne garantit une absence stricte de conservation des données. L’option Zero Data Retention de l’API est un contrôle distinct propre à l’API. Les engagements « eyes-off » et les contrôles de surveillance des abus sont également distincts de l’absence de conservation. Si un workflow exige qu’aucune donnée ne soit conservée, ne l’activez pas pour ces expériences.

Examinez la conservation, la suppression et la couverture d’audit des données et outils effectivement utilisés avant le déploiement. Pour Work, les conversations, l’état de l’exécution hébergée, les fichiers et les données des applications connectées peuvent suivre des cycles de vie différents ; la suppression d’une conversation ne supprime pas toutes les copies associées.

Vérifier les hooks et la compatibilité réseau

• Hooks d’entreprise pris en charge : Lorsque la politique gérée et les hooks distants sont activés, Work Cloud avec accès local et dots utilisent des hooks MCP distants gérés par les administrateurs. L’orchestrateur cloud appelle votre service MCP connecté lors des événements de tâche et d’outil pris en charge. Configurez les gestionnaires mcp_tool dans requirements.toml de Global. Work Cloud sans accès local n’utilise pas ces hooks ; ces hooks d’entreprise ne sont pas disponibles pour les comptes personnels.

• Work Cloud et dots avec accès local : 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 propres à un environnement ; et les hooks MCP SessionEnd ne sont pas pris en charge avec l’orchestration dans le cloud, même lorsque la tâche exécute des outils sur votre ordinateur. Si votre workflow dépend de l’un de ces hooks, continuez à utiliser un workflow entièrement local qui le prend en charge jusqu’à ce que vous ayez examiné une autre solution.

• Fils de discussion entièrement locaux dans Work et Codex : Lorsque l’orchestration et l’exécution sont toutes deux locales, les hooks existants pris en charge continuent de fonctionner. Les administrateurs peuvent toujours configurer les hooks gérés pris en charge dans Agent Security pour ce workflow.

• Gestion des échecs et couverture d’audit : 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élai d’attente dépassé ou une réponse mal formée peut faire échouer le hook sans bloquer l’outil. Les hooks ne fournissent pas une piste d’audit Compliance API complète et ne couvrent pas tous les parcours internes des sous-agents.

• 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 toujours s’appliquer lorsque l’orchestrateur cloud n’utilise pas un paramètre. Les ports d’écoute HTTP/SOCKS gérés et les points d’écoute proxy hors boucle locale ne sont pas pris en charge par l’environnement d’exécution cloud ; la prise en charge des règles de sockets dépend du parcours d’exécution. Consultez Priorité des politiques réseau et limites d’exécution, puis testez les actions autorisées et bloquées ainsi que la connectivité requise.

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

Activer l’accès à l’ordinateur local

Accordez l’accès à l’ordinateur local séparément pour Work et 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 groupes visés.

Avant le déploiement, examinez les politiques et les exigences de compatibilité ci-dessus. Il est recommandé d’examiner ou de créer des politiques dans Agent Security, mais le processus 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 Paramètres de l’espace de travail > Autorisations et rôles.

2. Activez Work Cloud pour les utilisateurs visés. Utiliser Codex en local dans l’application de bureau ChatGPT n’est pas un prérequis pour cette fonctionnalité.

3. Sous Work Cloud, activez Autoriser l’accès à l’ordinateur local. Consultez la fenêtre de confirmation, puis ouvrez Agent Security 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 démarrer une nouvelle tâche. Poursuivez la tâche depuis un autre appareil pris en charge et vérifiez l’accès à un fichier ou outil local approuvé pendant que l’ordinateur est connecté.

Dots

1. En tant que propriétaire de l’espace de travail, ouvrez Paramètres de l’espace de travail > Autorisations et rôles et activez dots pour les utilisateurs visés, sous réserve des critères d’admissibilité ci-dessus.

2. Sous Utiliser Dots, activez Autoriser l’accès à l’ordinateur local. Consultez la fenêtre de confirmation, puis ouvrez Agent Security 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 d’ouvrir les détails de leur dot dans l’application de bureau ChatGPT et de choisir Ordinateurs. Repérez Votre ordinateur (ou le nom de l’ordinateur), sélectionnez Autoriser, puis confirmez avec Autoriser l’accès.

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

Examiner OpenTelemetry et la couverture d’audit

Pour Work avec accès local et dots, distinguez la télémétrie d’exécution locale des enregistrements d’audit cloud lorsque vous examinez la couverture OpenTelemetry (OTel). Votre exécuteur local peut toujours exporter les événements d’exécution pris en charge. Les événements d’orchestration dans le 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 dans le cloud. Les enregistrements de la Compliance API ne remplacent pas tous les événements de l’ancien flux OpenTelemetry.

Pour dots, utilisez l’Analytics API pour l’utilisation et la Compliance API pour les enregistrements d’audit pris en charge. Validez les enregistrements nécessaires à votre workflow ainsi que leur transmission au collecteur local ; les hooks MCP ne remplacent pas une couverture d’audit.

Consultez Sécurité de Work dans le cloud pour connaître la couverture d’audit cloud.

Expérience utilisateur

Pour Work comme pour dots, les étapes locales nécessitent que l’ordinateur concerné soit en ligne et connecté, avec l’application de bureau ChatGPT en cours d’exécution et connectée au compte et à l’espace de travail appropriés.

Work

• Tâches admissibles. Les nouvelles tâches admissibles démarrées dans l’application de bureau ChatGPT avec Cloud sélectionné peuvent utiliser l’exécuteur local de cet ordinateur tant qu’il est connecté et que l’accès local est activé.

• Connexion. Utilisez Se connecter avec ChatGPT dans l’espace de travail prévu. Les API keys et les jetons d’accès Codex n’activent pas l’accès à l’ordinateur local avec Work Cloud.

• Ordinateur indisponible. Si l’ordinateur est indisponible au début d’un nouveau tour, une tâche admissible existante peut se poursuivre dans un conteneur cloud sans les fichiers ni les outils locaux de cet ordinateur. Le conteneur n’applique pas 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.

• Accès désactivé. La désactivation de l’accès à l’ordinateur local avec Work Cloud interrompt les tours en cours. Les utilisateurs peuvent démarrer un nouveau tour dans une conversation cloud existante ; celui-ci utilise Work Cloud sans accès aux fichiers locaux.

• Conversations et projets existants. Les tâches créées avant l’activation de cette fonctionnalité conservent leur mode d’origine : entièrement local, ou dans le cloud sans accès aux fichiers locaux. Démarrez une nouvelle tâche après l’activation de la fonctionnalité pour utiliser l’accès à l’ordinateur local avec Work Cloud.

• Paramètre Local/Cloud. Pour les entreprises, le sélecteur Local/Cloud de l’application et sa valeur par défaut restent inchangés au lancement. Les tâches admissibles avec Cloud sélectionné utilisent la coordination dans le cloud et l’ordinateur connecté pour les étapes locales.

Dots

• Connecter un ordinateur. Ouvrez les détails 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. L’ordinateur devient disponible pour les tâches locales prises en charge.

• Ordinateur hors ligne. L’autorisation d’accès enregistrée est conservée, mais le travail nécessitant cet ordinateur ne peut pas avancer tant qu’il est indisponible. Hors ligne ne signifie pas que l’accès a été révoqué.

• Supprimer l’accès. Choisissez Révoquer l’accès et confirmez pour retirer l’autorisation du dot sur cet ordinateur. Déconnecté signifie que l’accès a été supprimé ; cet état est différent de Hors ligne.

• Modifications de l’accès par un administrateur. Si un administrateur désactive l’accès à l’ordinateur local pour dots, une tâche locale déjà autorisée peut encore être en train de se terminer. Ne supposez pas que le comportement de Work, qui interrompt immédiatement les tours en cours, s’applique à dots.

• Tâches en cours. Une tâche locale en cours ne migre pas automatiquement vers le cloud. Les changements de connexion peuvent interrompre le travail ou recharger l’environnement d’exécution. Le dot peut poursuivre les travaux suivants sur son ordinateur cloud, mais une tâche enfant locale qui n’a plus accès à l’ordinateur ne peut pas y reprendre et n’est pas automatiquement déplacée vers le cloud.