Acesso ao computador local para o Work na nuvem e os dots

O modo Work e os dots podem usar os arquivos e as ferramentas permitidos em um computador conectado enquanto a nuvem da OpenAI coordena a tarefa. Ative o acesso ao computador local separadamente para cada recurso.

Comece pelas orientações sobre políticas compartilhadas, compatibilidade e auditoria. Depois, siga as instruções de configuração e uso do modo Work ou dos dots, conforme o recurso que pretende ativar.

Este guia ajuda os proprietários de espaços de trabalho empresariais a revisar os requisitos das políticas e a ativar o acesso ao computador local para o modo Work e os dots. A disponibilidade depende do espaço de trabalho e da etapa de lançamento.

Consulte Segurança de agentes para conferir a configuração de referência do escopo Global, as configurações que podem substituí-la em cada ambiente e as listas de campos do orquestrador e do executor.

Benefícios do acesso ao computador local

Com o acesso ao computador local, as equipes podem começar uma tarefa em um dispositivo e continuá-la em outro. Em Segurança de agentes, os administradores podem gerenciar de forma centralizada os requisitos compatíveis com a execução em um computador local. Esses requisitos de execução não se aplicam quando o modo Work usa um contêiner na nuvem ou um dot usa um computador na nuvem. A execução na nuvem tem controles próprios para acesso ao navegador, acesso à rede e uso do computador.

Modo Work

Os membros podem continuar uma tarefa do modo Work em outro dispositivo e usar recursos locais aprovados por meio de um computador conectado. Os administradores podem gerenciar os requisitos de execução local em Segurança de agentes e revisar a execução na nuvem separadamente.

dots

• Execute tarefas de engenharia localmente. Investigue bugs, implemente alterações e execute builds usando os repositórios locais, as ferramentas de desenvolvimento e as habilidades permitidos.

• Coordene tarefas de programação. Crie conversas locais no modo Work ou no Codex e controle conversas locais existentes no Codex.

• Use aplicativos de desktop e o navegador local nas tarefas compatíveis, inclusive nas que exigem login local quando o navegador na nuvem não consegue concluí-las.

Antes e depois de ativar o acesso ao computador local com o Work na nuvem

Uma tarefa tem duas partes: coordenação e execução. A coordenação define as próximas etapas e dá continuidade à conversa. A execução é o trabalho que uma ferramenta realiza, como executar um comando de shell. Com esse recurso, a nuvem da OpenAI passa a coordenar a tarefa. Isso não transfere todas as ferramentas e todos os arquivos do computador para a nuvem.

Como configurar o acesso ao computador local

Revise sua política em Segurança de agentes

Onde revisar

Abra Console de administração → Segurança de agentes. Essa seção substitui Políticas e configuração. Sua disponibilização é independente da liberação do acesso ao computador local para o modo Work e os dots.

• Configurações da política: Revise a configuração de referência do escopo Global e as substituições no escopo Local. Mantenha os controles do orquestrador, incluindo aprovações e pesquisa na Web, no escopo Global. Os ambientes não podem substituí-los. Use os controles específicos da interface quando disponíveis, incluindo Políticas de aprovação permitidas e Modos de pesquisa na Web permitidos. Para os demais campos compatíveis, use TOML. Consulte os controles do orquestrador e do executor para ver onde cada configuração se aplica.

• Requisitos e valores padrão: Os requisitos definem limites que os usuários não podem alterar. Os valores padrão servem como ponto de partida dentro desses limites e não podem se sobrepor a um requisito.

• Acesso aos recursos: Acesse Console de administração → Permissões. É preciso ativar o acesso ao computador local separadamente para o modo Work e os dots.

O que a migração preserva

Quando as políticas legadas de nuvem elegíveis são migradas, suas configurações passam para o escopo Global, mantendo as atribuições e a ordem das políticas. Revise as políticas migradas em Segurança de agentes e use a tabela abaixo para conferir sua configuração atual. Se você automatiza as atualizações de políticas, confira também a última linha. Consulte Segurança de agentes para orientações sobre a migração.

Qual política tem prioridade

As regras a seguir se aplicam em níveis diferentes. As setas indicam a ordem da maior para a menor prioridade.

• Entre políticas: A política de maior prioridade prevalece mesmo quando a de menor prioridade é mais específica.

• Dentro de uma política: Para as configurações de execução compatíveis, a ordem é: substituição no ambiente → Global. Se não houver substituição, o ambiente herda a configuração aplicável do escopo Global.

• Requisitos locais: Requisitos de MDM do macOS → campos legados de managed_config.toml interpretados como requisitos → requisitos de Segurança de agentes gerenciados na nuvem → requirements.toml do sistema. A camada de MDM se aplica ao macOS. Os valores padrão seguem regras de configuração próprias.

Alguns requisitos têm regras de combinação específicas para cada campo. Consulte Configuração gerenciada e a Referência de configuração para conferir o escopo das políticas, os campos compatíveis e o escopo de execução.

Como as políticas se aplicam ao modo Work e aos dots

Com o acesso local, o modo Work e os dots seguem as mesmas regras nos seguintes escopos:

• Coordenação da tarefa: Quando a política gerenciada está ativa, o serviço de nuvem que coordena a tarefa aplica os requisitos compatíveis definidos no escopo Global de Segurança de agentes, como requisitos de aprovação e modos de pesquisa na Web permitidos.

• Execução local: Quando uma ferramenta é executada em um computador conectado, ela aplica os requisitos de Segurança de agentes compatíveis com a execução local e as políticas de dispositivo aplicáveis, incluindo as distribuídas por MDM quando há suporte. Esses controles podem incluir restrições de rede e do sistema de arquivos. Apenas os campos compatíveis com o executor local se aplicam. Configurar um campo no MDM ou no requirements.toml local não garante que o executor o aplique.

• Execução na nuvem: Os contêineres do Work na nuvem e os computadores dos dots na nuvem usam controles de execução próprios. As restrições locais de rede e do sistema de arquivos não se aplicam automaticamente a esses ambientes de nuvem.

Confira a compatibilidade e os requisitos de dados

Antes de ativar qualquer um dos recursos, confira a elegibilidade, quais dados estão cobertos e os controles dos quais sua organização depende. Embora compartilhem a infraestrutura, o modo Work e os dots oferecem suporte a configurações diferentes.

Confira a elegibilidade para o modo Work e os dots

• Modo Work: A residência se aplica apenas ao conteúdo elegível e às cargas de trabalho, regiões e configurações compatíveis. O EKM abrange o conteúdo armazenado compatível em espaços de trabalho elegíveis. Confirme a cobertura do seu fluxo de trabalho, pois ela pode não incluir todas as etapas de acesso local ou todas as integrações conectadas. O modo Work não é compatível com a residência de inferência nos Emirados Árabes Unidos. Consulte Residência de dados e residência de inferência e Segurança do Work na nuvem.

• Residência para os dots: Durante a fase beta do Enterprise, os dots não oferecem suporte à residência de dados nem à residência de inferência. Os espaços de trabalho elegíveis podem aderir após confirmar que estão cientes dessas limitações. Ativar os dots não faz com que seus dados ou seu processamento atendam aos requisitos de residência.

• Exclusões para os dots: Os dots não estão disponíveis em espaços de trabalho FedRAMP, com EKM ou com residência de inferência definida como AE (Emirados Árabes Unidos). Espaços de trabalho HIPAA podem participar se atenderem aos demais requisitos de elegibilidade.

Confira o tratamento de dados e a proteção de acesso local

• Processamento na nuvem: O modo Work com acesso local e os dots continuam usando coordenação na nuvem. As conversas, os resultados das ferramentas e os demais dados de contexto da tarefa não ficam exclusivamente no computador conectado.

• Proteção de residência: Se qualquer política de nuvem ativar enforce_residency, a opção Permitir acesso ao computador local ficará indisponível tanto para o modo Work quanto para os dots. Essa proteção não define a residência do espaço de trabalho nem, por si só, desativa o Work na nuvem ou os dots. Os espaços de trabalho elegíveis ainda podem ativar os dots após confirmar que estão cientes das limitações de residência da versão beta. O acesso local continua bloqueado.

• Retenção e acesso aos dados: Nenhum dos dois recursos oferece zero retenção de dados em sentido estrito. A zero retenção de dados da API é um controle específico da API. Os compromissos de “não visualização do conteúdo” e os controles de monitoramento de abuso também são distintos da zero retenção de dados. Se um fluxo de trabalho exigir que nenhum dado seja retido, não o habilite nesses recursos.

Antes da implantação, confira as regras de retenção e exclusão e a cobertura de auditoria para os dados e as ferramentas que serão usados. No modo Work, as conversas, o estado da execução hospedada, os arquivos e os dados de aplicativos conectados podem ter ciclos de vida diferentes. Excluir uma conversa não remove todas as cópias relacionadas.

Confira a compatibilidade dos hooks e da rede

• Compatibilidade dos hooks: Antes de ativar o acesso local, confira se há avisos de compatibilidade nas configurações do espaço de trabalho e em Segurança de agentes. Compare os hooks necessários para o seu fluxo de trabalho com os hooks compatíveis com a orquestração na nuvem. Se o fluxo depender de um hook de comando local ou de um hook de plugin, mantenha esse fluxo exclusivamente local.

• Falhas e cobertura de auditoria: Teste a conexão de callback, os eventos necessários e o comportamento da ferramenta após um erro de callback ou quando o tempo limite do callback for excedido. Se um hook PreToolUse falhar, a ferramenta ainda poderá ser executada. Os hooks não cobrem todos os caminhos internos de execução dos subagentes. Confira separadamente os registros de auditoria disponíveis.

• Controles de rede e de aplicativos: Confira o campo, o mecanismo de distribuição e o ambiente de execução na Referência de configuração. Os controles aplicados pelo aplicativo ou pelo dispositivo podem continuar valendo mesmo quando o orquestrador na nuvem não usa determinada configuração. O ambiente de execução na nuvem não oferece suporte a portas de escuta HTTP/SOCKS gerenciadas nem a proxies que escutam em endereços fora do loopback. O suporte a regras de socket depende do caminho de execução. Consulte Precedência das políticas de rede e limites do ambiente de execução e teste as ações permitidas, as ações bloqueadas e a conectividade necessária.

Para esclarecer dúvidas sobre arquivos locais, execução na nuvem ou precedência de políticas, consulte as perguntas frequentes de administradores do modo Work, a segurança do modo Work local e a segurança do Work na nuvem.

Ative o acesso ao computador local

Conceda acesso ao computador local separadamente para o modo Work e os dots. Use as configurações padrão do espaço de trabalho e as funções personalizadas compatíveis para conceder acesso aos usuários ou grupos desejados.

Antes da implantação, revise as políticas e os requisitos de compatibilidade acima. É recomendável revisar ou criar políticas em Segurança de agentes, mas o fluxo de confirmação permite ativar o acesso sem criar políticas antes. A migração de políticas não concede acesso ao computador local.

Modo Work

1. Como proprietário do espaço de trabalho, abra Console de administração > Permissões.

2. Ative Work na nuvem para os usuários desejados. A opção Usar o Codex localmente no aplicativo ChatGPT para desktop não é um pré-requisito para esse recurso.

3. Em Work na nuvem, ative Permitir acesso ao computador local. Leia a caixa de diálogo de confirmação. Em seguida, abra Segurança de agentes para revisar ou definir políticas, ou confirme para ativar o acesso.

4. Peça aos usuários que atualizem o aplicativo ChatGPT para desktop para a versão 26.929 ou posterior. A atualização é necessária para que o acesso ao computador local funcione com o Work na nuvem.

5. Peça a um membro com as permissões desejadas que selecione Nuvem no editor do aplicativo para desktop e inicie uma nova tarefa. Peça a esse membro que continue a tarefa em outro dispositivo compatível e verifique se consegue acessar um arquivo local aprovado ou uma ferramenta local aprovada enquanto o computador estiver conectado.

dots

1. Como proprietário do espaço de trabalho, abra Console de administração > Permissões e ative os dots para os usuários desejados, observando os requisitos de elegibilidade acima.

2. Em Usar dots, ative Permitir acesso ao computador local. Leia a caixa de diálogo de confirmação. Em seguida, abra Segurança de agentes para revisar ou definir políticas, ou confirme para ativar o acesso.

3. Peça aos usuários que atualizem o aplicativo ChatGPT para desktop para a versão 26.929 ou posterior. A atualização é necessária para que o acesso ao computador local funcione.

4. Peça aos usuários que conectem o computador seguindo as instruções para usuários dos dots abaixo.

5. Peça a um membro com as permissões desejadas e um computador conectado que teste uma tarefa local com seu dot.

Confira a cobertura do OpenTelemetry e da auditoria

Ao avaliar a cobertura do OpenTelemetry (OTel) para o modo Work com acesso local e os dots, diferencie a telemetria de execução local dos registros de auditoria na nuvem. O executor local continua podendo exportar os eventos de execução compatíveis. Os eventos de orquestração na nuvem não chegam ao coletor OpenTelemetry existente.

Use a API de Compliance para obter os registros de nuvem compatíveis. Alterar o endpoint do coletor não restabelece o envio dos eventos de orquestração na nuvem. Os registros da API de Compliance não substituem todos os eventos do fluxo anterior do OpenTelemetry.

Para os dots, use a API de análise para consultar dados de uso e a API de Compliance para obter os registros de auditoria compatíveis. Valide os registros necessários para seu fluxo de trabalho e verifique também se os eventos chegam ao coletor local. Os hooks MCP não substituem a cobertura de auditoria.

Consulte Segurança do Work na nuvem para conferir a cobertura de auditoria na nuvem.

Experiência do usuário final

Tanto no modo Work quanto nos dots, as etapas locais exigem que o computador usado na tarefa esteja online e conectado. O aplicativo ChatGPT para desktop precisa estar em execução, com a sessão iniciada na conta e no espaço de trabalho corretos.

Modo Work

Os membros precisam usar a opção Entrar com o ChatGPT para acessar o espaço de trabalho desejado. Chaves de API e tokens de acesso do Codex não habilitam esse recurso. Compartilhe o guia Continue uma tarefa do modo Work em outro dispositivo para que os membros saibam como iniciar uma tarefa elegível e como continuá-la quando o computador estiver offline. Antes de desativar o recurso, consulte as instruções para reverter a configuração.

dots

• Conecte um computador. Abra os detalhes do dot no aplicativo ChatGPT para desktop e selecione Computadores. Localize Seu computador (ou o nome do computador), selecione Permitir e confirme em Permitir acesso. O computador ficará disponível para as tarefas locais compatíveis.

• Computador offline. A autorização de acesso fica salva, mas as tarefas que dependem desse computador não podem prosseguir enquanto ele estiver indisponível. O status Offline não significa que o acesso foi revogado.

• Remova o acesso. Selecione Revogar acesso e confirme para remover a autorização do dot para esse computador. O status Desconectado indica que o acesso foi removido. Ele é diferente do status Offline.

• Alterações de acesso pelo administrador. Se um administrador desativar o acesso ao computador local para os dots, uma tarefa local já autorizada pode ainda estar em fase de conclusão. No modo Work, os turnos em andamento são interrompidos imediatamente. Não presuma que os dots tenham o mesmo comportamento.

• Tarefas em andamento. Uma tarefa local em andamento não migra automaticamente para a nuvem. Alterações na conexão podem interromper o trabalho ou recarregar o ambiente de execução. O dot pode continuar as etapas seguintes em seu computador na nuvem. Porém, uma subtarefa local que perder o acesso não poderá ser retomada no computador local nem será transferida automaticamente para a nuvem.