Documentação do ChatGPT
Português
Contacto goolvyouyou@gmail.com

Agent Security

Gira políticas Global e definições de ambiente para o ChatGPT Work e o Codex

Utilize Agent Security na Consola de administração para gerir políticas e configuração. Substitui Políticas e configuração. A sua disponibilização é independente do acesso ao computador local para o Work e os dots.

Quando as políticas de nuvem antigas elegíveis são migradas, as suas definições são transferidas para Global, preservando as atribuições e a ordem das políticas. Reveja as políticas migradas em Agent Security. O acesso ao computador local requer uma ativação separada para o Work e para os dots.

Onde se aplicam as definições

Cada política começa com uma base Global. As substituições de ambiente alteram as definições de execução suportadas para Local ou Codex Cloud. Quando um ambiente não tem uma substituição, herda dessa política as definições Global aplicáveis.

  • Global: defina controlos do orquestrador, incluindo aprovações e pesquisa na Web, e definições de execução partilhadas.

  • Local: ajuste as definições de execução suportadas para trabalho executado num computador ligado.

  • Codex Cloud: ajuste as definições de execução suportadas para tarefas de nuvem do Codex. Pode configurar estas políticas antes de ativar o Codex Cloud, mas só se aplicam depois de ativar o Codex Cloud na página de permissões. O Work Cloud tem permissões de capacidades separadas, descritas em Como Agent Security se aplica ao Work Cloud.

Definir uma base e acrescentar definições de ambiente

  1. Abra Agent Security e reveja as políticas Global existentes, as atribuições e a ordem. Compare-as com os controlos pretendidos pela sua organização. Esta revisão não ativa o Acesso ao computador local com Work Cloud.

  2. Reveja Requisitos e Predefinições separadamente. Os Requisitos estabelecem limites que os utilizadores não podem substituir. As Predefinições estabelecem valores iniciais dentro desses limites.

  3. Mantenha os controlos do orquestrador em Global. Estes incluem requisitos de aprovação, modos de pesquisa na Web permitidos e controlos de ferramentas geridas.

  4. Acrescente definições de ambiente Local ou Codex Cloud para controlos de execução suportados, como isolamento em sandbox, permissões do sistema de ficheiros e rede de execução gerida. Utilize uma substituição específica do sistema operativo quando esse âmbito for necessário.

  5. Guarde a política e reveja quaisquer mensagens de validação sobre as definições introduzidas.

Escolher controlos e campos de configuração

O orquestrador coordena a tarefa. Um executor é o computador ou contentor de nuvem que executa um passo de execução. Configure os controlos do orquestrador em Global. As definições de ambiente requirements.toml suportam apenas controlos de execução. As definições do orquestrador, como a política de aprovação e a pesquisa na Web, permanecem em Global e não podem ser substituídas por um ambiente.

Controlos do orquestrador

Configure estes controlos em Global. Para o Work com acesso local e os dots, a política Global suportada aplica-se através do orquestrador de nuvem partilhado quando a política gerida está ativada. As substituições de ambiente aplicam-se às definições de execução suportadas e não podem substituir os controlos do orquestrador. Dos requisitos de aprovação, pesquisa na Web, aplicações, MCP, plugins e regras listados abaixo, apenas Políticas de aprovação permitidas e Modos de pesquisa na Web permitidos têm controlos dedicados na interface de Agent Security. Configure os outros campos através de TOML.

Controlo O que controla Campos de requirements.toml
Políticas de aprovação e revisão Quando o agente precisa de aprovação e quem a revê, incluindo a revisão automática. allowed_approval_policies
allowed_approvals_reviewers
auto_review
guardian_policy_config
Modos de pesquisa na Web Quais os modos de pesquisa na Web que o agente pode utilizar. allowed_web_search_modes
Aplicações, MCP servers e plugins Aplicações, MCP servers e plugins disponíveis e a respetiva configuração. apps
mcp_servers
plugins
rules de comandos Quais os comandos que o agente pode executar, quais exigem aprovação e quais não pode executar. rules
hooks geridos Ações definidas pelo administrador em eventos de tarefas e ferramentas suportados. hooks
allow_managed_hooks_only

Hooks no Acesso ao computador local com Work Cloud

Quando a política gerida e os hooks remotos estão ativados, o Work Cloud com acesso local e os dots utilizam hooks MCP remotos geridos pelo administrador no orquestrador de nuvem. Configure os processadores mcp_tool em requirements.toml de Global. O Work Cloud sem acesso local e as contas pessoais não utilizam estes hooks empresariais. Os processadores de comandos/shell, de prompts e de agentes; os hooks de configuração local, de plugins ou de diretórios locais; os hooks com âmbito de ambiente; e os hooks MCP SessionEnd não são suportados com 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 suportados existentes continuam a funcionar em conversas exclusivamente locais do Work e do Codex. Os administradores podem continuar a configurar hooks geridos suportados em Agent Security para esses fluxos de trabalho.

Antes de depender destes hooks, teste a conectividade de callback, os eventos necessários e o comportamento em caso de falha. Uma recusa explícita suportada pode bloquear uma ação, mas um erro de callback PreToolUse, um tempo limite excedido ou uma resposta malformada podem fazer o hook falhar sem bloquear a ferramenta. Os hooks MCP não fornecem um registo de auditoria completo da Compliance API.

Global também contém definições do computador e do cliente. Algumas destas definições aplicam-se apenas à aplicação para computador. Configurar uma definição em Global não significa que se aplique em todo o lado. Consulte a Referência de configuração para conhecer a utilização suportada de cada campo.

Controlos de execução (executor)

Estes campos controlam a forma como o trabalho é executado num computador ou num contentor de nuvem. Defina valores partilhados em Global. Utilize substituições Local ou Codex Cloud para definições suportadas que precisem de ser diferentes nesse ambiente.

Controlo O que controla Campos de requirements.toml
Utilização de shell de início de sessão Se as ferramentas de shell podem iniciar uma shell de início de sessão. allow_login_shell
Modos de sandbox permitidos Quais os modos de sandbox que o executor pode utilizar. allowed_sandbox_modes
Perfis de permissões e predefinições Perfis de permissões permitidos, os seus limites de acesso e o perfil predefinido. allowed_permission_profiles
default_permissions
permissions
Configuração de sandbox remota Modos de sandbox específicos do anfitrião, selecionados pelo nome do anfitrião. remote_sandbox_config
Rede de execução gerida Acesso à rede gerido, incluindo destinos permitidos e recusados. experimental_network
Definições de execução do Windows Definições de execução e de sandbox específicas da plataforma no Windows. windows

A tabela mostra quais os grupos de campos que suportam substituições de ambiente. As opções suportadas em cada grupo podem variar consoante a plataforma, e alguns requisitos combinam-se entre políticas em vez de se substituírem. Consulte a Referência de configuração para conhecer os valores suportados e Configuração gerida para conhecer as exceções de rede.

Nos percursos de execução gerida suportados do Codex Cloud, os requisitos de Agent Security limitam o acesso à rede dos comandos. As definições de Internet do ambiente Codex Cloud aplicam-se separadamente. Um domínio permitido em Agent Security não substitui uma restrição nas definições de Internet do ambiente Cloud. Estes controlos de rede dos comandos não desativam, por si só, a pesquisa na Web alojada, as aplicações ou o MCP. O ChatGPT Work Cloud tem permissões de capacidades separadas e não herda estes requisitos de Agent Security.

Uma lista gerida de comandos permitidos aplica-se aos comandos que utilizam o proxy gerido. Quando a política permite a elevação completa para fora da sandbox e esta é aprovada, essa execução pode contornar o proxy de comandos. Uma concessão restrita de acesso à rede é diferente de uma elevação completa para fora da sandbox. Configure requisitos obrigatórios de aprovação e de sandbox para o limite pretendido e teste tanto os comandos normais como os comandos com elevação.

Configurar a rede na interface

  1. Abra Consola de administração > Agent Security. Selecione uma política e escolha Global, Local ou Codex Cloud. Utilize Global para a base partilhada e uma substituição de ambiente para as diferenças suportadas.
  2. Abra Requisitos e ative Gerir rede. Acrescente as entradas de domínio necessárias e escolha Permitir ou Recusar para cada uma. Ative Permitir apenas domínios adicionados por administradores se a configuração normal dos utilizadores e as aprovações por domínio não puderem alargar a lista de permissões do proxy gerido.
  3. Reveja as definições efetivas e as regras herdadas antes de guardar. As definições de ambiente vazias herdam Global em vez de o limparem. Verifique separadamente a conectividade local/privada do Codex Cloud. Desativar Gerir rede não equivale a desativar o acesso à Internet do ambiente Cloud.
  4. Para o Codex Cloud, verifique também as definições de acesso à Internet, destino e método do ambiente. Guarde e teste um pedido que deva ser permitido e um pedido que deva ser bloqueado. Teste separadamente qualquer elevação completa para fora da sandbox que seja permitida.

Sem destinos permitidos efetivos

Quando Gerir rede e Permitir apenas domínios adicionados por administradores estão ativados, os comandos geridos normais precisam de destinos permitidos efetivos. Se não existirem entradas Permitir configuradas ou herdadas, esses comandos não têm destinos permitidos. Uma política apenas de recusa não permite implicitamente o resto da Internet. Acrescente as entradas Permitir necessárias e verifique as regras herdadas antes de guardar. Esta restrição aplica-se ao proxy de comandos gerido, não a todas as ferramentas nem a elevações completas aprovadas para fora da sandbox.

Conectividade local/privada do Codex Cloud

Um valor explicitamente desativado para a conectividade local/privada pode impedir o Codex Cloud de alcançar o seu proxy a montante, mesmo quando o domínio de destino é permitido. Verifique o valor final de allow_local_binding e identifique a política ou definição que o fornece. No percurso de proxy Cloud suportado, este valor é true por predefinição apenas quando nenhum requisito aplicável, perfil de rede selecionado ou definição de funcionalidade do proxy fornece um valor. Um false herdado continua a contar como definição explícita. Quando suportado, defina uma substituição Cloud de prioridade superior para alterar este valor para o Codex Cloud sem alterar o valor Global utilizado por Local. Isto não acrescenta entradas Permitir de domínio. Verifique o suporte do executor antes de depender da substituição. Não aplique esta predefinição Cloud a Local.

Predefinições de ambiente

O editor de Predefinições utiliza campos de config.toml, que são diferentes das restrições de requirements.toml. As predefinições de ambiente de nível superior suportadas são:

  • Comportamento da shell: allow_login_shell e shell_environment_policy.

  • Sandbox e permissões: sandbox_mode, sandbox_workspace_write, default_permissions e permissions.

  • Execução do Windows: windows.

Uma predefinição não substitui um requisito obrigatório. Mantenha as predefinições do orquestrador, incluindo as definições de aprovação e pesquisa na Web, em Global.

Compreender como as políticas se combinam

  • Entre políticas, uma política de prioridade superior prevalece sobre uma de prioridade inferior, mesmo quando a política de prioridade inferior é mais específica.

  • Dentro de uma política, as definições de execução suportadas são resolvidas por esta ordem: uma substituição de ambiente específica do sistema operativo, uma substituição de ambiente para todos os sistemas operativos e, por fim, Global.

  • Para a execução local, MDM e os requisitos antigos de dispositivos geridos têm precedência sobre Agent Security. O ficheiro de requisitos de sistema do dispositivo tem prioridade inferior à de Agent Security.

Para a mesma regra de domínio dentro de uma política, uma substituição de ambiente do administrador pode permitir um domínio recusado em Global ou recusar um domínio permitido em Global. Sem uma substituição de ambiente, a regra Global é herdada. Outras regras Recusar efetivas ou controlos de acesso podem continuar a bloquear um pedido.

Estes resultados comparam a mesma chave de domínio dentro de uma política, sem que uma política de prioridade superior altere o resultado. Um valor de prioridade superior substitui a mesma chave. As outras chaves herdadas permanecem. Uma regra Permitir não contorna outra regra Recusar correspondente, como um caráter universal herdado. Um mapa de ambiente vazio não limpa as regras herdadas.

Como Agent Security se aplica ao Work Cloud

Configure Utilização do navegador na nuvem e Acesso à rede na nuvem em Consola de administração > Permissões e funções > Capacidades do espaço de trabalho > Capacidades do computador na nuvem. Estas capacidades partilhadas estão disponíveis para o Work Cloud e os dots e podem ser configuradas independentemente do acesso ao Work Cloud. Uma tarefa do Work continua a precisar de acesso ao Work e de permissão para utilizar cada capacidade de que necessita. Reveja separadamente o acesso ao navegador e o acesso à rede do código ou da shell. Desativar um não desativa automaticamente o outro.

Os contentores do Work Cloud e os computadores na nuvem dos dots utilizam a sua própria configuração e os seus próprios requisitos de execução, em vez do conjunto de definições de ambiente gerido utilizado por outros tipos de executor. As restrições locais de ficheiros e rede não se aplicam automaticamente a estes computadores na nuvem. A política Global suportada do orquestrador tem um âmbito separado. Uma política Global ou uma substituição Codex Cloud não configura as permissões de capacidades de nuvem partilhadas. Reveja essas permissões separadamente.

Verifique a predefinição do espaço de trabalho, todas as funções atribuídas diretamente e por grupo e as restrições impostas separadamente, como o Lockdown Mode, ao verificar o acesso efetivo de um membro.

Antes de ativar Permitir acesso ao computador local em Work Cloud, reveja a base Global e verifique a compatibilidade com os controlos de que a sua organização depende. Utilizar o Codex localmente na aplicação ChatGPT para computador não é um pré-requisito. Se enforce_residency estiver ativado em qualquer política de nuvem, Permitir acesso ao computador local fica desativado tanto para o Work como para os dots. Esta salvaguarda não configura a residência do espaço de trabalho nem, por si só, desativa o Work Cloud ou os dots. Reveja Acesso ao computador local para o Work Cloud e os dots para conhecer os passos de configuração separados, a elegibilidade e o comportamento da ligação.

API de políticas e Terraform

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

A migração de políticas não altera a sincronização de membros SCIM nem as funções RBAC.

Guias relacionados