Guia prático de segurança do Codex

Use esta receita quando os funcionários precisarem entrar no Codex pelo espaço de trabalho do ChatGPT da empresa e o uso de contas pessoais do ChatGPT ou de chaves de API para autenticação for proibido nos endpoints gerenciados.

Resultado esperado

Nos dispositivos gerenciados pela empresa, o Codex aceita apenas o login pelo ChatGPT no espaço de trabalho do ChatGPT da empresa.

Pré-requisitos

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

• Um meio de distribuir a configuração gerenciada do Codex aos endpoints.

• A decisão de proibir a autenticação por chave de API nos endpoints gerenciados.

Configuração

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

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

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

   A primeira chave permite apenas a autenticação pelo ChatGPT. A segunda restringe o login ao espaço de trabalho aprovado. Substitua o UUID do exemplo pelo UUID do seu espaço de trabalho. Consulte a referência de requisitos.

3. Distribua os requisitos pelo requirements.toml local ou pelo MDM do macOS, usando os caminhos indicados em Onde aplicar a configuração. Esses requisitos de autenticação se aplicam antes do carregamento das credenciais e da obtenção da política da nuvem. O Codex os ignora quando estão nos requisitos gerenciados na nuvem. Impeça que o usuário modifique o arquivo ou o diretório que o contém. Os padrões do antigo managed_config.toml não impõem essa restrição.

4. Durante o piloto, encerre as sessões dos usuários ou remova as sessões pessoais do Codex armazenadas anteriormente. Não presuma que uma nova política invalide retroativamente uma sessão existente.

5. Combine a restrição de login com funções do espaço de trabalho e acesso por grupo. A autenticação determina qual identidade pode entrar. O controle de acesso baseado em funções (RBAC) determina quais recursos do Codex essa identidade pode usar. Consulte Autenticação.

Verificação

• Saia do Codex.

• Tente entrar com uma conta pessoal do ChatGPT. Resultado esperado: o login no espaço de trabalho pessoal é recusado.

• Tente entrar no Codex com uma chave de API. Resultado esperado: o login por chave de API é recusado.

• Entre no espaço de trabalho aprovado com a conta corporativa. Resultado esperado: o login funciona.

• Reinicie o aplicativo para desktop, a CLI e a extensão de IDE e repita os testes.

Reversão

Restaure os requisitos locais de autenticação anteriores e implante novamente o pacote revisado.

Limites

Este controle se aplica aos clientes gerenciados do Codex em endpoints gerenciados. Combine-o com controles de aplicativos nos endpoints e uma política de rede se o requisito for “proibir o uso pessoal do Codex em recursos corporativos”.

Use esta receita quando os desenvolvedores precisarem de acesso somente leitura ou restrito ao espaço de trabalho e você quiser impedir que selecionem Acesso completo ou usem --yolo para contornar as aprovações e o ambiente isolado.

Resultado esperado

Os usuários só podem selecionar perfis aprovados de acesso somente leitura ou restrito ao espaço de trabalho. Eles não podem selecionar danger-full-access, approval_policy = "never" ou --yolo.

Configuração

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

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

2. Imponha as restrições de perfis e políticas de aprovação:

   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. Perfis ausentes da lista ou definidos como falsos são recusados, inclusive os que forem adicionados em versões futuras. Consulte a Referência de configuração.

3. Para clientes legados que ainda usam sandbox_mode, use:

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

4. Distribua essas configurações como requisitos impostos pelo administrador. Um arquivo de configuração que o usuário possa editar não impõe a restrição.

5. Se decidir permitir a Revisão automática mais tarde, adicione-a explicitamente após os testes. A Revisão automática muda quem avalia uma ação que ultrapassa um limite. Ela não restabelece um limite removido. Consulte Revisão automática.

Verificação

• Abra o seletor de permissões. Resultado esperado: a opção Acesso completo está indisponível ou sua seleção é recusada.

• Inicie o Codex com --dangerously-bypass-approvals-and-sandbox. Resultado esperado: o Codex recusa a inicialização ou impõe um perfil compatível.

• Inicie o Codex com --sandbox danger-full-access --ask-for-approval never. Resultado esperado: a inicialização é recusada.

• Execute uma tarefa normal no espaço de trabalho. Resultado esperado: a tarefa é concluída e as ações que ultrapassam os limites continuam exigindo aprovação.

Reversão

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

Limites

Este controle restringe as permissões de execução do Codex. Ele não remove os privilégios de uma conta privilegiada do sistema operacional.

Use esta receita quando sua organização precisar decidir quais servidores MCP o Codex pode usar e impor uma lista de servidores aprovados.

Autorizar um servidor e configurá-lo são etapas distintas. Uma entrada na lista de permissões autoriza um servidor correspondente, mas não cria sua configuração. Configure o servidor separadamente com o nome e a identidade correspondentes e a autenticação exigida por ele.

Resultado esperado

O Codex habilita apenas os servidores MCP cujo nome e identidade configurados correspondem à lista aprovada pela empresa.

Configuração

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

2. Comece bloqueando tudo. Uma tabela gerenciada vazia desabilita todos os servidores MCP:

   [mcp_servers]

3. Adicione os servidores HTTP aprovados pela URL exata:

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

4. Adicione os 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=" },
   ] }

   A regra de correspondência estruturada verifica o executável, a quantidade de argumentos e sua ordem. Ela não restringe cwd, env nem env_vars. Para aprovar um servidor stdio, é preciso controlar todo o contexto de inicialização. Proteja o executável e suas dependências e impeça que configurações não confiáveis de usuários ou projetos forneçam um diretório de trabalho ou um ambiente capaz de alterar o comportamento do servidor. Se não puder impor esse limite de forma independente, mantenha o servidor stdio sem aprovação e use um servidor HTTP que tenha passado por revisão.

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

6. Armazene a lista aprovada em um repositório de configuração sujeito a revisão e distribua-a por meio de requisitos impostos pelo administrador.

O cliente só habilita um servidor quando tanto o nome quanto a identidade correspondem a uma entrada aprovada. Consulte Configuração gerenciada.

Verificação

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

• Altere um caractere da URL. Resultado esperado: o servidor é desabilitado.

• Altere a quantidade ou a ordem dos argumentos de stdio ou forneça um argumento que não atenda às regras configuradas. Resultado esperado: o servidor é desabilitado. Valores que ainda correspondam a um prefixo autorizado continuam permitidos.

• Em um projeto confiável e descartável, teste substituições inofensivas de cwd, env e env_vars, mantendo o executável e os argumentos correspondentes. A verificação de identidade, por si só, não recusa essas substituições. Verifique se o controle independente do contexto de inicialização recusa substituições inseguras ou se o servidor stdio continua sem aprovação. Não use código de injeção real.

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

• Teste um servidor incluído em um plugin. Resultado esperado: o servidor funciona apenas com a identidade aprovada.

Reversão

Remova a entrada recém-adicionada. Para interromper imediatamente todo uso de MCP, implante uma tabela mcp_servers vazia.

Limites

A lista de identidades permitidas não comprova que as ferramentas, os dados de origem, as credenciais ou o ambiente de inicialização de um servidor sejam seguros. Os processos MCP stdio locais são executados fora do sandbox de comandos local. Verificar a correspondência do executável e dos argumentos não restringe o acesso do servidor nem impede o carregamento de código por meio do ambiente. Revise de forma independente todo o contexto de inicialização e as permissões do servidor. Consulte Requisitos de identidade MCP.

Use esta receita quando a equipe de segurança precisar entender o que o Codex faz nos endpoints e na rede. Ela reúne eventos de execução e de ferramentas, decisões de aprovação, registros de auditoria do espaço de trabalho e logs de rede para investigação.

Resultado esperado

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

Use quatro fontes de evidências

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

2. Hooks gerenciados de ciclo de vida: registros no endpoint sobre o uso de ferramentas e as solicitações de permissão.

3. Logs do proxy ou gateway de rede: destinos DNS/HTTP efetivamente solicitados e resultados das conexões.

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

Nenhuma fonte, isoladamente, oferece monitoramento completo da rede.

Configuração

1. Envie os logs do OpenTelemetry do Codex ao seu coletor, omitindo o conteúdo original dos prompts:

   [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}" }

   Antes de iniciar o cliente, forneça OTLP_TOKEN ao processo do Codex pelo gerenciador de segredos aprovado ou pelo ambiente do processo. Mantenha o token fora dos arquivos TOML implantados e do controle de versão.

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

2. Implante o OTel fora da configuração local do projeto. Os arquivos .codex/config.toml do projeto não podem substituir o roteamento da telemetria.

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

4. Instale os scripts dos hooks em um diretório gerenciado pelo administrador e defina allow_managed_hooks_only = true se os hooks de usuários, projetos e plugins precisarem ser ignorados.

5. Encaminhe o tráfego dos comandos executados no sandbox por um proxy que mantenha logs independentes. O OTel registra a execução da ferramenta. O proxy registra os destinos aos quais o subprocesso tentou se conectar.

6. Configure telemetria separada para pesquisa na Web, aplicativos, conectores, servidores MCP, atividade do navegador e Codex Cloud. As regras do proxy de comandos locais não abrangem esses recursos automaticamente.

7. Transmita os registros compatíveis da API de Compliance ao SIEM e aplique seus próprios controles de retenção e preservação por obrigação legal. Consulte API de Compliance e eventos de auditoria.

8. Correlacione o usuário ou a conta de serviço, o host ou executor, o ID da conversa, o modelo, a versão do cliente, o perfil de permissão, a decisão de aprovação, o destino e o nome da ferramenta.

Verificação

Execute uma sessão controlada em que o Codex realize as seguintes ações:

• Leia um arquivo permitido.

• Tente ler um arquivo cuja leitura esteja bloqueada.

• Execute um comando permitido.

• Tente enviar uma solicitação de saída que esteja bloqueada.

• Solicite aprovação e receba uma recusa.

• Encerre a sessão.

Resultados esperados por fonte de evidências:

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

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

• Os logs do proxy mostram os destinos permitidos e bloqueados.

• O processo de ingestão de dados de compliance recebe os registros compatíveis.

• O SIEM correlaciona esses registros com o usuário ou a carga de trabalho.

Reversão

Restaure a configuração anterior para desabilitar o exportador e os hooks. Ao reverter a telemetria, mantenha o registro independente de logs do proxy.

Limites

Não prometa que a telemetria do Codex captura cada argumento de comando, byte de saída ou pacote de rede. Documente a cobertura de cada camada.

Use esta receita quando o Codex precisar ficar sem acesso à internet ou acessar apenas destinos aprovados. Escolha o procedimento local ou de nuvem conforme o ambiente que estiver configurando. As políticas de cada ambiente têm escopos distintos.

Resultado esperado

O Codex fica sem acesso à internet ou acessa apenas os domínios aprovados, conforme a configuração escolhida. Os ambientes do Codex Cloud (legado) também podem restringir os métodos HTTP.

Configurar a versão atual do Codex Cloud

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, desative Habilitar todo o acesso à internet pública e Habilitar domínios de gerenciadores de pacotes.

3. Quando for necessário acessar a internet pública, adicione os nomes exatos dos hosts aprovados em Domínios adicionais permitidos. Remova os Segredos HTTP que permitam acessar destinos públicos não aprovados. Para bloquear o acesso à internet pública fora da VPN, deixe a lista vazia e remova os Segredos HTTP que permitam acessar destinos públicos.

4. Salve a configuração e teste os serviços durante a preparação do ambiente. Publique ou republique o ambiente e teste o acesso a destinos aprovados e não aprovados em uma nova tarefa. Revise os scripts de preparação separadamente. Fixe as versões das dependências, prefira espelhos aprovados e evite baixar executáveis que não tenham passado por revisão.

Consulte Conectar a serviços. As configurações atuais do Codex Cloud não incluem o seletor de métodos HTTP da versão legada.

Configurar o Codex Cloud (legado)

1. Mantenha o acesso do agente à internet Desativado quando for desnecessário. Por padrão, a versão legada bloqueia a internet durante a fase do agente. Os scripts de preparação continuam com acesso à internet para instalar dependências.

2. Quando o agente precisar de acesso, defina a opção como Ativado e use uma lista restrita de permissões. Comece com Nenhum e adicione os domínios exatos.

3. Para fluxos que só precisam fazer downloads, permita apenas GET, HEAD e OPTIONS. Isso bloqueia POST, PUT, PATCH, DELETE e os demais métodos. Revise os scripts de preparação separadamente, pois a restrição da fase do agente não controla o acesso desses scripts à internet.

Consulte Acesso do agente à internet na versão legada. Essas predefinições e os controles de métodos HTTP se aplicam apenas à versão legada do ambiente de nuvem.

Configurar o Codex local

1. No requirements.toml gerenciado pelo administrador, defina e selecione o perfil de rede aprovado e restrinja os usuários 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. Implante o pacote de requisitos revisado conforme as instruções de Configuração gerenciada. Só dar nome a um perfil não o ativa. A configuração default_permissions seleciona o perfil e a lista de permissões impede a seleção de outros perfis.

3. Ative o proxy gerenciado pelo administrador no mesmo pacote de requisitos para impor as restrições de domínio e impedir que os usuários ampliem o acesso. Implante o proxy junto com o perfil que habilita a rede. Sem um proxy ativo, esse perfil concede acesso direto à rede sem impor suas regras de domínio:

   Atenção: [experimental_network] é experimental e pode mudar. Valide essa configuração em cada versão compatível do cliente local e em cada sistema operacional antes de ampliar a implantação. O suporte ao Windows é limitado. Só aplique essa política aos usuários do Windows após testar se as restrições são impostas 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, a menos que o fluxo de trabalho precise dela. Configure separadamente o acesso a destinos em redes privadas. Permitir um domínio não autoriza, por si só, o acesso a seus endereços privados. Consulte Requisitos de acesso à rede.

5. Configure separadamente a pesquisa na Web, os aplicativos, os servidores MCP, a atividade do navegador e o Codex Cloud. As regras do sandbox local não controlam esses recursos.

Verificação

• Envie uma solicitação a um domínio aprovado e confirme que ela é bem-sucedida.

• Envie uma solicitação a um domínio não aprovado e confirme que ela é bloqueada.

• Envie solicitações a localhost, a um IP privado e a um endpoint de metadados da nuvem. Confirme que cada solicitação é bloqueada, salvo quando houver aprovação explícita.

• No Codex Cloud (legado), tente enviar uma solicitação POST a um domínio permitido. Confirme que a solicitação é bloqueada quando apenas GET, HEAD e OPTIONS são permitidos.

• Confirme que os logs do proxy ou gateway contêm entradas tanto para as solicitações permitidas quanto para as recusadas.

Reversão

Volte a desativar o acesso à internet no ambiente ou restaure a política de domínios anterior. Evite voltar a uma configuração de acesso irrestrito à internet.

Limites

Uma elevação aprovada que remova todas as restrições do sandbox pode contornar o proxy de comandos locais. Antes de depender da restrição, teste separadamente os comandos comuns executados no sandbox e os comandos com elevação aprovada.

Um domínio permitido ainda pode hospedar conteúdo com injeção de prompt, pacotes comprometidos ou documentação insegura.

Use esta receita quando o Codex precisar acessar diretórios de código-fonte aprovados, mas segredos, arquivos .env, chaves SSH e repositórios não relacionados precisarem ficar fora de alcance. Ela mostra como restringir o acesso a arquivos e reduzir o número de variáveis de ambiente que contêm credenciais e são repassadas aos comandos iniciados pelo Codex.

Resultado esperado

O Codex pode trabalhar nos diretórios de código-fonte aprovados, mas não consegue ler arquivos que costumam conter segredos nem herdar um conjunto amplo de variáveis de ambiente com credenciais.

Configuração

1. Defina padrões de bloqueio de leitura em um 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 os caminhos exatos a bloquear para diretórios conhecidos de credenciais, chaves de assinatura, configuração de produção e repositórios vizinhos.

3. No arquivo de sistema /etc/codex/config.toml ou no arquivo de usuário ~/.codex/config.toml, reduza as variáveis de ambiente repassadas aos comandos iniciados pelo Codex:

   [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"

   Esse padrão pode ser alterado pelo usuário e não impõe um requisito. Ele reduz as variáveis herdadas, mas não impede o acesso a arquivos de credenciais, utilitários de credenciais, conteúdo de inicialização do shell ou outras identidades. Consulte Configuração avançada.

4. No requirements.toml gerenciado pelo administrador, selecione o perfil restrito e permita apenas esse perfil. Os perfis integrados não herdam seus bloqueios de acesso a arquivos com segredos:

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

5. Escolha como fornecer credenciais no seu ambiente de nuvem:

   • Na versão atual do Codex Cloud, use Segredos HTTP para credenciais enviadas a um serviço HTTPS permitido. Os programas recebem um valor substituto. Durante a preparação do ambiente e a execução de tarefas, o proxy troca esse valor pela credencial real para destinos aprovados na porta 443. Nenhum processo ou arquivo local recebe a credencial original. Variáveis de ambiente fornecidas diretamente ficam disponíveis aos programas. Consulte Variáveis de ambiente e segredos de rede.
   • No Codex Cloud (legado), os segredos permitem autenticação durante a preparação do ambiente e são removidos antes da fase do agente. As variáveis de ambiente permanecem disponíveis durante todo o chat. Consulte Ambientes de nuvem legados.

6. Se o agente precisar de autenticação, use um intermediário independente para fornecer credenciais de curta duração restritas ao destino e à ação específicos. Consulte Configuração recomendada.

Verificação

Crie arquivos de teste inofensivos:

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

Depois, peça ao Codex para:

• Ler um arquivo comum.

• Ler cada arquivo de teste.

• Buscar segredos recursivamente.

• Exibir o ambiente em que os comandos são executados.

• Ler um repositório vizinho.

Resultado esperado: a leitura do arquivo comum funciona, os arquivos bloqueados e os repositórios vizinhos continuam inacessíveis e as variáveis excluídas não aparecem no ambiente dos comandos.

Reversão

Restaure o perfil anterior, mas mantenha os bloqueios de arquivos que você sabe com segurança que contêm segredos enquanto investiga falhas nos fluxos de trabalho.

Limites

Os bloqueios no sistema de arquivos não removem segredos já colados em prompts, registrados em commits de código acessível, retornados por conectores ou gravados em logs que o modelo pode acessar.

Use esta receita quando ações como git push, implantações, migrações de banco de dados e comandos de CLI de nuvem precisarem de aprovação antes da execução. Decida quais comandos devem solicitar revisão e quais devem ser proibidos. Depois, configure as regras correspondentes.

Resultado esperado

Os comandos sensíveis sempre aguardam aprovação ou são proibidos, mesmo quando o modelo considera sua execução apropriada.

Configuração

1. Decida quais comandos devem solicitar aprovação e quais são proibidos.

2. Adicione regras de comando 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 definidas nos requisitos podem exigir aprovação ou proibir um comando, mas não podem autorizá-lo. Consulte Configuração gerenciada.

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

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

   Essa entrada pode gerar muitas solicitações de aprovação. Use-a de forma seletiva.

4. Se uma pessoa precisar aprovar os comandos, imponha estas configurações:

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

   A Revisão automática muda quem faz a revisão. Ela não oferece uma garantia determinística de segurança. Consulte Revisão automática.

5. Envie os eventos PermissionRequest, de decisão sobre ferramentas e de resultado de ferramentas ao pipeline de segurança.

Verificação

• Execute git status. Resultado esperado: nenhuma solicitação de aprovação aparece.

• Execute git push. Resultado esperado: aparece uma solicitação de aprovação.

• Execute terraform apply. Resultado esperado: aparece uma solicitação de aprovação.

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

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

• Recuse uma solicitação de aprovação. Resultado esperado: o comando não é executado e a recusa é registrada no log.

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

Reversão

Restaure o pacote de requisitos anterior. Se um padrão de tokens for amplo demais, torne-o mais específico em vez de remover toda uma classe de comandos sensíveis.

Limites

As regras de prefixo não constituem um mecanismo completo de políticas do sistema operacional. Combine-as com um ambiente isolado, contas do sistema operacional com o mínimo de privilégios, restrições de rede, IAM da nuvem, proteção de branches, aprovações de implantação e autorização no banco de dados.

Receitas de configuração usadas: Restringir os perfis de permissão e o Acesso completo, Proteger segredos e repositórios não relacionados e Exigir aprovação para comandos sensíveis.

Os desenvolvedores têm acesso legítimo ao ambiente de produção, mas você quer que o Codex ajude no desenvolvimento sem fazer alterações em produção que não tenham passado por revisão.

• Defina um perfil aprovado para o espaço de trabalho e restrinja os perfis e as políticas de aprovação às opções permitidas. Distribua essas configurações como requisitos impostos pelo administrador para impedir que os usuários as substituam.

• Execute o Codex com uma identidade separada, com menos privilégios, ou em um ambiente que não possa acessar nem obter credenciais de gravação em produção. Os desenvolvedores podem manter o acesso à produção por meio de um fluxo autorizado separado.

• Reduza ao mínimo as variáveis de ambiente repassadas aos comandos iniciados pelo Codex. Se o agente precisar de autenticação, use um intermediário independente para fornecer credenciais de curta duração restritas ao destino e à ação específicos.

• Decida quais comandos devem solicitar aprovação e quais são proibidos. Exija que uma pessoa aprove comandos selecionados de alto impacto, como git push, terraform apply, alterações no Kubernetes e migrações de banco de dados. Proíba os comandos que nunca devem ser executados.

• Mantenha o IAM de produção, a proteção de branches e as aprovações de implantação em vigor independentemente do Codex.

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

No requirements.toml gerenciado pelo administrador, permita os perfis integrados de espaço de trabalho e de acesso somente leitura e exija revisão pelo usuário para ações que precisem 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 atuar nesse espaço dentro do sandbox. O perfil somente leitura está disponível para tarefas de escopo mais restrito. Os perfis de acesso completo ficam fora da lista de permissões.

Defina approval_policy = "on-request" na configuração do cliente se ele precisar de uma opção compatível explícita. Com on-request, o cliente pode solicitar aprovação quando necessário, sem pedi-la a cada comando. Adicione regras explícitas para as ações que precisam de revisão e mantenha a autorização de produção independente.

As listas gerenciadas de perfis permitidos exigem o Codex 0.138.0 ou posterior. Para clientes mais antigos, use e teste os requisitos documentados para o modo de sandbox legado.

Reinicie cada cliente piloto. Verifique se o perfil aprovado funciona e se um perfil de acesso completo não permitido é recusado.

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

No sistema de gerenciamento de dispositivos ou de provisionamento de ambientes de desenvolvimento, crie um usuário, contêiner ou host de desenvolvimento dedicado ao Codex. Conceda acesso apenas ao código-fonte e aos serviços de desenvolvimento necessários. Não monte nesse ambiente os arquivos de credenciais de produção, os utilitários de tokens ou os chaveiros do desenvolvedor. Impeça que a identidade assuma funções com permissão de gravação em produção.

Se o agente precisar acessar serviços, configure o intermediário de credenciais da organização para emitir credenciais de curta duração restritas ao recurso de desenvolvimento e à ação. O desenvolvedor pode usar sua identidade habitual em um fluxo 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 revisada como a do exemplo. Substitua 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"
    }
  ]
}

O exemplo bloqueia tentativas de assumir a função especificada, mas não bloqueia 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 revise as políticas de confiança e os controles no nível da organização.

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

Reduzir ao mínimo o ambiente do shell

Em /etc/codex/config.toml, para uma configuração inicial de todo o sistema, ou em ~/.codex/config.toml, para um único usuário, configure quais variáveis de ambiente os comandos iniciados pelo Codex 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"

Esse padrão é configurável e não impõe um limite de acesso a credenciais. Configurações do usuário, a inicialização ou os snapshots do shell, utilitários de credenciais e outras fontes ainda podem expor credenciais.

Em requirements.toml, use as restrições opcionais a seguir para desabilitar shells de login e snapshots do shell, se forem compatíveis com seu fluxo de trabalho:

allow_login_shell = false

[features]
shell_snapshot = false

Teste essas configurações em um piloto, pois alguns fluxos dependem da inicialização de um shell de login.

Inicie o Codex com variáveis sintéticas inofensivas que correspondam aos filtros e inspecione o ambiente de um comando iniciado por ele. Se o shell de login estiver desabilitado, verifique também se uma solicitação para usá-lo é recusada. Verifique de forma independente se a identidade de execução não consegue acessar credenciais reais de produção. Consulte Política de ambiente do shell.

Pedir aprovação para comandos selecionados de alto impacto

Adicione regras aos requisitos para os comandos que sua organização usa. 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." },
]

Use forbidden para um comando que nunca deve ser executado. Substitua ou adicione padrões para as ferramentas de implantação e migração que você usa.

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

Em um destino descartável, execute um comando comum, solicite uma ação da lista, recuse a solicitação de aprovação e verifique se a ação não foi executada. Consulte Como impor regras de comando.

Exigir aprovações de repositório e implantação fora do Codex

Na plataforma de controle de versão, proteja branches de produção como main. Exija revisão das alterações, as aprovações necessárias e as verificações de status. Revise quais funções podem contornar esses requisitos. Configure a aprovação de implantação no sistema de implantação correspondente e os privilégios de banco de dados no próprio banco.

Use um repositório descartável para verificar se uma alteração revisada é aceita e se um push direto não autorizado é recusado. Esses controles se aplicam independentemente de a ação ter sido solicitada pelo Codex.

Verificação

Em um destino de teste descartável:

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

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

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

• Reinicie o cliente e repita os testes.

Limites

As regras de prefixo não constituem um mecanismo completo de políticas do sistema operacional. Combine-as com um ambiente isolado, contas do sistema operacional com o mínimo de privilégios, restrições de rede, IAM da nuvem, proteção de branches, aprovações de implantação e autorização no banco de dados.

Receitas de configuração usadas: Proteger segredos e repositórios não relacionados, Restringir os destinos de rede, Permitir somente servidores MCP aprovados e Exigir aprovação para comandos sensíveis.

Os desenvolvedores usam o Codex com repositórios internos e você quer reduzir o risco de que o código seja enviado a um repositório público, publicado como trecho de código público ou enviado a outro destino não aprovado.

• Adicione os caminhos exatos a bloquear para diretórios conhecidos de credenciais e repositórios não relacionados. Reduza ao mínimo as variáveis de ambiente repassadas aos comandos iniciados pelo Codex.

• Quando o agente precisar acessar a internet, use uma lista restrita de domínios aprovados. Permita apenas nomes e identidades aprovados de servidores MCP. Para comandos de publicação selecionados, como git push, exija revisão ou proíba sua execução.

• Use hooks e permissões de controle de versão, políticas para repositórios públicos e trechos de código e controles de prevenção contra perda de dados adequados à sua organização.

Bloquear o acesso a repositórios não relacionados e arquivos de credenciais

No requirements.toml gerenciado pelo administrador, adicione os caminhos exatos que o agente local não deve ler:

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

Substitua os exemplos por caminhos presentes nos dispositivos gerenciados. Esse bloqueio gerenciado se aplica a todos os perfis de permissão autorizados. Um bloqueio configurado em apenas um perfil personalizado não protege os usuários que selecionam outro perfil. Prefira caminhos exatos conhecidos e teste os padrões glob nos níveis de profundidade necessários.

No Windows nativo, a configuração gerenciada deny_read abrange as ferramentas que acessam arquivos diretamente, mas, sozinha, não impede leituras por subprocessos do shell. Use também identidades do sistema operacional e listas de controle de acesso a arquivos.

Crie arquivos de teste inofensivos nos locais bloqueados. Em cada perfil permitido, verifique se as leituras desses arquivos são bloqueadas tanto diretamente quanto pelo shell e se é possível ler um arquivo de código-fonte aprovado. Consulte Requisitos gerenciados de bloqueio de leitura.

Reduzir ao mínimo as variáveis do shell que contêm credenciais

Em /etc/codex/config.toml ou ~/.codex/config.toml, limite as variáveis de ambiente herdadas:

[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"

Essa configuração reduz as variáveis herdadas, mas pode ser alterada pelo usuário e não impede o acesso a arquivos de credenciais, utilitários de credenciais, conteúdo de inicialização do shell ou outras identidades.

Quando apropriado, um administrador também pode adicionar estas restrições ao requirements.toml e testá-las em um piloto para avaliar o efeito nos fluxos de trabalho dos desenvolvedores:

allow_login_shell = false

[features]
shell_snapshot = false

Teste com variáveis sintéticas de controle e uma identidade de execução separada, com o mínimo de privilégios. Não use credenciais reais. Consulte Política de ambiente do shell.

Permitir somente destinos de rede aprovados para comandos locais

Se os comandos locais executados no sandbox precisarem de acesso à rede, incorpore ao requirements.toml tanto a configuração do perfil quanto a do proxy gerenciado mostradas abaixo. Substitua os domínios pelos 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 rede habilitada permite que o comando executado no sandbox acesse a rede. O proxy gerenciado restringe os destinos. Implante os dois juntos, pois o perfil com rede habilitada, sem o proxy gerenciado previsto, não impõe as mesmas restrições de destino. Se o acesso à internet for desnecessário, mantenha o acesso à rede desabilitado.

Não combine a tabela canônica domains com as configuraçõ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.

Essas configurações são experimentais. Valide a compatibilidade do sistema operacional e do cliente e configure separadamente o acesso à rede privada se um host aprovado resolver para um endereço privado. Uma elevação aprovada que remova todas as restrições do sandbox pode contornar o proxy de comandos.

Esse controle de rede para comandos locais não abrange, por si só, a pesquisa na Web, os aplicativos, os servidores MCP, a atividade do navegador nem os ambientes de nuvem. Esses recursos precisam de políticas separadas. Um domínio de hospedagem aprovado também pode conter repositórios ou trechos de código públicos. Restringir os destinos a uma lista de permissões não basta para proteger o conteúdo. Consulte Requisitos de acesso à rede.

Configurar separadamente a rede dos ambientes de nuvem

Na interface atual do Codex Cloud, abra a configuração do ambiente. Desative Habilitar todo o acesso à internet pública e Habilitar domínios de gerenciadores de pacotes. Se o acesso à internet pública for necessário, adicione os nomes exatos dos hosts aprovados em Domínios adicionais permitidos. Remova os Segredos HTTP que permitam acessar destinos públicos não aprovados. Para bloquear o acesso à internet pública fora da VPN, deixe a lista vazia e remova os Segredos HTTP que permitam acessar destinos públicos. Salve a configuração, publique ou republique o ambiente e teste uma nova tarefa.

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

A versão legada do Codex Cloud tem uma configuração de acesso do agente à internet para cada ambiente, com controles para domínios e métodos HTTP permitidos. Os scripts de preparação têm regras de acesso próprias.

Teste a versão do ambiente que você usa. Consulte Conectar a serviços e configurações legadas de internet.

Restringir servidores MCP e pedir aprovação antes de um push do Git

Em requirements.toml, permita somente identidades aprovadas de servidores MCP locais. Por exemplo:

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

Configure o servidor separadamente no config.toml do usuário ou de padrões gerenciados, com o nome e a URL correspondentes e a autenticação exigida pelo servidor:

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

O requisito apenas permite um servidor correspondente, sem criá-lo. Revise o acesso e as ferramentas do próprio servidor.

Verifique se o servidor aprovado consegue se conectar e se um servidor com nome ou URL diferente é recusado.

Adicione uma regra de comando gerenciada 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." },
]

Se a revisão precisar ser feita por uma pessoa, combine a regra com allowed_approval_policies = ["on-request"] e allowed_approvals_reviewers = ["user"] como requisitos de nível superior.

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

A correspondência de prefixos não abrange todos os wrappers, clientes de API, aplicativos ou meios alternativos de publicação.

Restringir a publicação pública com controles de versão e de DLP

Na plataforma de controle de versão, restrinja a criação de repositórios públicos e limite quem pode alterar a visibilidade dos repositórios, quando a plataforma oferecer esses controles. Revise as permissões de usuários privilegiados para contornar restrições. Verifique separadamente as contas pessoais, os trechos de código, as organizações externas e o acesso por token. As configurações da organização não controlam todos os destinos.

No repositório em questão, exija revisão das alterações e revise a proteção de branches e as permissões para contorná-la.

No console de prevenção contra perda de dados (DLP) da organização, configure uma política piloto para conteúdo sensível de código-fonte e para os canais de upload ou de repositório que o produto de DLP de fato abrange. Configure a ação de bloqueio e teste com um marcador sintético inerte.

Quando a plataforma de controle de versão oferecer controles no servidor, configure hooks revisados e torne sua execução obrigatória nos repositórios que recebem pushes.

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

Verificação

• Crie arquivos de teste inofensivos e confirme que as tentativas de ler arquivos bloqueados falham.

• Se o acesso à rede estiver habilitado, verifique se o acesso a um destino aprovado funciona e se o acesso a um destino não aprovado é bloqueado. Caso contrário, verifique se as solicitações de rede são bloqueadas.

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

Limites

Um domínio permitido ainda pode hospedar conteúdo público. Configure separadamente a pesquisa na Web, os aplicativos, os servidores MCP, a atividade do navegador e o Codex Cloud. As regras do sandbox local não controlam esses recursos.

Receitas de configuração usadas: Restringir os perfis de permissão e o Acesso completo, Permitir somente servidores MCP aprovados, Restringir os destinos de rede, Proteger segredos e repositórios não relacionados e Exigir aprovação para comandos sensíveis.

Você quer que as restrições do Codex continuem em vigor quando ele trabalha em um repositório ou quando um usuário altera as configurações locais.

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

• Instale os scripts dos hooks em um diretório gerenciado pelo administrador e permita apenas hooks gerenciados se os hooks de usuários, projetos e plugins precisarem ser ignorados.

• Proteja os arquivos de política e o mecanismo de distribuição das configurações com controles do sistema operacional e de gerenciamento de dispositivos. Execute o Codex sem os privilégios necessários para alterar essas proteções.

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

Impor as regras para perfis, aprovações, identidades de servidores e comandos permitidos

Incorpore as configurações revisadas ao requirements.toml gerenciado pelo administrador, sem depender das configurações editáveis de usuários ou repositórios. 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." },
]

O exemplo permite dois perfis, exige revisão humana quando uma ação precisa de aprovação, permite uma identidade MCP correspondente e solicita aprovação para um prefixo de comando específico.

Configure o próprio servidor MCP separadamente e adicione os demais padrões de comandos sensíveis da organização. Adicione restrições globais de arquivos e restrições de rede quando necessário. Os requisitos limitam as configurações compatíveis, mas não substituem os controles de identidade, serviços e destinos fora do Codex.

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

Em um cliente piloto, tente selecionar um perfil não permitido, alterar uma configuração restrita de usuário ou projeto e usar uma identidade MCP ausente da lista de permissões. Verifique se cada tentativa é recusada ou se a restrição continua em vigor após reiniciar. Recuse a solicitação de aprovação de um comando de teste e verifique se o comando não é executado.

Adicionar restrições gerenciadas de sistema de arquivos e rede

Para bloquear a leitura de arquivos locais sensíveis em todos os perfis permitidos, adicione a tabela a seguir ao requirements.toml e substitua os exemplos pelos caminhos da sua organização:

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

Quando comandos locais executados no sandbox precisarem de acesso à rede, defina em conjunto um perfil permitido com rede habilitada e os destinos gerenciados:

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"

Use essa política de perfil no lugar do padrão :workspace anterior ou inclua explicitamente os dois nomes de perfil. Não cole chaves ou tabelas duplicadas. Se os comandos não precisarem da rede, mantenha o acesso desabilitado.

Use arquivos inofensivos para verificar o bloqueio dos caminhos exatos e teste destinos aprovados e não aprovados.

No Windows nativo, use também listas de controle de acesso a arquivos, pois a configuração gerenciada deny_read, sozinha, não abrange leituras por subprocessos do shell.

As regras de rede dos comandos locais não controlam outros clientes, aplicativos, conectores nem a execução na nuvem.

Instalar hooks gerenciados pelo administrador e impor seu uso

Peça a um administrador que instale um programa de hook revisado em um diretório gerenciado pelo root, por exemplo, no caminho /etc/codex/hooks/pre_tool_use_policy.py, e impeça que o usuário do Codex altere o arquivo ou seu diretório. Em requirements.toml, habilite os hooks e configure o Codex para ignorar hooks de usuários, projetos, sessões e 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 registra o hook, mas não o instala. Para um teste de integração local no macOS, salve o código a seguir como pre_tool_use_policy.py e peça a um administrador que o instale com os comandos abaixo.

O programa bloqueia apenas o marcador sintético. Antes de depender dessa proteção, substitua a lógica de teste por uma política revisada específica da organização. Confirme se /usr/bin/python3 existe no sistema de destino e ajuste o caminho do interpretador se necessário:

1
2
3
4
5
6
7
8import 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 faça as seguintes verificações:

• Confirme que um comando Bash inofensivo é executado.

• Confirme que um comando que contém CODEX_HOOK_TEST_DENY é bloqueado.

• Verifique se o usuário do Codex não consegue alterar a política nem as dependências.

allow_managed_hooks_only ignora todos os hooks não gerenciados de usuários, projetos, sessões e plugins e pode afetar outros fluxos de trabalho.

A regra de correspondência do Bash não abrange todas as ferramentas nem as entradas fornecidas posteriormente a um processo já em execução. Erros, tempos limite excedidos ou respostas malformadas do hook podem permitir que uma chamada de ferramenta prossiga.

Quando orquestrado na nuvem, o modo Work usa outros manipuladores de hooks compatíveis. Mantenha proteções independentes no sistema operacional e nos serviços. Consulte Hooks gerenciados e comportamento dos hooks.

Proteger a política e sua distribuição

No macOS, um administrador pode implantar um arquivo consolidado e revisado de requisitos em um diretório pertencente ao root e impedir que o usuário do Codex grave no arquivo:

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, use o grupo de administradores apropriado. No Windows, proteja o diretório ProgramData e o arquivo com listas de controle de acesso gerenciadas pelo administrador. Restrinja quem pode alterar a política de MDM ou de nuvem, revise as alterações e guarde 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 que a contém nem o programa de hook gerenciado. Tente aplicar uma configuração de usuário ou projeto menos restritiva, reinicie o Codex e verifique se as restrições continuam em vigor.

Teste cada cliente e ambiente abrangido. Não presuma que todos os clientes carreguem a mesma política.

Verificação

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

• Tente editar a política gerenciada. Resultado esperado: não é possível alterar o arquivo gerenciado.

• Tente enfraquecer uma restrição pela configuração de usuário ou projeto. Resultado esperado: as configurações menos restritivas são recusadas ou continuam sujeitas aos limites impostos.

• Reinicie o cliente e verifique se as restrições continuam em vigor.

Limites

Um usuário ou agente com privilégios suficientes de administrador do host pode conseguir alterar as proteções do ambiente. Configurações editáveis pelo usuário, por si só, não substituem requisitos gerenciados pelo administrador.