Configuração recomendada

Os controlos de segurança adequados a um fluxo de trabalho de cibersegurança dependem do modelo, das ações que este pode realizar, dos sistemas a que pode aceder e da sensibilidade dos dados envolvidos.

Para a maioria dos fluxos de trabalho Daybreak Blue, as práticas de segurança existentes na sua organização — como controlos de acesso, proteção de credenciais e revisão de ações sensíveis — podem ser suficientes.

Os fluxos de trabalho Daybreak Red, os testes de segurança autónomos e as atividades que envolvam sistemas de produção, dados sensíveis ou ferramentas externas podem exigir salvaguardas mais robustas. As recomendações abaixo destinam-se principalmente a estes cenários de maior risco.

O Trusted Access rege o acesso aprovado ao modelo, mas não configura o seu ambiente nem impõe limites aos sistemas e ações aprovados. A sua equipa tem de configurar controlos adequados de isolamento, permissões, revisão, monitorização e supervisão humana. Parta do princípio de que o modelo, as respetivas ferramentas e todos os sistemas ligados podem ser comprometidos e, em seguida, configure o ambiente para que, ainda assim, não possam alcançar sistemas não autorizados, expor credenciais, desativar salvaguardas ou manter persistência após o fim do trabalho.

Isole o ambiente

Execute trabalhos de segurança ofensiva num laboratório ou sandbox dedicado. Comece sem acesso irrestrito à Internet, a sistemas de produção sensíveis, a redes empresariais, a cargas de trabalho não relacionadas ou a interfaces de gestão do sistema anfitrião. Mantenha segredos, credenciais, acesso persistente e alterações duradouras ao sistema fora de alcance, exceto se o trabalho aprovado os exigir e autorizar explicitamente.

Para trabalhos de maior risco ou com salvaguardas reduzidas, utilize um ambiente novo e fortemente isolado em cada tentativa. Separe a computação, o armazenamento, a rede e as identidades e destrua posteriormente o ambiente, em vez de o repor ou reutilizar.

Teste os limites do sistema de ficheiros e da rede antes de iniciar trabalhos de maior risco. Inclua todos os anfitriões acessíveis, ferramentas ligadas, agentes delegados e serviços a jusante. Mantenha o ambiente anfitrião isolado, mesmo quando o modelo ou o revisor aprova uma ação individual.

Defina e imponha os limites aprovados

Antes de o modelo iniciar, documente os sistemas, as ferramentas, as ações e os limites de tempo aprovados para o seu trabalho. Inclua:

• Sistemas, anfitriões e ambientes de destino aprovados.
• Sistemas excluídos, incluindo a produção e infraestruturas não relacionadas.
• Ferramentas e serviços ligados aprovados.
• Ações aprovadas e proibidas.
• Horas de início e fim aprovadas e requisitos de tratamento de dados.
• Divulgação de vulnerabilidades, aprovação de correções e coordenação com os responsáveis pela manutenção.
• Condições de paragem e ações que exijam aprovação humana explícita.

Forneça ao agente estes limites aprovados como contexto da tarefa. A documentação, por si só, não os impõe: aplique controlos independentes ao sistema de ficheiros, à rede, à identidade e às ferramentas para impossibilitar ações não autorizadas sempre que seja viável.

Utilize os perfis de permissões do Codex para criar um limite de privilégio mínimo. Escolha :read-only quando a tarefa não exigir alterações ou expanda :workspace quando o trabalho exigir edições 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"

A funcionalidade network_proxy impõe o domínio aprovado. Sem esta, 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, as aplicações, os conectores, os servidores MCP, a atividade do navegador e a utilização do Codex na cloud usam controlos separados; restrinja ou desative cada superfície de que o seu fluxo de trabalho aprovado não necessite.

Substitua lab.example.com por um destino aprovado. A análise delimitada do sistema de ficheiros foi concebida para evitar a pesquisa de todo o espaço de trabalho no Linux, WSL e Windows; aumente a profundidade ou utilize caminhos exatos de bloqueio caso existam ficheiros sensíveis em níveis mais profundos. Não combine perfis de permissões com definições sandbox_mode antigas; siga as orientações de configuração dos perfis de permissões.

Se o anfitrião de laboratório aprovado resolver para um endereço privado, o Codex bloqueia-o por predefinição, mesmo que o anfitrião esteja na lista de permissões. Defina allow_local_binding = true apenas para trabalhos em redes privadas explicitamente aprovados, mantenha restrita a lista de destinos permitidos e consulte as orientações relativas a redes locais e privadas. Também pode adicionar à lista de permissões o endereço IP privado exato aprovado.

Bloqueie por predefinição o acesso à Internet aberta e à rede de produção. Se for necessário acesso externo, encaminhe-o através de um gateway ou proxy imposto de forma independente, com listas de permissões restritas, inspeção de pedidos e registo. Aplique as mesmas restrições a ligações indiretas através de gestores de pacotes, webhooks, serviços de obtenção de URLs, redirecionamentos, APIs de cloud e ferramentas ligadas. Carregue as dependências antes da execução ou utilize dependências aprovadas por um administrador.

Proteja as credenciais e os dados sensíveis

Mantenha API keys reutilizáveis, credenciais de cloud, palavras-passe e tokens de contas de serviço fora dos pedidos, repositórios, variáveis de ambiente, sistemas de ficheiros partilhados e registos acessíveis ao modelo. Quando for necessária autenticação, utilize um broker ou gateway separado para fornecer credenciais de curta duração, limitadas ao destino exato e à ação permitida, sem expor a credencial ao modelo.

Forneça apenas os dados necessários à tarefa aprovada. Remova informações sensíveis desnecessárias, bloqueie o acesso a metadados de cloud e a endpoints de credenciais e trate os ficheiros gerados pelo modelo como não fidedignos.

Evite :danger-full-access e --yolo em fluxos de trabalho de cibersegurança. O Full Access remove o limite de sandbox que a revisão automática exige para poder ser imposto. As organizações geridas podem excluir :danger-full-access e --yolo, limitar as políticas de aprovação permitidas e exigir revisão automática através da configuração gerida pela empresa.

Antes de ativar o Full Access para um modelo de segurança aprovado, a aplicação ChatGPT para computador apresenta um aviso específico do modelo sobre ações perigosas. O aviso recomenda antes Approve for me e inclui uma ligação para a configuração da política do revisor. O aviso não repõe o limite de sandbox nem substitui a política da organização.

As medidas de proteção acrescentam uma revisão baseada em políticas a um fluxo de trabalho de cibersegurança controlado. Não substituem o isolamento do ambiente, as permissões de privilégio mínimo, os limites claramente definidos, a monitorização ou a supervisão humana.

Reveja as ações sensíveis do Codex

A Auto-review encaminha os pedidos de aprovação elegíveis relativos aos limites de sandbox para um revisor separado antes de a ação proposta ser executada. O revisor considera a ação proposta, o contexto delimitado da tarefa e a política aplicável e, em seguida, permite ou recusa o pedido. As organizações podem personalizar essa política de acordo com os seus destinos aprovados, ações proibidas e condições obrigatórias de revisão humana.

Exija aprovação humana explícita para ações que afetem a produção, sistemas externos, dados sensíveis, elevação de privilégios, acesso persistente ou alterações irreversíveis. Trate como não fidedignas as instruções incorporadas em sites, repositórios, documentos e resultados de ferramentas; estas não podem alargar o âmbito autorizado nem substituir os controlos de acesso.

Na aplicação ChatGPT para computador, selecionar um modelo Daybreak aprovado muda automaticamente o controlo de permissões para Approve for me quando esse modo estiver disponível para a sua conta e for permitido pela política da organização. Isto também se aplica quando utiliza o comando /model da aplicação para computador. Se esse modo não estiver disponível, o modo de permissões atual permanece inalterado. A seleção do modelo nunca substitui os requisitos geridos da organização.

Para que a revisão automática seja executada, mantenha os três controlos seguintes:

1. Utilize uma política de aprovação interativa, como approval_policy = "on-request".
2. Defina approvals_reviewer = "auto_review".
3. Mantenha um limite de sandbox ou de perfil de permissões que possa ser imposto.

Os pedidos para um destino incluído na lista de permissões da rede permanecem dentro dos limites da rede e não acionam automaticamente a Auto-review. Para rever um comando sensível mesmo quando o respetivo destino consta da lista de permissões, crie uma regra de comandos 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 correspondentes são enviados ao revisor antes da execução. Adicione regras de pedidos correspondentes para cada comando sensível ou utilize approval_mode = "prompt" para ferramentas MCP individuais. As ações que exigem a decisão de uma pessoa continuam a necessitar de aprovação humana explícita.

A Auto-review não inspeciona ações de rotina que já são permitidas dentro da sandbox. Com approval_policy = "never" ou Full Access, uma ação sensível pode não criar um pedido de aprovação passível de revisão. A revisão automática pode cometer erros e não substitui o isolamento, os limites claramente definidos, a monitorização ou a supervisão humana explícita.

Para obter uma política delimitada e a respetiva aplicação em toda a organização, consulte Configurar um fluxo de trabalho de cibersegurança autorizado.

Monitorize de forma independente e bloqueie em caso de falha

Registe os pedidos ao modelo, as chamadas de ferramentas, a atividade de rede, a utilização de credenciais e as alterações relevantes para a segurança. Mantenha os registos e os sistemas de monitorização fora do ambiente controlado pelo modelo. Emita alertas para destinos não autorizados, pedidos de rede inesperados, credenciais expostas, alterações de políticas, registos em falta e tentativas de contornar as salvaguardas.

Mantenha a aplicação de políticas, os brokers de credenciais, os sistemas de revisão e os controlos de encerramento de emergência independentes do agente. Interrompa o fluxo de trabalho se um controlo ou sistema de monitorização essencial falhar.

Adicione medidas de proteção a fluxos de trabalho de agentes personalizados

Se desenvolver com a Responses API, o Agents SDK ou outro harness, adicione a revisão no limite de execução das ferramentas. Antes da execução, verifique as ações sensíveis propostas relativamente aos sistemas, ações e limites de tempo aprovados; encaminhe ações ambíguas ou de alto risco para uma pessoa; imponha restrições independentes ao sistema de ficheiros e à rede; mantenha registos de auditoria; e bloqueie em caso de falha se o revisor ou a política não estiver disponível.

A Auto-review do Codex não protege automaticamente ferramentas personalizadas ou harnesses externos. Utilize Medidas de proteção e revisão humana para o padrão do Agents SDK e a política de revisor de código aberto como referência.

A sandbox e a revisão no lado do produto Codex são distintas das verificações de cibersegurança da API. As salvaguardas da API podem devolver erros cyber_policy, e os valores safety_identifier por utilizador podem ajudar a limitar o impacto de uma ação de salvaguarda.

Efetue a limpeza e valide os resultados

Após a conclusão do trabalho, revogue as credenciais temporárias, termine os processos em segundo plano, remova o acesso persistente e destrua os ambientes de maior risco. Verifique se não restam callbacks, artefactos expostos, estado partilhado ou acesso entre execuções e mantenha utilizadores, sessões e avaliações distintos isolados.

Valide as conclusões antes de agir sobre elas, siga práticas de divulgação coordenada e mantenha as pessoas responsáveis pela correção e pelas alterações.

Antes de começar

Confirme os sistemas e as ações aprovados, o modelo adequado, o ambiente isolado, as permissões de privilégio mínimo, o acesso restrito à rede, as credenciais protegidas, a revisão de ações, a monitorização independente, a paragem de emergência e o plano de limpeza. As salvaguardas do modelo, o isolamento, as permissões delimitadas, a revisão de ações, a monitorização e a supervisão humana são complementares; nenhum destes elementos deve ser o único controlo.