Os controles de segurança adequados a um fluxo de trabalho de cibersegurança dependem do modelo, das ações que ele pode executar, dos sistemas que pode acessar e da sensibilidade dos dados envolvidos.
Para a maioria dos fluxos de trabalho com o Daybreak Blue, as práticas de segurança que sua organização já adota, como controle de acesso, proteção de credenciais e revisão de ações sensíveis, podem ser suficientes.
Fluxos de trabalho com o Daybreak Red, testes autônomos de segurança e atividades que envolvem sistemas de produção, dados sensíveis ou ferramentas externas podem exigir proteções mais rigorosas. As recomendações a seguir se destinam principalmente a esses cenários de maior risco.
Cabe a você avaliar os riscos específicos do seu fluxo de trabalho e implementar os controles de segurança adequados. As proteções do modelo e o Trusted Access não substituem as práticas de segurança, monitoramento e supervisão da sua organização.
O Trusted Access controla o acesso aprovado aos modelos, mas não configura seu ambiente nem impõe limites quanto aos sistemas e às ações que receberam aprovação. Sua equipe deve configurar controles adequados de isolamento, permissão, revisão, monitoramento e supervisão humana. Parta do princípio de que o modelo, suas ferramentas e cada sistema conectado podem ser comprometidos. Configure o ambiente para que, mesmo nesse caso, nenhum deles consiga acessar sistemas não autorizados, expor credenciais, desativar proteções ou manter acesso após o término do trabalho.
Isole o ambiente
Execute atividades de segurança ofensiva em um laboratório dedicado ou em uma sandbox. Comece sem acesso irrestrito à internet e sem acesso a sistemas de produção sensíveis, redes corporativas, cargas de trabalho alheias à tarefa ou interfaces de gerenciamento de hosts. Mantenha segredos e credenciais fora de alcance e impeça o acesso persistente e as alterações duradouras nos sistemas, a menos que o trabalho aprovado exija e autorize expressamente esses recursos ou ações.
Para atividades de maior risco ou com menos proteções, use um ambiente novo e com isolamento rigoroso a cada tentativa. Separe os recursos de computação, armazenamento e rede, além das identidades. Ao terminar, destrua o ambiente em vez de redefini-lo ou reutilizá-lo.
Teste os limites de acesso ao sistema de arquivos e à rede antes de iniciar atividades de maior risco. Inclua nos testes todos os hosts acessíveis, ferramentas conectadas, agentes que recebem tarefas delegadas e serviços subsequentes. Mantenha o ambiente do host isolado mesmo quando o modelo ou o revisor aprovar uma ação específica.
Defina e aplique os limites aprovados
Antes de o modelo começar, documente os sistemas, as ferramentas, as ações e os limites de tempo aprovados para o trabalho. Inclua os seguintes itens:
- Sistemas-alvo, hosts e ambientes aprovados.
- Sistemas excluídos, inclusive a infraestrutura de produção e a que não faz parte do trabalho.
- Ferramentas e serviços conectados aprovados.
- Ações aprovadas e proibidas.
- Horários aprovados de início e término e requisitos para o tratamento dos dados.
- Procedimentos de divulgação de vulnerabilidades, aprovação de correções e coordenação com os mantenedores.
- Condições para interromper o trabalho e ações que exigem aprovação humana explícita.
Informe ao agente os limites aprovados como parte do contexto da tarefa. Documentar esses limites, por si só, não garante seu cumprimento. Aplique controles independentes ao sistema de arquivos, à rede, às identidades e às ferramentas para impedir ações não autorizadas sempre que for viável.
Use os perfis de permissão do Codex para limitar os privilégios ao mínimo necessário. Escolha :read-only quando a tarefa não exigir alterações ou estenda :workspace quando for necessário editar arquivos no espaço de trabalho. Por exemplo:
approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = "cyber-lab"
[features]
network_proxy = true
[permissions.cyber-lab]
description = "Limit security testing to the approved lab and workspace."
extends = ":workspace"
[permissions.cyber-lab.filesystem]
glob_scan_max_depth = 3
[permissions.cyber-lab.filesystem.":workspace_roots"]
"**/.env*" = "deny"
"**/*.pem" = "deny"
[permissions.cyber-lab.network]
enabled = true
# Uncomment only for an approved host that resolves to a private address.
# allow_local_binding = true
[permissions.cyber-lab.network.domains]
"lab.example.com" = "allow"O recurso network_proxy restringe o acesso ao domínio aprovado. Sem ele, network.enabled = true permite acesso direto à rede, e a lista de permissões do laboratório não restringe os destinos. A Pesquisa na Web, os aplicativos, os conectores, os servidores MCP, a atividade do navegador e o Codex Cloud têm controles próprios. Restrinja ou desative cada recurso que o fluxo de trabalho aprovado não exigir.
Substitua lab.example.com por um destino aprovado. O limite de profundidade da varredura do sistema de arquivos evita a busca em todo o espaço de trabalho no Linux, no WSL e no Windows. Se houver arquivos sensíveis em níveis mais profundos, aumente a profundidade ou bloqueie os caminhos exatos desses arquivos. Não combine perfis de permissão com configurações antigas de sandbox_mode. Siga as orientações para configurar perfis de permissão.
Se o nome do host aprovado do laboratório resolver para um endereço privado, o Codex bloqueará o acesso por padrão, mesmo que o host esteja na lista de permissões. Defina allow_local_binding = true somente para atividades expressamente aprovadas em redes privadas, limite a lista de destinos permitidos ao estritamente necessário e consulte as orientações sobre redes locais e privadas. Você também pode incluir na lista de permissões o endereço IP privado exato que recebeu aprovação.
Bloqueie por padrão o acesso à internet pública e às redes de produção. Se o acesso externo for necessário, encaminhe o tráfego por um gateway ou proxy que aplique as restrições de forma independente, com listas de permissões restritas, inspeção de solicitações e registro em logs. Aplique as mesmas restrições às conexões indiretas por meio de gerenciadores de pacotes, webhooks, serviços que buscam conteúdo de URLs, redirecionamentos, APIs de nuvem e ferramentas conectadas. Carregue as dependências antes da execução ou use dependências aprovadas por um administrador.
Proteja credenciais e dados sensíveis
Mantenha chaves de API reutilizáveis, credenciais de nuvem, senhas e tokens de contas de serviço fora de prompts, repositórios, variáveis de ambiente, sistemas de arquivos compartilhados e logs acessíveis ao modelo. Quando a autenticação for necessária, use um intermediário de credenciais ou um gateway separado para fornecer credenciais de curta duração, restritas ao destino específico e à ação permitida, sem expô-las ao modelo.
Forneça apenas os dados necessários para a tarefa aprovada. Remova informações sensíveis desnecessárias, bloqueie o acesso aos endpoints de metadados de nuvem e de credenciais e trate os arquivos gerados pelo modelo como não confiáveis.
Evite :danger-full-access e --yolo em fluxos de trabalho de cibersegurança. A Revisão automática depende dos limites impostos pela sandbox. O modo Acesso completo remove esses limites. Organizações com gerenciamento centralizado podem excluir :danger-full-access e --yolo, restringir as políticas de aprovação permitidas e exigir a Revisão automática por meio da configuração gerenciada pela organização.
Antes de ativar o Acesso completo para um modelo de segurança aprovado, o aplicativo do ChatGPT para desktop exibe um aviso específico para esse modelo sobre ações perigosas. O aviso recomenda usar Aprovar por mim como alternativa e inclui um link para a configuração da política do revisor. O aviso não restabelece os limites da sandbox nem se sobrepõe à política da organização.
Use a Revisão automática em conjunto com o isolamento do ambiente, permissões de privilégio mínimo, um escopo de trabalho documentado, monitoramento e supervisão humana.
Revise ações sensíveis do Codex
A Revisão automática encaminha as solicitações de aprovação elegíveis a um revisor separado antes da execução da ação proposta. O revisor leva em conta a ação, o contexto da tarefa e a política aplicável. As organizações podem substituir a política do revisor por outra que especifique quais destinos estão aprovados, quais ações são proibidas e quando a aprovação humana é obrigatória.
Exija aprovação humana explícita para ações que afetem a produção, sistemas externos ou dados sensíveis, ou que envolvam elevação de privilégios, acesso persistente ou alterações irreversíveis. Trate como não confiáveis as instruções contidas em sites, repositórios, documentos e saídas de ferramentas. Elas não podem ampliar o escopo autorizado nem se sobrepor aos controles de acesso.
No aplicativo do ChatGPT para desktop, selecionar um modelo Daybreak aprovado muda automaticamente o controle de permissões para Aprovar por mim quando esse modo está disponível para sua conta e a política da organização permite seu uso. Isso também se aplica quando você usa o comando /model no aplicativo para desktop. Se o modo não estiver disponível, o modo de permissão atual continua em vigor. A seleção do modelo nunca se sobrepõe aos requisitos gerenciados pela organização.
Para que a Revisão automática funcione, mantenha os três controles a seguir:
- Use uma política de aprovação interativa, como
approval_policy = "on-request". - Defina
approvals_reviewer = "auto_review". - Mantenha limites que a sandbox ou o perfil de permissão possa impor.
As solicitações enviadas a um destino que consta na lista de permissões da rede ficam dentro dos limites da rede e não acionam a Revisão automática por si só. Para revisar um comando sensível mesmo quando o destino está na lista de permissões, crie uma regra de comando explícita em ~/.codex/rules/:
prefix_rule(
pattern = ["curl"],
decision = "prompt",
justification = "Review requests to the approved cybersecurity target.",
)Reinicie o Codex depois de adicionar a regra. Com approvals_reviewer = "auto_review", os comandos que correspondem à regra são encaminhados ao revisor antes da execução. Adicione regras que solicitem aprovação para cada comando sensível ou use approval_mode = "prompt" para ferramentas MCP individuais. Ações que dependem da decisão de uma pessoa continuam exigindo aprovação humana explícita.
A Revisão automática avalia as ações que exigem aprovação. Com approval_policy = "never" ou com o modo Acesso completo, uma ação sensível pode ser executada sem que haja uma solicitação de aprovação. Use controles de acesso e monitoramento independentes durante todo o trabalho.
Para definir uma política com escopo delimitado e aplicá-la em toda a organização, consulte Configure um fluxo de trabalho autorizado de cibersegurança.
Monitore de forma independente e bloqueie a execução em caso de falha
Registre as solicitações do modelo, as chamadas de ferramentas, a atividade de rede, o uso de credenciais e as alterações relevantes para a segurança. Mantenha os logs e os sistemas de monitoramento fora do ambiente controlado pelo modelo. Configure alertas para destinos não autorizados, solicitações de rede inesperadas, exposição de credenciais, alterações de política, ausência de logs e tentativas de contornar as proteções.
Mantenha os mecanismos de aplicação de políticas, os intermediários de credenciais, os sistemas de revisão e os controles de desligamento de emergência independentes do agente. Interrompa o fluxo de trabalho se um controle essencial ou um sistema de monitoramento falhar.
Adicione mecanismos de proteção aos fluxos de trabalho personalizados com agentes
Se você desenvolve com a API Responses, o SDK de Agentes ou outro harness, adicione uma etapa de revisão no ponto em que as ferramentas são executadas. Antes da execução, verifique se cada ação sensível proposta está entre as ações aprovadas, se envolve apenas sistemas aprovados e se respeita os limites de tempo. Encaminhe ações ambíguas ou de alto risco a uma pessoa, imponha restrições independentes ao sistema de arquivos e à rede, mantenha logs de auditoria e bloqueie a execução se o revisor ou a política estiver indisponível.
A Revisão automática do Codex não protege automaticamente ferramentas personalizadas nem harnesses externos. Consulte Mecanismos de proteção e revisão humana para ver como implementar a revisão no SDK de Agentes e use a política de código aberto do revisor como referência.
O ambiente isolado e a revisão no Codex são independentes das verificações de cibersegurança da API. As proteções da API podem retornar erros cyber_policy, e valores de safety_identifier específicos para cada usuário podem ajudar a limitar o impacto de uma medida de proteção.
Faça a limpeza e valide os resultados
Ao concluir o trabalho, revogue as credenciais temporárias, encerre os processos em segundo plano, remova os acessos persistentes e destrua os ambientes de maior risco. Confirme que não restam callbacks, artefatos expostos, estado compartilhado nem acesso entre execuções. Mantenha o isolamento entre usuários, entre sessões e entre avaliações.
Valide os resultados antes de agir com base neles, siga as práticas de divulgação coordenada de vulnerabilidades e mantenha responsáveis definidos pelas correções e alterações.
Antes de começar
Confirme quais sistemas e ações estão aprovados e se o modelo é adequado. Verifique o isolamento do ambiente, as permissões de privilégio mínimo, as restrições de acesso à rede, a proteção das credenciais, a revisão das ações, o monitoramento independente, a parada de emergência e o plano de limpeza. As proteções do modelo, o isolamento, as permissões com escopo delimitado, a revisão das ações, o monitoramento e a supervisão humana se complementam. Nenhum deles deve ser o único controle.