Guia prático de segurança do Codex

Utilize este procedimento quando os colaboradores devam iniciar sessão no Codex através do espaço de trabalho do ChatGPT da empresa, sendo proibidas as contas pessoais do ChatGPT e a autenticação por API key nos dispositivos geridos.

Resultado pretendido

Nos dispositivos geridos pela empresa, o Codex aceita apenas o início de sessão do ChatGPT no espaço de trabalho do ChatGPT da empresa.

Pré-requisitos

• O UUID do espaço de trabalho do ChatGPT Enterprise aprovado.

• Uma forma de distribuir a configuração gerida do Codex aos dispositivos.

• Uma decisão de proibir a autenticação por API key nos dispositivos geridos.

Configurar

1. Registe o UUID do espaço de trabalho aprovado no seu repositório de configuração interno.

2. Adicione requisitos de autenticação obrigatórios ao requirements.toml local:

   allowed_login_methods = ["chatgpt"]
   allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]

A primeira chave permite apenas a autenticação do ChatGPT; a segunda restringe o início de sessão ao espaço de trabalho aprovado. Substitua o UUID ilustrativo pelo UUID do seu espaço de trabalho. Consulte a referência de requisitos.

3. Implemente através de requirements.toml local ou de requisitos de MDM do macOS, utilizando os caminhos indicados em Onde colocar a configuração. Estes requisitos de autenticação aplicam-se antes do carregamento das credenciais e da obtenção da política da cloud; o Codex ignora-os nos requisitos geridos na cloud. Proteja o ficheiro e o respetivo diretório principal contra alterações pelo utilizador. As predefinições legadas de managed_config.toml não impõem esta restrição.

4. Durante o piloto, termine as sessões dos utilizadores ou remova as sessões pessoais do Codex guardadas anteriormente. Não pressuponha que uma nova política invalida retroativamente uma sessão existente.

5. Combine a restrição de início de sessão com funções do espaço de trabalho e acesso por grupos. A autenticação controla que identidade inicia sessão; o RBAC controla que funcionalidades do Codex essa identidade pode utilizar. Consulte Autenticação.

Verificar

• Termine a sessão no Codex.

• Tente iniciar sessão com uma conta pessoal do ChatGPT. Resultado esperado: o início de sessão no espaço de trabalho pessoal é rejeitado.

• Tente iniciar sessão no Codex por API key. Resultado esperado: o início de sessão por API key é rejeitado.

• Inicie sessão no espaço de trabalho aprovado com a conta empresarial. Resultado esperado: o início de sessão é bem-sucedido.

• Reinicie a aplicação de ambiente de trabalho, a CLI e a extensão para IDE e, em seguida, repita.

Reverter

Restaure os requisitos de autenticação locais anteriores e volte a implementar o pacote revisto.

Limites

Este controlo aplica-se aos clientes Codex geridos em dispositivos geridos. Combine-o com controlos de aplicações nos dispositivos e uma política de rede se o requisito for «nenhuma utilização pessoal do Codex a partir de recursos empresariais».

Utilize este procedimento quando os programadores precisem de acesso só de leitura ou limitado ao espaço de trabalho e pretenda impedi-los de selecionar Acesso total ou de contornar as aprovações e o isolamento em sandbox com --yolo.

Resultado pretendido

Os utilizadores só podem selecionar perfis aprovados de acesso só de leitura ou limitado ao espaço de trabalho. Não podem selecionar danger-full-access, approval_policy = "never" ou --yolo.

Configurar

1. Defina um perfil de espaço de trabalho aprovado:

   [permissions.corp-workspace]
   description = "Company workspace access with no unrestricted host access."
   extends = ":workspace"

2. Imponha os perfis e as políticas de aprovação permitidos:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]
   default_permissions = "corp-workspace"

   [allowed_permission_profiles]
   ":read-only" = true
   "corp-workspace" = true
   ":danger-full-access" = false

A lista de permissões é exaustiva: os perfis omitidos da lista ou definidos como false são recusados, incluindo os perfis adicionados em versões futuras. Consulte a Referência de configuração.

3. Para clientes legados que ainda utilizam sandbox_mode, utilize:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_sandbox_modes = ["read-only", "workspace-write"]

4. Distribua esta configuração como requisitos impostos pelo administrador, e não como um ficheiro de configuração editável pelo utilizador.

5. Se posteriormente permitir a Revisão automática, adicione-a deliberadamente após os testes. A Revisão automática altera quem analisa uma transposição de limites; não restabelece um limite removido. Consulte Revisão automática.

Verificar

• Abra o seletor de permissões. Resultado esperado: Acesso total está indisponível ou é rejeitado.

• Inicie com --dangerously-bypass-approvals-and-sandbox. Resultado esperado: o Codex rejeita o arranque ou impõe um perfil compatível.

• Inicie com --sandbox danger-full-access --ask-for-approval never. Resultado esperado: o arranque é rejeitado.

• Execute uma tarefa normal no espaço de trabalho. Resultado esperado: a tarefa é concluída com êxito; as transposições de limites continuam a exigir aprovação.

Reverter

Restaure o pacote de requisitos anterior. Mantenha o acesso irrestrito bloqueado, salvo se existir uma exceção aprovada separadamente.

Limites

Este controlo aplica-se às permissões de execução do Codex. Não retira os privilégios a uma conta privilegiada do sistema operativo.

Utilize este procedimento quando a sua organização precisar de decidir que MCP servers o Codex pode utilizar e de impor uma lista aprovada.

Permitir um servidor e configurá-lo são passos distintos. Uma entrada na lista de permissões permite um servidor correspondente; não cria a configuração do servidor. Configure o servidor separadamente com o nome e a identidade correspondentes, bem como a autenticação de que necessita.

Resultado pretendido

O Codex ativa apenas MCP servers cujo nome e identidade configurados correspondam à lista aprovada pela empresa.

Configurar

1. Faça um inventário de cada servidor aprovado: responsável, finalidade, transporte, executável ou URL exato, autenticação, classificação dos dados e ferramentas com capacidade de escrita.

2. Comece por recusar tudo. Uma tabela gerida vazia desativa todos os MCP servers:

   [mcp_servers]

3. Adicione servidores HTTP aprovados pelo URL exato:

   [mcp_servers.internal_docs]
   identity = { url = "https://mcp.example.com/docs" }

4. Adicione servidores stdio aprovados pelo executável e pelos argumentos posicionais:

   [mcp_servers.internal_build.identity]
   command = { executable = "/usr/local/bin/company-mcp", args = [
     { match = "exact", value = "serve" },
     { match = "prefix", value = "--workspace=" },
   ] }

O mecanismo de correspondência estruturada verifica o executável, o número de argumentos e a ordem dos argumentos. Não restringe cwd, env ou env_vars. Considere o controlo de todo o contexto de arranque um pré-requisito para aprovar um servidor stdio: proteja o executável e as respetivas dependências e impeça que configurações não fidedignas do utilizador ou do projeto forneçam um diretório de trabalho ou um ambiente que possa alterar o seu comportamento. Se não conseguir impor esse limite de forma independente, mantenha o servidor stdio por aprovar e utilize antes um servidor HTTP revisto.

5. Adicione separadamente as identidades MCP incluídas em plugins em plugins.<plugin>.mcp_servers.<server>.

6. Guarde a lista aprovada num repositório de configuração sujeito a revisão e implemente-a através de requisitos impostos pelo administrador.

O cliente só ativa um servidor quando tanto o nome como a identidade correspondem a uma entrada aprovada. Consulte Configuração gerida.

Verificar

• Configure o servidor aprovado exatamente como definido. Resultado esperado: o servidor inicia.

• Altere um caráter do URL. Resultado esperado: o servidor é desativado.

• Altere o número ou a ordem dos argumentos stdio, ou forneça um argumento fora das regras de argumentos configuradas. Resultado esperado: o servidor é desativado. Os valores que continuem a satisfazer um prefixo permitido continuam a ser permitidos.

• Num projeto fidedigno descartável, experimente substituições inofensivas de cwd, env e env_vars, mantendo o executável e os argumentos correspondentes. A correspondência de identidade, por si só, não rejeita estas substituições. Verifique se o seu controlo independente do contexto de arranque rejeita substituições inseguras ou se o servidor stdio continua por aprovar; não utilize uma carga de injeção real.

• Adicione um nome não aprovado. Resultado esperado: o servidor é desativado.

• Teste um servidor incluído num plugin. Resultado esperado: o servidor só funciona com a identidade aprovada.

Reverter

Remova a entrada recém-adicionada. Para interromper imediatamente toda a utilização de MCP, implemente uma tabela mcp_servers vazia.

Limites

A inclusão de identidades numa lista de permissões não prova que as ferramentas, os dados a montante, as credenciais ou o ambiente de arranque de um servidor são seguros. Os processos MCP stdio locais são executados fora da sandbox de comandos local; a correspondência de um executável e dos argumentos não restringe o acesso do servidor nem impede o carregamento de código baseado no ambiente. Analise de forma independente todo o contexto de arranque e as permissões do servidor. Consulte Requisitos de identidade MCP.

Utilize este procedimento quando a sua equipa de segurança precisar de compreender o que o Codex está a fazer nos dispositivos e na sua rede. Reúne eventos de execução e de ferramentas, decisões de aprovação, registos de auditoria do espaço de trabalho e registos de rede para investigação.

Resultado pretendido

As equipas de segurança conseguem correlacionar execuções do Codex, decisões sobre ferramentas, aprovações, registos de auditoria do espaço de trabalho e tráfego de saída real da rede, sem depender da narrativa do próprio modelo.

Utilize quatro fontes de evidência

1. OpenTelemetry do Codex: eventos de execução, API, modelo, sandbox, aprovação e ferramentas.

2. Hooks geridos do ciclo de vida: registos no dispositivo relativos à utilização de ferramentas e aos pedidos de permissão.

3. Registos do proxy ou gateway de rede: destinos DNS/HTTP reais e resultados das ligações.

4. Compliance API: registos de auditoria e investigação ao nível do espaço de trabalho.

Nenhuma fonte, por si só, proporciona uma monitorização completa da rede.

Configurar

1. Envie os registos OpenTelemetry do Codex para o seu coletor, com os prompts em bruto ocultados:

   [otel]
   environment = "enterprise"
   log_user_prompt = false

   [otel.exporter.otlp-http]
   endpoint = "https://otel.example.com/v1/logs"
   protocol = "binary"
   headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }

Forneça OTLP_TOKEN ao processo do Codex através do seu gestor de segredos aprovado ou do ambiente do processo antes de iniciar o cliente. Mantenha o token fora dos ficheiros TOML implementados e do controlo de versões.

O Codex pode emitir inícios de conversas, pedidos à API, eventos de streaming, metadados de prompts, decisões sobre ferramentas e resultados de ferramentas. Consulte Configuração avançada.

2. Implemente o OTel fora da configuração local do projeto. Os ficheiros .codex/config.toml do projeto não podem substituir o encaminhamento da telemetria.

3. Adicione hooks geridos do ciclo de vida para SessionStart, PreToolUse, PermissionRequest, PostToolUse, Stop e SessionEnd.

4. Instale os scripts dos hooks num diretório gerido pelo administrador e defina allow_managed_hooks_only = true se os hooks do utilizador, do projeto e dos plugins devam ser ignorados.

5. Encaminhe o tráfego dos comandos executados em sandbox através de um proxy com registo independente. O OTel regista que uma ferramenta foi executada; o proxy regista os destinos aos quais o subprocesso tentou ligar-se.

6. Configure telemetria separada para a pesquisa na Web, aplicações, conectores, MCP servers, atividade do navegador e Codex Cloud. As regras do proxy de comandos local não os abrangem automaticamente.

7. Transmita os registos suportados da Compliance API para o SIEM e aplique os seus próprios controlos de retenção e preservação legal. Consulte Compliance API e eventos de auditoria.

8. Correlacione o utilizador ou a conta de serviço, o anfitrião ou executor, o ID da conversa, o modelo, a versão do cliente, o perfil de permissões, a decisão de aprovação, o destino e o nome da ferramenta.

Verificar

Execute uma sessão controlada que faça o seguinte:

• Leia um ficheiro permitido.

• Tente ler um ficheiro bloqueado.

• Execute um comando permitido.

• Tente efetuar um pedido de saída bloqueado.

• Peça aprovação e receba uma recusa.

• Termine a sessão.

Resultados esperados por fonte de evidência:

• O OTel mostra eventos de execução e de ferramentas.

• Os hooks mostram o ciclo de vida da sessão.

• Os registos do proxy mostram destinos permitidos e bloqueados.

• A ingestão da Compliance recebe os registos suportados.

• O SIEM correlaciona esses registos com o utilizador ou a carga de trabalho.

Reverter

Desative o exportador e os hooks restaurando a configuração anterior. Não remova o registo independente do proxy como parte de uma reversão da telemetria.

Limites

Não prometa que a telemetria do Codex capta todos os argumentos de comandos, bytes de saída ou pacotes de rede. Documente a cobertura de cada camada.

Utilize este procedimento quando o Codex não deva ter acesso à Internet ou deva aceder apenas a destinos aprovados. Escolha o procedimento local ou da cloud consoante o ambiente que está a configurar e tenha em conta os âmbitos distintos das respetivas políticas.

Resultado pretendido

O Codex não tem acesso à Internet ou acede apenas a domínios aprovados, de acordo com a configuração escolhida. Os ambientes Codex Cloud (Legacy) podem também restringir os métodos HTTP.

Configurar o Codex Cloud atual

1. Crie ambientes separados para diferentes níveis de confiança, como no-internet-review, approved-dependencies-build e cyber-lab.

2. Na configuração do ambiente, mantenha Permitir que o Codex aceda à Internet desativado, salvo se o fluxo de trabalho necessitar de acesso à Internet.

3. Quando o acesso for necessário, ative Permitir que o Codex aceda à Internet. Em Permitir domínios, escolha Apenas domínios personalizados e adicione os anfitriões exatos necessários em Domínios adicionais permitidos.

4. Guarde e teste os serviços durante a configuração inicial. Publique ou volte a publicar o ambiente e, em seguida, teste o acesso a destinos aprovados e não aprovados numa nova tarefa. Analise os scripts de configuração inicial separadamente: fixe as versões das dependências, prefira espelhos aprovados e evite transferências de executáveis que não tenham sido revistas.

Consulte Ligar a serviços. As definições atuais do Codex Cloud não disponibilizam o seletor de métodos HTTP da versão Legacy.

Configurar o Codex Cloud (Legacy)

1. Mantenha o acesso do agente à Internet Desativado quando não for necessário. O Legacy Cloud bloqueia a Internet durante a fase do agente por predefinição; os scripts de configuração inicial continuam a ser executados com acesso à Internet para instalar dependências.

2. Quando o acesso do agente for necessário, coloque-o em Ativado com uma lista de permissões restrita. Comece por Nenhum e adicione os domínios exatos.

3. Para fluxos de trabalho apenas de transferência, permita apenas GET, HEAD e OPTIONS. Isto bloqueia POST, PUT, PATCH, DELETE e outros métodos. Analise os scripts de configuração inicial separadamente, porque a restrição da fase do agente não rege o respetivo acesso à Internet.

Consulte Acesso do agente à Internet na versão Legacy. Estas predefinições e controlos de métodos HTTP aplicam-se apenas ao Legacy Cloud.

Configurar o Codex local

1. No requirements.toml gerido pelo administrador, defina e selecione o perfil de rede aprovado e restrinja os utilizadores a esse perfil:

   default_permissions = "corp-build"

   [allowed_permission_profiles]
   "corp-build" = true

   [permissions.corp-build]
   description = "Workspace access with approved dependency destinations."
   extends = ":workspace"

   [permissions.corp-build.network]
   enabled = true
   allow_local_binding = false

   [permissions.corp-build.network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

2. Implemente o pacote de requisitos revisto utilizando Configuração gerida. Um perfil com nome, por si só, está inativo; default_permissions seleciona-o e a lista de permissões impede a seleção de outros perfis.

3. Ative o proxy gerido pelo administrador no mesmo pacote de requisitos, para que as restrições de domínios sejam impostas e os utilizadores não as possam alargar. Implemente o proxy e o perfil com rede ativada em conjunto; um perfil com rede ativada sem um proxy ativo concede acesso direto à rede sem impor as suas regras de domínios:

   Atenção: [experimental_network] é experimental e pode mudar. Valide-o em cada versão suportada do cliente local e em cada sistema operativo antes de uma implementação mais alargada. O suporte para Windows é limitado; não aplique esta política aos utilizadores de Windows antes de testar a sua aplicação efetiva no seu ambiente.

   [experimental_network]
   enabled = true
   managed_allowed_domains_only = true

   [experimental_network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

4. Mantenha a vinculação a portas locais desativada, salvo se o fluxo de trabalho precisar dela. Configure separadamente o acesso a destinos de rede privada; permitir um domínio não aprova, por si só, os respetivos endereços privados. Consulte Requisitos de acesso à rede.

5. Configure separadamente a pesquisa na Web, aplicações, MCP servers, atividade do navegador e Codex Cloud. As regras da sandbox local não os controlam.

Verificar

• Envie um pedido para um domínio aprovado e confirme que é bem-sucedido.

• Envie um pedido para um domínio não aprovado e confirme que é bloqueado.

• Envie pedidos para localhost, um IP privado e um endpoint de metadados da cloud. Confirme que cada pedido é bloqueado, salvo aprovação explícita.

• No Codex Cloud (Legacy), tente efetuar um pedido POST para um domínio permitido. Confirme que o pedido é bloqueado quando apenas GET, HEAD e OPTIONS são permitidos.

• Confirme que os registos do proxy ou gateway contêm entradas tanto para pedidos permitidos como para pedidos recusados.

Reverter

Volte a colocar o ambiente em Desativado ou restaure a política de domínios anterior. Evite reverter para acesso irrestrito à Internet.

Limites

Uma elevação aprovada para acesso total fora da sandbox pode contornar o proxy de comandos local. Teste separadamente os comandos normais executados em sandbox e os comandos com elevação aprovada antes de confiar na restrição.

Um domínio permitido pode, ainda assim, alojar injeção de prompts, pacotes comprometidos ou documentação insegura.

Utilize este procedimento quando o Codex precisar de acesso a diretórios de código-fonte aprovados, enquanto os segredos, os ficheiros .env, as chaves SSH e os repositórios não relacionados devem permanecer inacessíveis. Abrange a restrição do acesso a ficheiros e a redução do número de variáveis de ambiente que contêm credenciais transmitidas aos comandos iniciados.

Resultado pretendido

O Codex pode trabalhar em diretórios de código-fonte aprovados, mas não pode ler ficheiros comuns que contêm segredos nem herdar um conjunto alargado de variáveis de ambiente que contêm credenciais.

Configurar

1. Defina padrões de recusa de leitura num perfil de espaço de trabalho:

   [permissions.corp-workspace]
   description = "Workspace edits with secret-bearing paths denied."
   extends = ":workspace"

   [permissions.corp-workspace.filesystem]
   glob_scan_max_depth = 6

   [permissions.corp-workspace.filesystem.":workspace_roots"]
   "**/.env*" = "deny"
   "**/*.pem" = "deny"
   "**/*.p12" = "deny"
   "**/id_*" = "deny"
   "**/.aws/**" = "deny"
   "**/.kube/**" = "deny"

2. Adicione caminhos exatos de recusa para diretórios de credenciais conhecidos, chaves de assinatura, configuração de produção e repositórios vizinhos.

3. No /etc/codex/config.toml do sistema ou no ~/.codex/config.toml do utilizador, reduza as variáveis de ambiente transmitidas aos comandos iniciados:

   [shell_environment_policy]
   inherit = "core"
   ignore_default_excludes = false

   [shell_environment_policy.filters]
   "AWS_*" = "exclude"
   "AZURE_*" = "exclude"
   "GITHUB_*" = "exclude"
   "*_TOKEN" = "exclude"
   "*_SECRET" = "exclude"
   "*_PASSWORD" = "exclude"

Esta é uma predefinição configurável pelo utilizador, não um requisito obrigatório. Reduz as variáveis herdadas, mas não impede o acesso a ficheiros de credenciais, utilitários auxiliares, conteúdo de arranque da shell ou outras identidades. Consulte Configuração avançada.

4. No requirements.toml gerido pelo administrador, selecione o perfil restrito e permita apenas esse perfil. Os perfis integrados não herdam as suas recusas de acesso a ficheiros de segredos:

   default_permissions = "corp-workspace"

   [allowed_permission_profiles]
   "corp-workspace" = true
   ":danger-full-access" = false

5. Escolha o fluxo de credenciais para o seu ambiente Cloud:

   • No Codex Cloud atual, utilize Segredos de rede para credenciais enviadas para um serviço HTTPS permitido. Os programas recebem um marcador de posição e o proxy substitui-o pelo valor real para destinos aprovados na porta 443 durante a configuração inicial e as tarefas. A credencial em bruto não é colocada num processo ou ficheiro local. As variáveis de ambiente diretas estão disponíveis para os programas. Consulte Variáveis de ambiente e segredos de rede.
   • No Codex Cloud (Legacy), os segredos suportam a autenticação durante a configuração inicial e são removidos antes da fase do agente; as variáveis de ambiente permanecem durante toda a conversa. Consulte Ambientes Cloud legados.

6. Se o agente precisar de autenticação, utilize um intermediário independente para fornecer credenciais de curta duração limitadas ao destino e à ação exatos. Consulte Configuração recomendada.

Verificar

Crie ficheiros de teste inofensivos:

.env.test
test-key.pem
.aws/credentials
.kube/config

Em seguida, peça ao Codex para:

• Ler um ficheiro normal.

• Ler cada ficheiro de teste.

• Procurar segredos recursivamente.

• Apresentar o ambiente dos seus comandos.

• Ler um repositório vizinho.

Resultado esperado: a leitura de um ficheiro normal é bem-sucedida; os ficheiros cujo acesso é recusado e os repositórios vizinhos permanecem inacessíveis e as variáveis excluídas estão ausentes do ambiente dos comandos.

Reverter

Restaure o perfil anterior, mas mantenha as recusas de acesso a ficheiros de segredos de elevada confiança enquanto investiga falhas nos fluxos de trabalho.

Limites

As recusas de acesso ao sistema de ficheiros não removem segredos já colados em prompts, incluídos em código-fonte legível no controlo de versões, devolvidos por conectores ou escritos em registos acessíveis ao modelo.

Utilize este procedimento quando ações como git push, implementações, migrações de bases de dados e comandos de CLI da cloud precisarem de aprovação antes de serem executadas. Decida que comandos devem solicitar revisão e quais devem ser proibidos e, em seguida, configure regras para esses comandos.

Resultado pretendido

Os comandos sensíveis são sempre suspensos para aprovação ou proibidos, mesmo quando o modelo considera que são adequados.

Configurar

1. Decida que comandos exigem um pedido de aprovação e quais são proibidos.

2. Adicione regras de comandos impostas pelo administrador:

   [rules]
   prefix_rules = [
     { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating shared Git state." },
     { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Require review before infrastructure changes." },
     { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Require review before Kubernetes changes." },
     { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Destructive removal is not permitted in managed Codex workflows." },
   ]

As regras de requisitos podem exigir um pedido de aprovação ou proibir um comando; não podem permitir um comando. Consulte Configuração gerida.

3. Para perfis de alto risco, adicione uma entrada para wrappers de shell ao mesmo array prefix_rules quando os wrappers puderem ocultar um comando sensível:

   { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Review shell wrappers that could obscure sensitive commands." },

A entrada para wrappers de shell gera muitos pedidos; utilize-a seletivamente.

4. Se uma pessoa tiver de aprovar os comandos, imponha estas definições:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]

A Revisão automática altera quem faz a revisão; não é uma garantia de segurança determinística. Consulte Revisão automática.

5. Envie eventos PermissionRequest, de decisão sobre ferramentas e de resultados de ferramentas para o pipeline de segurança.

Verificar

• Execute git status. Resultado esperado: não aparece nenhum pedido de aprovação.

• Execute git push. Resultado esperado: aparece um pedido de aprovação.

• Execute terraform apply. Resultado esperado: aparece um pedido de aprovação.

• Execute kubectl delete pod test. Resultado esperado: aparece um pedido de aprovação.

• Execute rm -rf test-directory. Resultado esperado: o comando é proibido.

• Recuse um pedido de aprovação. Resultado esperado: o comando não é executado e a recusa é registada.

• Reinicie o cliente e repita as verificações. Resultado esperado: a regra continua a ser imposta.

Reverter

Restaure o pacote de requisitos anterior. Restrinja um padrão de tokens demasiado abrangente em vez de remover uma classe inteira de comandos sensíveis.

Limites

As regras de prefixos não são um motor completo de políticas do sistema operativo. Combine-as com isolamento em sandbox, contas do SO com privilégios mínimos, restrições de rede, IAM da cloud, proteção de ramos, aprovações de implementação e autorização de bases de dados.

Utiliza estes procedimentos de configuração: Restringir os perfis de permissões e o Acesso total; Proteger segredos e repositórios não relacionados; Exigir aprovação para comandos sensíveis.

Os programadores têm acesso legítimo à produção, mas pretende que o Codex ajude no desenvolvimento sem efetuar alterações de produção não revistas.

• Defina um perfil de espaço de trabalho aprovado e imponha os perfis e as políticas de aprovação permitidos. Distribua estas definições como requisitos impostos pelo administrador para impedir que os utilizadores as substituam.

• Execute o Codex com uma identidade separada, com menos privilégios, ou num ambiente que não possa aceder a credenciais de escrita em produção nem obtê-las. Os programadores podem manter o acesso à produção através de um fluxo de trabalho autorizado separado.

• Minimize as variáveis de ambiente transmitidas aos comandos iniciados. Se o agente precisar de autenticação, utilize um intermediário independente para fornecer credenciais de curta duração limitadas ao destino e à ação exatos.

• Decida que comandos exigem um pedido de aprovação e quais são proibidos. Exija que uma pessoa aprove os comandos selecionados de elevado impacto, como git push, terraform apply, alterações do Kubernetes e migrações de bases de dados; proíba os comandos que nunca devem ser executados.

• Mantenha a aplicação do IAM de produção, da proteção de ramos e das aprovações de implementação independente do Codex.

Restringir os perfis de permissões e exigir revisão humana

No requirements.toml gerido pelo administrador, permita os perfis integrados de espaço de trabalho e de acesso só de leitura e exija a revisão do utilizador para ações que necessitem de aprovação:

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

O perfil de espaço de trabalho permite trabalhar no espaço de trabalho dentro da respetiva sandbox; o perfil de acesso só de leitura está disponível para trabalho mais restrito. Os perfis de acesso total não estão na lista de permissões.

Defina approval_policy = "on-request" na configuração do cliente se este precisar de uma escolha compatível explícita. on-request permite um pedido de aprovação quando necessário; não o solicita para todos os comandos. Adicione regras explícitas para as ações que necessitam de revisão e mantenha a autorização de produção independente.

As listas geridas de perfis permitidos exigem o Codex 0.138.0 ou posterior; para clientes mais antigos, utilize e teste os requisitos documentados do modo sandbox legado.

Reinicie cada cliente piloto, verifique se o perfil aprovado funciona e se um perfil de acesso total não permitido é rejeitado.

Separar a identidade do Codex das credenciais de produção

No seu sistema de gestão de dispositivos ou de aprovisionamento de ambientes de desenvolvimento, crie um utilizador, um contentor ou um anfitrião de desenvolvimento dedicado ao Codex, com acesso apenas ao código-fonte e aos serviços de desenvolvimento de que necessita. Não monte nesse ambiente os ficheiros de credenciais de produção, os utilitários auxiliares de tokens ou os porta-chaves do programador e impeça a identidade de adquirir funções de escrita em produção.

Se o agente precisar de acesso a serviços, configure o intermediário de credenciais da sua organização para emitir credenciais de curta duração restritas ao recurso e à ação de desenvolvimento. O programador pode utilizar a sua identidade normal através de um fluxo de trabalho de produção autorizado separado.

Por exemplo, no AWS IAM, abra Funções, selecione a função de desenvolvimento do Codex e, em Permissões, adicione uma política inline revista como esta, substituindo a conta e a função pelas suas:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAssumeExampleProductionRole",
      "Effect": "Deny",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::111122223333:role/ExampleProductionRole"
    }
  ]
}

Este exemplo recusa tentativas de assumir a função indicada, mas não recusa tentativas de assumir outras funções. Remova também as permissões diretas de produção, restrinja outras funções de produção e fontes de credenciais e reveja as políticas de confiança e os controlos ao nível da organização.

Teste a função de desenvolvimento com permissões representativas de desenvolvimento e produção sem efetuar alterações em produção. Consulte Exemplos de políticas de funções do AWS IAM.

Minimize o ambiente da shell

Em /etc/codex/config.toml para uma configuração inicial ao nível do sistema, ou em ~/.codex/config.toml para um utilizador, configure as variáveis de ambiente que os comandos iniciados herdam:

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

Esta é uma predefinição configurável, não uma barreira de proteção de credenciais imposta. As definições do utilizador, a inicialização ou os snapshots da shell, os auxiliares de credenciais e outras fontes de credenciais podem continuar a expor credenciais.

Em requirements.toml, utilize as seguintes restrições opcionais para desativar as shells de início de sessão e os snapshots da shell, se forem compatíveis com o seu fluxo de trabalho:

allow_login_shell = false

[features]
shell_snapshot = false

Teste estas definições num projeto-piloto, porque alguns fluxos de trabalho dependem da inicialização da shell de início de sessão.

Inicie o Codex com variáveis sintéticas inofensivas que correspondam aos filtros e inspecione o ambiente de um comando iniciado; verifique também se um pedido de shell de início de sessão é rejeitado quando esta está desativada. Verifique de forma independente se a identidade de execução não consegue aceder a credenciais reais de produção. Consulte Política de ambiente da shell.

Solicite aprovação para determinados comandos de elevado impacto

Adicione regras de requisitos para os comandos utilizados pela sua organização. Por exemplo:

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
  { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Review infrastructure changes." },
  { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Review cluster changes." },
  { pattern = [{ token = "python3" }, { token = "manage.py" }, { token = "migrate" }], decision = "prompt", justification = "Review database migrations." },
]

Utilize forbidden para um comando que nunca deve ser executado; substitua ou adicione padrões para as ferramentas de implementação e migração efetivamente utilizadas.

Estas regras correspondem a prefixos de comandos e não abrangem todas as ações equivalentes. Teste separadamente caminhos absolutos, wrappers, ordens alternativas de argumentos, outros clientes e outras ferramentas.

Num destino descartável, execute um comando normal, solicite uma ação da lista, recuse o pedido de aprovação e verifique se a ação não foi executada. Consulte Aplicação de regras de comandos.

Imponha aprovações de repositórios e implementações fora do Codex

Na sua plataforma de controlo de versões, proteja os ramos de produção, como main: exija alterações revistas e as aprovações e verificações de estado necessárias, e reveja quais as funções que podem contornar esses requisitos. Configure a aprovação de implementações no sistema de implementação relevante e os privilégios de base de dados na própria base de dados.

Utilize um repositório descartável para verificar se uma alteração revista funciona e se um push direto não autorizado é rejeitado. Estes controlos aplicam-se independentemente de a ação ter sido solicitada através do Codex.

Verifique

Num destino de teste descartável:

• Execute uma tarefa normal no espaço de trabalho. Resultado esperado: a tarefa é concluída com êxito.

• Tente executar um comando sensível representativo e recuse o pedido de aprovação. Resultado esperado: o comando recusado não é executado.

• Verifique se a identidade do Codex não consegue obter acesso de escrita em produção.

• Reinicie o cliente e repita.

Limites

As regras de prefixos não constituem um motor completo de políticas do sistema operativo. Combine-as com isolamento em sandbox, contas do sistema operativo com privilégios mínimos, restrições de rede, IAM da nuvem, proteção de ramos, aprovações de implementações e autorização da base de dados.

Utiliza estes procedimentos de configuração: Proteger segredos e repositórios não relacionados; Restringir destinos de rede; Permitir apenas MCP servers aprovados; Exigir aprovação para comandos sensíveis.

Os programadores utilizam o Codex com repositórios internos, e pretende reduzir o risco de o código ser enviado para um repositório público, um fragmento de código público ou outro destino não aprovado.

• Adicione caminhos exatos de acesso negado para diretórios de credenciais conhecidos e repositórios não relacionados, e minimize as variáveis de ambiente transmitidas aos comandos iniciados.

• Quando o agente necessitar de acesso à Internet, utilize uma lista restrita de domínios aprovados. Permita apenas nomes e identidades de MCP servers aprovados e exija a revisão de determinados comandos de publicação ou bloqueie-os, como git push.

• Utilize hooks e permissões de controlo de versões, políticas para repositórios públicos e fragmentos de código, e controlos de prevenção de perda de dados adequados à sua organização.

Negue o acesso a repositórios não relacionados e a ficheiros de credenciais

No requirements.toml gerido pelo administrador, adicione caminhos exatos que o agente local não pode ler:

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config", "/work/unrelated-repository"]

Substitua os exemplos por caminhos existentes nos seus dispositivos geridos. Esta negação gerida aplica-se a todos os perfis de permissões permitidos; uma negação configurada apenas num perfil personalizado não protege os utilizadores que selecionem outro perfil. Prefira caminhos exatos conhecidos e teste quaisquer padrões glob nos níveis de profundidade necessários.

No Windows nativo, o deny_read gerido abrange ferramentas de acesso direto a ficheiros, mas, por si só, não impede leituras por subprocessos da shell; utilize também identidades do sistema operativo e listas de controlo de acesso a ficheiros.

Crie ficheiros de teste inofensivos nos locais de acesso negado. Em cada perfil permitido, verifique se as leituras diretas e através da shell desses ficheiros são negadas e se é possível ler um ficheiro de código-fonte aprovado. Consulte Requisitos geridos de negação de leitura.

Minimize as variáveis da shell que contêm credenciais

Em /etc/codex/config.toml ou ~/.codex/config.toml, defina um ambiente herdado restrito:

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

Esta definição reduz as variáveis herdadas, mas é configurável pelo utilizador e não impede o acesso a ficheiros de credenciais, auxiliares, conteúdo de inicialização da shell ou outras identidades.

Quando adequado, um administrador também pode adicionar estas restrições a requirements.toml e testá-las num projeto-piloto para avaliar o seu efeito nos fluxos de trabalho dos programadores:

allow_login_shell = false

[features]
shell_snapshot = false

Teste com variáveis sintéticas de controlo e uma identidade de execução separada com privilégios mínimos. Não utilize credenciais reais. Consulte Política de ambiente da shell.

Permita apenas destinos de rede aprovados para comandos locais

Se os comandos locais em sandbox necessitarem de acesso à rede, integre tanto as definições do perfil como as do proxy gerido abaixo em requirements.toml, substituindo os domínios por endpoints aprovados:

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"
"registry.corp.example" = "allow"

O perfil com acesso à rede concede ao comando em sandbox uma via de acesso à rede, enquanto o proxy gerido restringe os seus destinos. Implemente ambos em conjunto; um perfil com acesso à rede sem o proxy gerido previsto não aplica as mesmas restrições de destinos. Se o acesso à Internet não for necessário, mantenha o acesso à rede desativado.

Não combine a tabela canónica domains com as definições legadas allowed_domains ou denied_domains; migre e teste a política existente.

Reinicie o cliente e verifique se um endpoint aprovado funciona e se um endpoint não aprovado é bloqueado.

Estas definições são experimentais; valide o suporte do sistema operativo e do cliente e configure separadamente o acesso à rede privada se um anfitrião aprovado resolver para um endereço privado. Uma elevação aprovada para acesso total fora da sandbox pode contornar o proxy de comandos.

Este controlo de rede para comandos locais não abrange, por si só, a pesquisa na Web, aplicações, MCP servers, atividade do navegador ou ambientes na nuvem, que necessitam de políticas separadas. Um domínio de alojamento aprovado também pode conter repositórios públicos ou fragmentos de código públicos, pelo que uma lista de destinos permitidos, por si só, não protege o conteúdo. Consulte Requisitos de acesso à rede.

Configure separadamente a rede do ambiente na nuvem

Na interface atual do Codex Cloud, abra a configuração do ambiente. Mantenha Permitir que o Codex aceda à Internet desativado. Se necessitar de acesso à Internet, ative-o e escolha Apenas domínios personalizados, adicione os anfitriões exatos necessários em Domínios adicionais permitidos e, em seguida, guarde a configuração, publique ou volte a publicar o ambiente e teste uma nova tarefa.

Reveja de forma independente a autenticação e as capacidades dos serviços.

O Codex Cloud legado utiliza uma definição separada de acesso do agente à Internet por ambiente, com controlos para domínios e métodos HTTP permitidos; os scripts de configuração têm o seu próprio comportamento de acesso.

Teste a versão do ambiente que efetivamente utiliza. Consulte Ligar a serviços e definições legadas de Internet.

Restrinja os MCP servers e solicite aprovação antes de pushes do Git

Permita apenas identidades de MCP servers locais aprovadas em requirements.toml. Por exemplo:

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

Configure o próprio servidor separadamente no config.toml do utilizador ou das predefinições geridas, utilizando o nome e o URL correspondentes e a autenticação exigida pelo seu servidor:

[mcp_servers.internal]
url = "https://mcp.corp.example/mcp"

O requisito apenas permite um servidor correspondente e não o cria. Reveja o acesso e as ferramentas desse servidor.

Verifique se o servidor aprovado consegue estabelecer ligação e se um servidor com um nome ou URL diferente não é permitido.

Adicione uma regra de comando gerida para solicitar revisão antes de um comando de publicação representativo:

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review the destination before publishing." },
]

Combine-a com allowed_approval_policies = ["on-request"] e allowed_approvals_reviewers = ["user"] como requisitos de nível superior se a revisão tiver de ser efetuada por uma pessoa.

Recuse um push de teste e confirme que não é executado.

A correspondência de prefixos não abrange todos os wrappers, clientes de API, aplicações ou vias alternativas de publicação.

Restrinja a publicação pública com controlos de controlo de versões e DLP

Na sua plataforma de controlo de versões, restrinja a criação de repositórios públicos e limite quem pode alterar a visibilidade dos repositórios, quando essa funcionalidade estiver disponível. Reveja as permissões de exceção dos utilizadores com privilégios. Verifique separadamente contas pessoais, fragmentos de código, organizações externas e acesso por tokens: as definições da organização não regem todos os destinos.

No repositório relevante, exija alterações revistas e reveja a proteção de ramos e as permissões de exceção.

Na consola de DLP da sua organização, configure uma política-piloto para conteúdo sensível de código-fonte e para os canais de carregamento ou de repositório que o seu produto de DLP efetivamente abrange; defina a ação como bloquear e teste com um marcador sintético inerte.

Quando a plataforma de controlo de versões suportar controlos do lado do servidor, configure e imponha hooks revistos para os repositórios que recebem pushes.

Utilize destinos de teste autorizados e confirme o bloqueio antes de qualquer publicação.

Verifique

• Crie ficheiros de teste inofensivos e confirme que as tentativas de leitura de ficheiros de acesso negado falham.

• Se o acesso à rede estiver ativado, verifique se um destino aprovado funciona e se um destino não aprovado é bloqueado; caso contrário, verifique se os pedidos de rede são bloqueados.

• Com um marcador inofensivo e contas ou destinos de teste descartáveis, verifique se as tentativas representativas de publicação pública são bloqueadas antes da publicação.

Limites

Um domínio permitido pode continuar a alojar conteúdo público. Configure separadamente a pesquisa na Web, aplicações, MCP servers, atividade do navegador e Codex Cloud; as regras da sandbox local não os controlam.

Utiliza estes procedimentos de configuração: Restringir perfis de permissões e Acesso total; Permitir apenas MCP servers aprovados; Restringir destinos de rede; Proteger segredos e repositórios não relacionados; Exigir aprovação para comandos sensíveis.

Pretende que as restrições que regem o Codex se mantenham em vigor quando este trabalha num repositório ou quando um utilizador altera as configurações locais.

• Distribua as restrições suportadas de permissões, aprovação, MCP, rede e comandos como requisitos impostos pelo administrador.

• Instale scripts de hooks num diretório gerido pelo administrador e utilize apenas hooks geridos se os hooks do utilizador, do projeto e de plugins tiverem de ser ignorados.

• Proteja os ficheiros de políticas e o canal de distribuição da configuração com controlos do sistema operativo e de gestão de dispositivos. Execute o Codex sem os privilégios necessários para alterar essas proteções.

• Reveja a configuração efetiva de cada cliente e ambiente abrangido.

Imponha os perfis, as aprovações, as identidades de servidores e os comandos permitidos

Integre as definições revistas no requirements.toml gerido pelo administrador, em vez de depender das definições editáveis de um utilizador ou repositório. Por exemplo:

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
]

Este exemplo permite dois perfis, exige um revisor humano quando é necessária aprovação, permite uma identidade MCP correspondente e solicita aprovação para um prefixo de comando específico.

Configure o próprio MCP server separadamente e adicione os outros padrões de comandos sensíveis da organização. Adicione restrições globais de ficheiros e restrições de rede quando necessário; os requisitos limitam as definições suportadas, mas não substituem os controlos de identidade, serviços e destinos externos ao Codex.

As listas geridas de perfis permitidos exigem o Codex 0.138.0 ou posterior.

Num cliente-piloto, tente selecionar um perfil não permitido, alterar uma definição restrita do utilizador ou do projeto e utilizar uma identidade MCP fora da lista de permissões; verifique se cada tentativa é rejeitada ou se continua sujeita às restrições após o reinício. Recuse a aprovação de um comando de teste e verifique se o comando não é executado.

Adicione restrições geridas do sistema de ficheiros e da rede

Para negar o acesso a ficheiros locais sensíveis em todos os perfis permitidos, adicione a tabela seguinte a requirements.toml e substitua os exemplos pelos caminhos da sua organização:

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config"]

Quando os comandos locais em sandbox necessitarem de acesso à rede, defina em conjunto um perfil permitido com acesso à rede e destinos geridos:

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"

Escolha esta política de perfis em substituição da predefinição anterior :workspace ou integre deliberadamente ambos os nomes de perfil; não cole chaves ou tabelas duplicadas. Se os comandos não necessitarem de rede, mantenha-a desativada.

Verifique os caminhos exatos de acesso negado utilizando ficheiros inofensivos e verifique os destinos aprovados e não aprovados.

No Windows nativo, utilize também listas de controlo de acesso a ficheiros, porque as leituras por subprocessos da shell não são abrangidas apenas pelo deny_read gerido.

A rede dos comandos locais não rege outros clientes, aplicações, conectores ou a execução na nuvem.

Instale e imponha hooks geridos pelo administrador

Peça a um administrador que instale um programa de hook revisto num diretório gerido por root, como /etc/codex/hooks/pre_tool_use_policy.py, e impeça o utilizador do Codex de alterar o ficheiro ou o respetivo diretório. Em requirements.toml, ative os hooks e ignore os hooks do utilizador, do projeto, da sessão e de plugins:

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/etc/codex/hooks"

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "/usr/bin/python3 /etc/codex/hooks/pre_tool_use_policy.py"
timeout = 30
statusMessage = "Checking managed Bash command"

O requisito regista o hook, mas não o instala. Para um teste de integração local no macOS, guarde o seguinte como pre_tool_use_policy.py e peça a um administrador que o instale com os comandos abaixo.

Apenas bloqueia o marcador sintético; substitua-o por uma política revista específica da organização antes de depender dele. Confirme que /usr/bin/python3 existe no destino e ajuste o caminho do interpretador, se necessário:

import json
import sys

event = json.load(sys.stdin)
command = event.get("tool_input", {}).get("command", "")
if "CODEX_HOOK_TEST_DENY" in command:
    print("Synthetic test command blocked by managed hook.", file=sys.stderr)
    sys.exit(2)

sudo install -d -o root -g wheel -m 755 /etc/codex/hooks
sudo install -o root -g wheel -m 644 ./pre_tool_use_policy.py /etc/codex/hooks/pre_tool_use_policy.py

Reinicie o cliente local e, em seguida:

• Confirme que um comando Bash inofensivo é executado.

• Confirme que um comando que contenha CODEX_HOOK_TEST_DENY é bloqueado.

• Verifique se a política e as dependências não podem ser alteradas pelo utilizador do Codex.

allow_managed_hooks_only ignora todos os hooks não geridos do utilizador, do projeto, da sessão e de plugins e pode afetar outros fluxos de trabalho.

O mecanismo de correspondência Bash não abrange todas as ferramentas nem os dados fornecidos posteriormente a um processo existente; erros, tempos limite excedidos ou respostas de hooks malformadas podem permitir que uma chamada de ferramenta prossiga.

O Work orquestrado na nuvem utiliza diferentes processadores de hooks suportados. Mantenha proteções independentes ao nível do sistema operativo e dos serviços. Consulte Hooks geridos e comportamento dos hooks.

Proteja a política e a sua distribuição

No macOS, um administrador pode implementar um ficheiro de requisitos revisto e integrado num diretório principal pertencente a root e impedir que o utilizador do Codex escreva no ficheiro:

sudo install -d -o root -g wheel -m 755 /etc/codex
sudo install -o root -g wheel -m 644 ./requirements.reviewed.toml /etc/codex/requirements.toml
ls -ld /etc/codex
ls -l /etc/codex/requirements.toml

No Linux, utilize o grupo de administradores adequado; no Windows, proteja o diretório ProgramData e o ficheiro com listas de controlo de acesso geridas pelo administrador. Restrinja quem pode alterar a política de MDM ou da nuvem, reveja as alterações e preserve uma cópia para reversão.

Com uma conta-piloto sem privilégios de administrador, verifique se a conta não consegue modificar a política, o diretório principal ou o programa de hook gerido; experimente uma definição menos restritiva do utilizador ou do projeto, reinicie o Codex e verifique se o comportamento imposto se mantém.

Teste cada cliente e ambiente abrangido, em vez de presumir que todos os clientes carregam a mesma política.

Verifique

Com uma identidade de teste sem privilégios de administrador:

• Tente editar a política gerida. Resultado esperado: o ficheiro gerido não pode ser alterado.

• Tente enfraquecer uma restrição através da configuração do utilizador ou do projeto. Resultado esperado: as definições menos restritivas são rejeitadas ou continuam sujeitas às restrições.

• Reinicie o cliente e verifique se as restrições continuam a aplicar-se.

Limites

Um utilizador ou agente com privilégios suficientes de administrador no anfitrião poderá conseguir alterar as proteções envolventes. As definições editáveis pelo utilizador, por si só, não substituem os requisitos geridos pelo administrador.