Segurança local do ChatGPT Work

O ChatGPT Work pode utilizar ficheiros, aplicações e sessões de navegador aprovados no computador de um utilizador para concluir tarefas locais. O acesso depende das permissões do espaço de trabalho, do acesso já existente na conta do utilizador, das permissões do sistema operativo, das aprovações de aplicações e das políticas de dispositivos suportadas.

Para obter uma visão geral dos controlos de segurança, consulte o livro branco sobre segurança empresarial do ChatGPT Work.

As capacidades locais dependem da aplicação para computador suportada, do sistema operativo, dos direitos do espaço de trabalho, das permissões da função, da política do dispositivo e da disponibilização do produto.

Resumo da segurança

• Os passos locais são executados através da aplicação ChatGPT para computador. No acesso ao computador local com o Work Cloud, a nuvem da OpenAI coordena a tarefa enquanto o computador ligado executa os passos que dele necessitam.

• Os controlos locais e alojados do Work disponíveis dependem da configuração e da disponibilização no espaço de trabalho.

• O acesso a ficheiros, o Computer Use, os navegadores e as aplicações ligadas utilizam permissões e aprovações diferentes.

• Um navegador ou uma aplicação que já tenha sessão iniciada num sistema da empresa pode expor as permissões dessa conta existente.

• As políticas de dispositivos geridos suportadas podem restringir funcionalidades locais sem substituir os controlos de acesso do espaço de trabalho.

• Os dados dos espaços de trabalho Business, Enterprise e Edu processados pelos serviços OpenAI abrangidos são encriptados em trânsito e em repouso e, por predefinição, não são utilizados para treinar modelos da OpenAI.

• Os ficheiros locais, o contexto das tarefas, os dados do navegador, os registos de sistemas ligados e os eventos de auditoria podem estar sujeitos a regras de armazenamento e retenção diferentes.

Onde são executadas as tarefas locais

A execução local acede a recursos aprovados através da aplicação para computador no computador do utilizador. Com o acesso ao computador local com o Work Cloud ativado, a nuvem da OpenAI coordena a tarefa e invoca o computador ligado quando um passo necessita de execução local. O computador tem de estar online e ligado para esses passos.

O acesso ao computador local com o Work Cloud aplica-se apenas a tarefas criadas depois de ativar a sincronização. As tarefas existentes, incluindo as tarefas em projetos, mantêm o modo original: apenas localmente ou na nuvem sem acesso a ficheiros locais. Inicie uma nova tarefa para utilizar esta funcionalidade.

Se o computador estiver indisponível quando um novo turno começar, uma tarefa existente elegível que utilize o acesso ao computador local com o Work Cloud pode continuar num contentor na nuvem. O contentor na nuvem não pode aceder a ficheiros ou ferramentas no computador indisponível. Também não aplica os requisitos empresariais da execução local. Uma tarefa não pode passar da execução local para a nuvem durante um turno.

Os ficheiros locais podem permanecer no dispositivo, mas excertos de ficheiros relevantes, prompts, capturas de ecrã, conteúdo do navegador ou resultados de ferramentas podem ser enviados para os serviços OpenAI para concluir uma tarefa. A execução local não significa inferência de modelos offline ou apenas no dispositivo.

Acesso a ficheiros e ao dispositivo

Uma tarefa local pode trabalhar com informações que o utilizador forneça ou disponibilize, incluindo ficheiros suportados, conteúdo de aplicações, sessões de navegador e sistemas ligados autorizados. O acesso depende dos privilégios existentes do utilizador e dos controlos que regem essa capacidade específica.

Conceder acesso local ao Work não aprova automaticamente todas as aplicações, não concede direitos de administrador nem contorna as permissões da conta utilizada para aceder a outro sistema. Uma ligação partilhada aprovada pode ter privilégios diferentes dos da conta pessoal do utilizador.

As leituras diretas de ficheiros, as edições de ficheiros e os comandos de shell seguem as definições de sandbox e de aprovação da tarefa. O Computer Use acede ao conteúdo através de uma aplicação nativa aprovada, ao abrigo das permissões dessa aplicação. Uma restrição ao acesso direto a ficheiros não estabelece, por si só, a mesma restrição aos ficheiros que a aplicação pode abrir.

Computer Use e aprovações de aplicações

As permissões do espaço de trabalho determinam quem pode utilizar o Work Local. As políticas dos administradores podem restringir ainda mais as aplicações nativas que o Computer Use pode operar e determinar se as aprovações de aplicações podem ser guardadas para sessões futuras. As permissões do sistema operativo e as aprovações de aplicações necessárias continuam a aplicar-se. Quando uma tarefa utiliza uma aplicação ou uma conta com sessão iniciada, as permissões dessa conta determinam as informações e ações disponíveis.

Permitir uma aplicação através de uma política de administrador não instala o plugin necessário, não concede permissões do sistema operativo nem aprova uma ação que ainda exija revisão. Para conhecer os controlos suportados e exemplos de configuração, consulte Controlos geridos do navegador e do Computer Use.

No macOS, a Gravação do ecrã permite ao Computer Use ver o conteúdo das aplicações e a Acessibilidade permite-lhe clicar, escrever e navegar. As tarefas macOS suportadas podem ser executadas em segundo plano. No Windows, o Computer Use funciona no ambiente de trabalho ativo e visível e não pode ser executado em segundo plano enquanto o utilizador continua a utilizar essa mesma sessão.

Os utilizadores podem parar uma tarefa em qualquer altura. O Computer Use não pode aprovar pedidos de segurança do sistema operativo, autenticar-se como administrador nem automatizar aplicações de terminal ou o próprio ChatGPT.

Dispositivos bloqueados

As configurações de macOS suportadas podem, opcionalmente, permitir que uma tarefa aprovada do Computer Use continue após o bloqueio do Mac. A disponibilidade depende da versão da aplicação, da disponibilização gradual da funcionalidade, dos requisitos aplicáveis e da elegibilidade para controlo remoto.

A ativação do Locked Use instala um plugin de autorização do macOS que pode desbloquear temporariamente o Mac para um turno ativo e de confiança do Computer Use. O ChatGPT cobre todos os ecrãs durante o desbloqueio temporário. Se detetar atividade local do teclado ou do dispositivo apontador, volta a bloquear o Mac e suspende o desbloqueio automático até que o utilizador o desbloqueie manualmente. Consulte Como funciona o Locked Use.

Os administradores podem impedir que os utilizadores ativem o Locked Use em Macs geridos. Este requisito não desativa o Locked Use se já estiver ativado. O Computer Use no Windows requer um ambiente de trabalho ativo e desbloqueado. Consulte Restrições do Locked Use.

Sessões de navegador e sessões já iniciadas

O Work Local não obtém automaticamente acesso a todos os navegadores ou contas da empresa. O acesso depende do navegador utilizado, da conta com sessão iniciada e das aprovações necessárias para essa experiência de navegação.

As políticas suportadas do Browser Use podem restringir o acesso a sites, os carregamentos, as transferências, o acesso ao histórico do navegador e o acesso completo ao Chrome DevTools Protocol (CDP) para depuração do navegador. Os administradores também podem restringir a revisão automática de aprovações, as aprovações guardadas e a duração das aprovações de acesso a sites. Uma aprovação do utilizador não pode sobrepor-se a uma recusa do administrador. Consulte Controlos geridos do navegador.

Um navegador alojado na nuvem é separado dos navegadores locais do utilizador e não herda automaticamente as respetivas sessões iniciadas. O início de sessão em sites através do navegador na nuvem não está disponível nos espaços de trabalho Enterprise ou Edu.

Aplicações, plugins e contas ligadas

Uma aplicação ligada pode proporcionar acesso a informações ou ações noutro sistema. Um plugin pode utilizar uma aplicação como ferramenta subjacente. Disponibilizar um plugin não ativa automaticamente a aplicação necessária, não autoriza uma conta nem permite todas as ações.

As predefinições de plugins e aplicações dependem do plano e de o espaço de trabalho ser novo ou existente. Os novos espaços de trabalho Enterprise e Edu começam com um conjunto selecionado de aplicações ativadas; essas predefinições não alteram as definições dos espaços de trabalho existentes e não se aplicam aos espaços de trabalho Healthcare. Em geral, os novos plugins e aplicações estão desativados por predefinição no Enterprise e no Edu. As aplicações do Business estão ativadas por predefinição. Os administradores podem alterar a disponibilidade. Consulte as predefinições atuais de plugins e aplicações e a visão geral do ChatGPT Work.

Antes de uma tarefa utilizar um sistema ligado, confirme que o espaço de trabalho permite a aplicação e qualquer plugin necessário, que a ligação está autorizada e que a conta ligada pode aceder às informações ou ações solicitadas. As definições só de leitura, as ações permitidas e os requisitos de confirmação variam consoante a integração.

Os plugins que disponibilizam capacidades de navegador ou do Computer Use exigem uma revisão específica da sua disponibilidade e instalação. Disponibilizar um plugin não se sobrepõe às políticas geridas de navegador ou de aplicações nativas, às permissões do sistema operativo nem às aprovações necessárias. Os plugins exclusivos para computador e as ferramentas disponibilizadas localmente podem seguir vias de instalação diferentes. Consulte Controlos de plugins.

Ligações pessoais e partilhadas

Uma ligação pessoal utiliza as permissões do utilizador ligado no sistema de origem. Uma ligação partilhada ou pertencente a um agente utiliza as permissões da conta ligada, que podem ser mais abrangentes do que o acesso do próprio utilizador.

Limite as contas partilhadas aos dados e ações necessários, restrinja quem as pode utilizar e aplique os controlos de ações ou confirmação suportados. Os registos no sistema ligado continuam sujeitos às políticas de permissões e retenção desse sistema.

Acesso de administrador e políticas de dispositivos geridos

Para o acesso ao computador local com o Work Cloud, reveja tanto a permissão de sincronização do espaço de trabalho como os requisitos do Agent Security para a execução local.

Para a execução local, os requisitos de MDM e os requisitos legados de dispositivos geridos têm prioridade sobre o Agent Security. O ficheiro de requisitos do sistema do dispositivo tem prioridade inferior à do Agent Security. Numa dada política, as substituições de ambiente específicas do sistema operativo têm prioridade sobre as substituições de ambiente para todos os sistemas operativos, seguidas de Global. Uma política de prioridade superior prevalece mesmo que uma política de prioridade inferior seja mais específica. Alguns requisitos têm regras de combinação específicas de cada campo.

Utilize a API de políticas para gerir as definições de Global. Para gerir as definições de Local ou Codex Cloud, utilize a interface do Agent Security. Os fluxos de trabalho existentes da API de Global continuam disponíveis após a migração. Teste os seus scripts e integrações do Terraform e confirme que as atribuições e a ordenação das políticas não foram alteradas.

Para o Work com acesso local e o dots, a política Global suportada aplica-se através do orquestrador partilhado na nuvem quando a política gerida está ativada. Os requisitos locais aplicáveis de requirements.toml regem a execução num computador ligado. Os contentores na nuvem do Work e os computadores na nuvem do dots utilizam a sua própria configuração e os seus próprios requisitos de execução, em vez do pacote de ambiente gerido utilizado por outros tipos de executores. As restrições de execução local não se aplicam automaticamente a estes computadores na nuvem. Reveja as permissões das capacidades na nuvem e teste separadamente a execução local e a execução na nuvem.

Antes de ativar a sincronização, reveja estes requisitos:

• Políticas distribuídas apenas através de MDM. O MDM distribui políticas aos dispositivos. Crie uma configuração de base no Agent Security para os requisitos de execução local suportados antes de ativar a sincronização.

• Hooks empresariais. Quando ativado para o seu espaço de trabalho, o acesso ao computador local com o Work Cloud suporta hooks MCP definidos pelo administrador que são executados no coordenador na nuvem (orquestrador) para eventos suportados do ciclo de vida e de ferramentas. Os hooks de comandos e os hooks provenientes da configuração local ou de plugins não são suportados com a orquestração na nuvem, mesmo quando as ferramentas são executadas localmente. Quando tanto a orquestração como a execução são locais, os hooks existentes suportados continuam a funcionar nas conversas exclusivamente locais do Work e do Codex. Os administradores podem continuar a configurar hooks geridos suportados no Agent Security para esses fluxos de trabalho.

• Auditoria. Antes de confiar nestes hooks, teste a ligação de callback, confirme os eventos que recebe e verifique como as falhas afetam a tarefa. Os hooks MCP não fornecem um registo de auditoria completo da Compliance API.

Reveja os controlos do Work disponíveis em Definições do espaço de trabalho > Permissões e funções. A apresentação do Work local e alojado como permissões distintas depende da configuração do espaço de trabalho e da disponibilização gradual. Para mais orientações, consulte as Perguntas frequentes para administradores do Work.

Ative apenas os ambientes de execução aprovados para cada utilizador ou grupo e verifique o acesso efetivo depois de efetuar alterações.

As permissões do espaço de trabalho determinam quem pode utilizar o Work. Os administradores também podem restringir as capacidades suportadas da aplicação para computador através de requisitos impostos definidos em requirements.toml. Dependendo da implementação, estes requisitos podem ser fornecidos através de uma configuração gerida pelo espaço de trabalho, de um ficheiro de configuração ao nível do sistema ou de ferramentas de gestão de dispositivos móveis macOS suportadas.

Os requisitos impostos não podem ser substituídos por utilizadores individuais. Em contrapartida, as predefinições geridas estabelecem definições iniciais que os utilizadores poderão alterar. Nenhuma delas substitui as funções do espaço de trabalho ou as permissões do sistema operativo.

Nos clientes locais que utilizam o mecanismo de configuração local existente, os requisitos geridos são carregados durante o carregamento da configuração. Uma atualização em segundo plano pode preparar os requisitos da nuvem para um carregamento posterior, e as alterações de MDM no macOS são lidas no arranque seguinte do cliente. Reinicie e verifique o cliente local aplicável após uma alteração de política local.

Desativar o acesso ao computador local com o Work Cloud interrompe os turnos em curso. Os utilizadores podem iniciar um novo turno numa conversa existente na nuvem. Esse turno utiliza automaticamente o Work Cloud sem acesso a ficheiros locais.

Este comportamento de carregamento local não determina quando uma alteração de política na nuvem entra em vigor numa tarefa em curso que utiliza o acesso ao computador local com o Work Cloud. Verifique os controlos efetivos da tarefa antes de confiar na atualização.

Estes são exemplos de restrições, não uma lista de predefinições ativadas. A omissão de um requisito de funcionalidade mantém em vigor as definições normais do cliente, da plataforma, da disponibilização gradual e do utilizador. Os sinalizadores de funcionalidades de Browser Use, o painel do navegador integrado e o Computer Use nativo são controlos separados. Verifique cada via de utilização do navegador de forma independente.

As definições e os métodos de distribuição disponíveis dependem do cliente, do sistema operativo, do espaço de trabalho e da configuração da implementação. Verifique as restrições num dispositivo gerido representativo. Para conhecer as definições de política suportadas, exemplos de configuração e instruções de configuração de MDM, consulte Configuração gerida.

Redes locais e recursos privados

O Work Local pode aceder a informações da empresa através de um navegador, de uma aplicação nativa, de uma aplicação ligada ou de outra ferramenta suportada. Os controlos de rede aplicam-se de forma diferente a cada via, e o acesso a uma VPN empresarial não autoriza, por si só, uma tarefa a utilizar um recurso interno.

Os requisitos de rede geridos e as políticas de origem de Browser Use são verificações separadas. Verifique ambos nas versões da aplicação e nos sistemas operativos da sua implementação antes de confiar numa restrição de rede para limitar o Browser Use. As verificações de políticas do navegador não significam que o tráfego do navegador seja encaminhado através do proxy de rede de comandos, e as políticas de Browser Use não regem o tráfego das aplicações nativas.

Os requisitos de rede geridos em [experimental_network] são experimentais e podem mudar. O suporte para Windows é limitado; teste o cliente e o ambiente exatos antes de os aplicar a utilizadores do Windows. As regras de domínio, por si só, não ativam o proxy gerido; experimental_network.enabled = true é obrigatório e não se sobrepõe a uma sandbox que mantenha o acesso à rede desativado.

Reveja a ligação, a conta com sessão iniciada, o destino e a ação exigidos pelo fluxo de trabalho. Para obter detalhes de configuração e conhecer as limitações de plataforma, consulte Requisitos de acesso à rede.

Tratamento e retenção de dados

No acesso ao computador local com o Work Cloud, a coordenação na nuvem faz parte do fluxo de trabalho mesmo quando um passo é executado no computador. Reveja os dados da conversa e o contexto da tarefa separadamente dos ficheiros locais utilizados por uma ferramenta. Não deduza que a execução local implica armazenamento apenas no dispositivo ou que todos os ficheiros de uma pasta são carregados.

O acesso ao computador local com o Work Cloud não oferece retenção estritamente nula de dados. A residência de dados e a residência de inferência abrangem apenas conteúdo elegível e cargas de trabalho, regiões e configurações suportadas. O Enterprise Key Management (EKM) abrange conteúdo armazenado suportado em espaços de trabalho elegíveis. O Work não é suportado com residência de inferência nos EAU. Confirme a cobertura de armazenamento, retenção e auditoria do espaço de trabalho antes da disponibilização. Se a sua organização exigir ZDR, não ative esta funcionalidade. Se enforce_residency estiver ativado em qualquer política na nuvem, Permitir acesso ao computador local é desativado tanto para o Work como para o dots. Esta salvaguarda não configura a residência do espaço de trabalho nem, por si só, desativa o Work Cloud ou o dots.

Aplique os controlos de endpoint, acesso a ficheiros, proxy e prevenção contra perda de dados da sua organização ao dispositivo e fluxo de trabalho específicos. Confirme se esses controlos conseguem impedir a entrada de informações confidenciais na tarefa antes do processamento. Os registos de auditoria e as exportações de conformidade ajudam na monitorização e investigação, mas não bloqueiam o processamento por si só.

O armazenamento e a retenção dependem da categoria das informações e do local onde são guardadas.

Nos espaços de trabalho Business, Enterprise e Edu suportados, os dados empresariais processados pelos serviços OpenAI abrangidos são encriptados em trânsito e em repouso e, por predefinição, não são utilizados para treinar ou melhorar modelos da OpenAI. Estas proteções não significam que a OpenAI rege todos os ficheiros do dispositivo, aplicações de terceiros, perfis do navegador ou registos do sistema de origem.

Não aplique um período de retenção de conversas alojadas, carregamentos temporários ou registos de conformidade aos registos locais sem confirmar que este se aplica à categoria de dados específica.

Visibilidade de auditoria e conformidade

Ativar o acesso ao computador local com o Work Cloud altera o que o seu coletor OpenTelemetry (OTel) existente recebe. O executor local pode continuar a exportar eventos de execução suportados. Os eventos de orquestração na nuvem não chegam ao seu coletor OpenTelemetry existente.

Utilize a Compliance API para os registos suportados da nuvem. Alterar o endpoint do coletor não restabelece os eventos de orquestração na nuvem. Os registos da Compliance API não substituem todos os eventos do fluxo OpenTelemetry anterior. Consulte Rever o OpenTelemetry e a cobertura de auditoria.

Os relatórios disponíveis dependem do plano do espaço de trabalho, da experiência do produto, do evento, da aplicação ligada e da configuração implementada. Verifique a cobertura do Work Local antes de depender de uma exportação do espaço de trabalho para a resposta a incidentes ou a análise regulamentar.

Nas versões suportadas, o Browser Use pode emitir eventos OpenTelemetry para verificações de capacidades, incluindo acesso a sites, carregamentos e transferências. Estes eventos registam a decisão e a origem da decisão, com detalhes da política quando disponíveis. A origem da decisão pode ser desconhecida. Quando a exportação está configurada, são enviados para o endpoint OpenTelemetry do cliente juntamente com outra telemetria do ambiente de execução local.

Configure a exportação OpenTelemetry separadamente dos registos da Compliance API. Estes eventos não constituem um registo completo de todas as ações do navegador ou das aplicações nativas. Consulte Configuração do OpenTelemetry.

Determine se os sistemas relevantes registam a identidade da tarefa, os prompts e respostas suportados, as chamadas a aplicações ligadas, as aprovações do navegador, as ações em aplicações, a atividade em ficheiros locais ou os eventos de endpoint. Os registos do sistema de origem e do dispositivo podem proporcionar uma visibilidade diferente dos registos do espaço de trabalho do ChatGPT.

A OpenAI não armazena um registo completo separado das ações do Chrome efetuadas através da extensão. Não pressuponha que todas as operações em ficheiros locais, capturas de ecrã, ações no navegador, aprovações ou atualizações externas aparecem na Compliance API.

Comece com uma tarefa aprovada

Verifique o Work local nos dispositivos geridos que as suas equipas utilizam. Execute uma tarefa aprovada, como comparar livros de cálculo financeiros selecionados. Confirme o acesso de cada utilizador ao Work e disponibilize apenas os ficheiros, aplicações, sessões do navegador ou contas ligadas de que a tarefa necessita.

Verifique se as ações aprovadas funcionam, se as ações restritas são bloqueadas e se os registos disponíveis satisfazem as suas necessidades de monitorização. Peça ao utilizador que reveja os resultados e confirme que quaisquer alterações a ficheiros ou sistemas ligados correspondem ao pedido.