Доступ к локальному компьютеру для Work Cloud и dots

Work и dots могут использовать разрешённые файлы и инструменты на подключённом компьютере, пока облако OpenAI координирует задачу. Включайте доступ к локальному компьютеру отдельно для каждой функции.

Сначала ознакомьтесь с общими рекомендациями по политикам, совместимости и аудиту ниже, а затем перейдите к инструкциям по настройке и использованию Work или dots — в зависимости от того, какую функцию вы планируете включить.

Это руководство помогает владельцам корпоративных рабочих пространств проверить требования политик и включить доступ к локальному компьютеру для Work и dots. Доступность зависит от рабочего пространства и этапа внедрения.

Сведения о базовых настройках Global, переопределениях для сред и списках полей оркестратора и исполнителя см. в разделе Agent Security.

Преимущества доступа к локальному компьютеру

Доступ к локальному компьютеру в этих функциях помогает командам продолжать работу на разных устройствах. Администраторы могут централизованно управлять поддерживаемыми требованиями к выполнению на локальном компьютере в Agent Security. Эти требования к выполнению не применяются, когда Work использует облачный контейнер или dot использует облачный компьютер. Для выполнения в облаке действуют отдельные настройки доступа к браузеру, доступа к сети и использования компьютера.

Work

• Продолжайте одну беседу Work на разных устройствах. Начните на компьютере, а затем просматривайте результаты или давайте дальнейшие указания в веб-версии или мобильном приложении. Задачи Work Cloud с доступом к локальному компьютеру используют облачную координацию.

• Используйте одобренные ресурсы на своём компьютере. Задача с этой функцией может использовать разрешённые локальные файлы и инструменты через подключённый компьютер, пока вы следите за работой с другого устройства. Для шагов, которым нужен этот компьютер, он должен оставаться в сети и быть подключён.

• Централизованно управляйте требованиями к локальному выполнению. Задайте поддерживаемые корпоративные требования к локальному выполнению в Agent Security. Отдельно проверьте политики Work Cloud для выполнения в облаке.

Dots

• Выполняйте инженерные задачи локально. Исследуйте ошибки, вносите изменения и запускайте сборки с помощью разрешённых локальных репозиториев, инструментов разработчика и навыков.

• Координируйте работу с кодом. Создавайте локальные ветки бесед Work или Codex и управляйте существующими локальными ветками бесед Codex.

• Используйте настольные приложения и локальный браузер для поддерживаемых задач, в том числе задач, требующих локального входа в учётную запись, когда облачный браузер не может их выполнить.

До и после включения доступа к локальному компьютеру в Work Cloud

Задача состоит из двух частей: координации и выполнения. Координация определяет необходимые шаги и обеспечивает продолжение беседы. Выполнение — это работа, которую выполняет инструмент, например запуск команды оболочки. Эта функция переносит координацию в облако OpenAI. Она не переносит все инструменты и файлы с компьютера.

Как настроить доступ к локальному компьютеру

Проверьте политику в Agent Security

Где проверять

Откройте консоль администратора → Agent Security. Этот раздел заменяет «Политики и конфигурация». Его внедрение не зависит от доступа к локальному компьютеру для Work и dots.

• Настройки политик: Проверьте базовые настройки Global и все переопределения Local. Храните настройки оркестратора, включая подтверждения и веб-поиск, в Global; среды не могут их переопределять. Используйте специальные элементы интерфейса, где они доступны, включая «Разрешённые политики подтверждения» и «Разрешённые режимы веб-поиска», а для остальных поддерживаемых полей — TOML. О том, где применяется каждая настройка, см. раздел «Настройки оркестратора и исполнителя».

• Требования и значения по умолчанию: Требования задают ограничения, которые пользователи не могут переопределить. Значения по умолчанию задают начальные значения в рамках этих ограничений и не могут переопределять требования.

• Доступ к функциям: Используйте «Настройки рабочего пространства → Разрешения и роли». Доступ к локальному компьютеру включается отдельно для Work и для dots.

Что переносится

При миграции подходящих устаревших облачных политик их настройки переносятся в Global с сохранением назначений и порядка политик. Проверьте перенесённые политики в Agent Security и сверьте текущую конфигурацию с таблицей ниже. Если вы автоматизируете обновление политик, также изучите последнюю строку. Рекомендации по миграции см. в разделе Agent Security.

Какая политика имеет приоритет

Эти правила действуют на разных уровнях. Каждая стрелка ниже направлена от более высокого приоритета к более низкому.

• Между политиками: Политика с более высоким приоритетом имеет преимущество перед политикой с более низким приоритетом, даже если последняя более конкретна.

• Внутри одной политики: Для поддерживаемых настроек выполнения: переопределение среды → Global. Среда без переопределения наследует применимую настройку Global.

• Локальные требования: Требования macOS MDM → устаревшие поля managed_config.toml, интерпретируемые как требования → требования Agent Security, управляемые из облака → системный requirements.toml. Уровень MDM применяется в macOS; для значений по умолчанию действуют отдельные правила конфигурации.

Для некоторых требований действуют особые правила объединения полей. Об области действия политик, поддерживаемых полях и области выполнения см. раздел «Управляемая конфигурация» и справочник по конфигурации.

Как политики применяются к Work и dots

Общее поведение Work и dots с локальным доступом охватывает следующие области:

• Координация задачи: Когда управляемая политика включена, облачный сервис, координирующий задачу, обеспечивает соблюдение поддерживаемых требований из Global в Agent Security, например требований к подтверждению и разрешённых режимов веб-поиска.

• Локальное выполнение: Когда инструмент запускается на подключённом компьютере, он обеспечивает соблюдение поддерживаемых требований к локальному выполнению из Agent Security и применимых политик устройства, включая политики, доставляемые через MDM, где это поддерживается. Они могут включать ограничения файловой системы и сети. Применяются только поля, поддерживаемые локальным исполнителем; настройка поля в MDM или локальном requirements.toml не гарантирует его соблюдения при локальном выполнении.

• Выполнение в облаке: Облачные контейнеры Work и облачные компьютеры dots используют отдельные средства управления выполнением. Локальные ограничения файловой системы и сети не применяются к этим облачным средам автоматически.

Для настройки общих облачных возможностей перейдите в «Консоль администратора → Разрешения и роли → Возможности рабочего пространства → Возможности облачного компьютера». Эти разрешения распространяются и на Work Cloud, и на dots. Проверяйте «Использование облачного браузера» и «Доступ к облачной сети» отдельно: настройка одного разрешения не настраивает другое. Политики Global и переопределения Codex Cloud не настраивают эти разрешения.

Проверьте совместимость и требования к данным

Прежде чем включать любую из функций, проверьте соответствие условиям, охват данных и средства контроля, на которые полагается ваша организация. Общая инфраструктура не означает одинаковую поддержку возможностей в Work и dots.

Проверьте соответствие условиям использования Work и dots

• Work: Резидентность распространяется только на подходящее содержимое и поддерживаемые рабочие нагрузки, регионы и конфигурации. EKM охватывает поддерживаемое хранимое содержимое в подходящих рабочих пространствах. Проверьте охват для своего процесса работы, не предполагая, что он распространяется на каждый шаг с локальным доступом или каждую подключённую интеграцию. Work не поддерживается при резидентности инференса в ОАЭ. См. «Резидентность данных и инференса» и «Безопасность Work в облаке».

• Резидентность dots: Во время бета-тестирования Enterprise dots не поддерживают резидентность данных или инференса. Подходящие рабочие пространства могут включить dots после подтверждения этих ограничений; включение dots не обеспечивает соответствие их данных или обработки требованиям резидентности.

• Исключения для dots: Dots недоступны в рабочих пространствах FedRAMP, рабочих пространствах с EKM и рабочих пространствах с резидентностью инференса AE (ОАЭ). Рабочие пространства HIPAA могут участвовать, если соответствуют остальным условиям.

Проверьте обработку данных и защитное ограничение локального доступа

• Обработка в облаке: Work с локальным доступом и dots по-прежнему используют облачную координацию. Беседы, результаты работы инструментов и другой контекст задачи не остаются исключительно на подключённом компьютере.

• Защитное ограничение резидентности: Если хотя бы одна облачная политика включает enforce_residency, настройка «Разрешить доступ к локальному компьютеру» недоступна и для Work, и для dots. Это ограничение не задаёт резидентность рабочего пространства и само по себе не отключает Work Cloud или dots. Подходящие рабочие пространства по-прежнему могут включить dots после подтверждения ограничений резидентности бета-версии; локальный доступ остаётся заблокированным.

• Хранение данных и доступ к ним: Ни одна из этих функций не обеспечивает строгое отсутствие хранения данных. API Zero Data Retention — отдельная настройка API. Обязательства «eyes-off» и средства контроля злоупотреблений также не равнозначны отсутствию хранения. Если процесс работы требует полного отсутствия хранения данных, не используйте для него эти функции.

Перед внедрением проверьте хранение, удаление и охват аудита для фактически используемых данных и инструментов. В Work беседы, состояние выполнения на сервере, файлы и данные подключённых приложений могут иметь разные жизненные циклы; удаление беседы не удаляет все связанные копии.

Проверьте совместимость хуков и сети

• Поддерживаемые корпоративные хуки: Когда включены управляемая политика и удалённые хуки, Work Cloud с локальным доступом и dots используют удалённые MCP-хуки, управляемые администратором. Облачный оркестратор вызывает подключённый MCP-сервис при поддерживаемых событиях задач и инструментов. Настройте обработчики mcp_tool в Global requirements.toml. Work Cloud без локального доступа не использует эти хуки; эти корпоративные хуки недоступны для личных учётных записей.

• Work Cloud и dots с локальным доступом: Обработчики команд/оболочки, запросов и агентов; хуки из локальной конфигурации, плагинов или локальных каталогов; хуки с областью действия на уровне среды; а также MCP-хуки SessionEnd не поддерживаются при облачной оркестрации, даже когда задача запускает инструменты на вашем компьютере. Если ваш процесс работы зависит от одного из этих хуков, продолжайте использовать полностью локальный процесс, который его поддерживает, пока не проверите альтернативу.

• Полностью локальные ветки бесед в Work и Codex: Когда и оркестрация, и выполнение происходят локально, существующие поддерживаемые хуки продолжают работать. Администраторы по-прежнему могут настраивать поддерживаемые управляемые хуки для этого процесса работы в Agent Security.

• Сбои и охват аудита: Проверьте доступность обратных вызовов, необходимые события и поведение при сбоях. Явный запрет в поддерживаемом формате может заблокировать действие, но ошибка обратного вызова PreToolUse, истечение времени ожидания или некорректный ответ могут привести к сбою хука без блокировки инструмента. Хуки не предоставляют полного журнала аудита Compliance API и не охватывают все внутренние пути выполнения субагентов.

• Средства контроля сети и приложений: Проверьте поле, способ доставки и среду выполнения в справочнике по конфигурации. Средства контроля на уровне приложения или устройства могут продолжать действовать, даже если облачный оркестратор не использует настройку. Управляемые порты прослушивания HTTP/SOCKS и прокси, прослушивающие адреса за пределами loopback, не поддерживаются облачной средой выполнения; поддержка правил сокетов зависит от пути выполнения. Изучите раздел «Приоритет сетевых политик и ограничения среды выполнения», затем проверьте разрешённые и запрещённые действия, а также необходимые подключения.

Ответы на вопросы о локальных файлах, выполнении в облаке и приоритете политик см. в вопросах и ответах для администраторов Work, разделе «Безопасность локального Work» и разделе «Безопасность Work в облаке».

Включите доступ к локальному компьютеру

Предоставляйте доступ к локальному компьютеру отдельно для Work и dots. Используйте настройки рабочего пространства по умолчанию и поддерживаемые пользовательские роли, чтобы предоставить доступ нужным пользователям или группам.

Перед внедрением изучите описанные выше политики и требования к совместимости. Рекомендуется проверить или создать политики в Agent Security, но процесс подтверждения не требует создания политик перед включением доступа. Миграция политик не предоставляет доступ к локальному компьютеру.

Work

1. Как владелец рабочего пространства откройте «Настройки рабочего пространства > Разрешения и роли».

2. Включите Work Cloud для нужных пользователей. Разрешение «Использовать Codex локально в настольном приложении ChatGPT» не является обязательным условием для этой функции.

3. В разделе Work Cloud включите «Разрешить доступ к локальному компьютеру». Ознакомьтесь с диалоговым окном подтверждения, затем откройте Agent Security, чтобы проверить или настроить политики, либо подтвердите включение доступа.

4. Попросите пользователей обновить настольное приложение ChatGPT до версии 26.929 или выше. Это обновление необходимо, чтобы доступ к локальному компьютеру в Work Cloud начал действовать.

5. Попросите участника с нужными разрешениями выбрать Cloud в поле ввода настольного приложения и начать новую задачу. Продолжите задачу с другого поддерживаемого устройства и проверьте доступ к одобренному локальному файлу или инструменту, пока компьютер подключён.

Dots

1. Как владелец рабочего пространства откройте «Настройки рабочего пространства > Разрешения и роли» и включите dots для нужных пользователей с учётом указанных выше условий.

2. В разделе «Использовать Dots» включите «Разрешить доступ к локальному компьютеру». Ознакомьтесь с диалоговым окном подтверждения, затем откройте Agent Security, чтобы проверить или настроить политики, либо подтвердите включение доступа.

3. Попросите пользователей обновить настольное приложение ChatGPT до версии 26.929 или выше. Это обновление необходимо, чтобы доступ к локальному компьютеру начал действовать.

4. Попросите пользователей открыть сведения о своём dot в настольном приложении ChatGPT и выбрать «Компьютеры». Найдите «Ваш компьютер» (или имя компьютера), выберите «Разрешить», затем подтвердите, нажав «Разрешить доступ».

5. Попросите участника с нужными разрешениями и подключённым компьютером проверить выполнение локальной задачи с помощью своего dot.

Проверьте охват OpenTelemetry и аудита

При проверке охвата OpenTelemetry (OTel) для Work с локальным доступом и dots различайте телеметрию локального выполнения и облачные записи аудита. Локальный исполнитель по-прежнему может экспортировать поддерживаемые события выполнения. События облачной оркестрации не поступают в ваш существующий коллектор OpenTelemetry.

Для поддерживаемых облачных записей используйте Compliance API. Изменение конечной точки коллектора не восстанавливает поступление событий облачной оркестрации. Записи Compliance API не заменяют все события прежнего потока OpenTelemetry.

Для dots используйте Analytics API для данных об использовании и Compliance API для поддерживаемых записей аудита. Проверяйте наличие записей, необходимых вашему процессу работы, наряду с доставкой в локальный коллектор; MCP-хуки не заменяют охват аудита.

Об охвате облачного аудита см. раздел «Безопасность Work в облаке».

Работа конечного пользователя

И для Work, и для dots локальные шаги требуют, чтобы соответствующий компьютер был в сети и подключён, а настольное приложение ChatGPT было запущено с выполненным входом в нужную учётную запись и рабочее пространство.

Work

• Подходящие задачи. Новые задачи, соответствующие условиям и запущенные в настольном приложении ChatGPT с выбранным режимом Cloud, могут использовать локальный исполнитель этого компьютера, пока он подключён и локальный доступ включён.

• Вход. Используйте «Войти с ChatGPT» в нужном рабочем пространстве. API key и токены доступа Codex не включают доступ к локальному компьютеру в Work Cloud.

• Компьютер недоступен. Если компьютер недоступен в начале нового хода, существующая подходящая задача может продолжиться в облачном контейнере без локальных файлов и инструментов этого компьютера. Контейнер не обеспечивает соблюдение корпоративных требований к локальному выполнению. Задача не может переключиться с локального выполнения на облачное в течение одного хода.

• Доступ отключён. Отключение доступа к локальному компьютеру в Work Cloud прерывает текущие выполняемые ходы. Пользователи могут начать новый ход в существующей облачной беседе; он будет использовать Work Cloud без доступа к локальным файлам.

• Существующие чаты и проекты. Задачи, созданные до включения этой функции, сохраняют исходный режим: только локально либо в облаке без доступа к локальным файлам. Чтобы использовать доступ к локальному компьютеру в Work Cloud, начните новую задачу после включения функции.

• Настройка Local/Cloud. Для корпоративных клиентов переключатель Local/Cloud в приложении и его значение по умолчанию на момент запуска остаются прежними. Подходящие задачи с выбранным режимом Cloud используют облачную координацию и подключённый компьютер для локальных шагов.

Dots

• Подключение компьютера. Откройте сведения о dot в настольном приложении ChatGPT, затем выберите «Компьютеры». Найдите «Ваш компьютер» (или имя компьютера), выберите «Разрешить», затем подтвердите, нажав «Разрешить доступ». Компьютер станет доступен для поддерживаемых локальных задач.

• Компьютер не в сети. Предоставленное разрешение на доступ сохраняется, но работа, требующая этого компьютера, не может продолжаться, пока он недоступен. Статус «Не в сети» не означает, что доступ отозван.

• Удаление доступа. Выберите «Отозвать доступ» и подтвердите действие, чтобы удалить разрешение dot на доступ к этому компьютеру. Статус «Отключён» означает, что доступ удалён; он отличается от статуса «Не в сети».

• Изменение доступа администратором. Если администратор отключает доступ к локальному компьютеру для dots, уже авторизованная локальная задача может ещё завершать работу. Не предполагайте, что немедленное прерывание выполняемых ходов, характерное для Work, также применяется к dots.

• Выполняемые задачи. Выполняемая локальная задача не переносится в облако автоматически. Изменения подключения могут прервать работу или перезапустить среду выполнения. Dot может продолжить последующую работу на своём облачном компьютере, но локальная дочерняя задача, утратившая доступ, не сможет возобновиться на этом компьютере и не будет автоматически перенесена в облако.