Revisão automática

A revisão automática substitui a aprovação manual nos limites da sandbox por um agente revisor separado. O agente Codex principal continua a ser executado dentro da mesma sandbox, com a mesma política de aprovação e os mesmos limites de rede e do sistema de ficheiros. A diferença reside em quem analisa os pedidos de elevação elegíveis.

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 está disponível para a sua conta e é 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.

Antes de ativar 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 Approve for me como alternativa e inclui uma ligação para a configuração da política do revisor. O aviso não repõe o limite da sandbox nem substitui a política da organização.

Como funciona a revisão automática

Em termos gerais, o fluxo é o seguinte:

1. O agente principal trabalha dentro de read-only ou workspace-write.
2. Quando precisa de ultrapassar os limites da sandbox, solicita aprovação.
3. Se approvals_reviewer = "auto_review", o Codex encaminha esse pedido de aprovação para um agente revisor separado, em vez de parar para aguardar uma pessoa.
4. O revisor decide se a ação deve ser executada e apresenta uma justificação.
5. Se a ação for aprovada, a execução prossegue. Se for recusada, o agente principal recebe instruções para encontrar uma abordagem substancialmente mais segura ou parar e pedir orientação ao utilizador.

A revisão automática substitui o revisor, não concede permissões. Não expande writable_roots, não ativa o acesso à rede nem reduz a proteção dos caminhos protegidos. Apenas altera a forma como o Codex trata ações que já necessitam de aprovação.

Quando é acionada

A revisão automática avalia pedidos de aprovação que, de outro modo, interromperiam o fluxo à espera de uma pessoa. Estes incluem:

• Chamadas a ferramentas de shell ou de execução que solicitam permissões elevadas da sandbox.
• Pedidos de rede bloqueados pela sandbox ou política atual.
• Edições de ficheiros fora das raízes com permissão de escrita.
• Chamadas a ferramentas MCP ou de aplicações que necessitam de aprovação com base nas respetivas anotações ou no modo de aprovação configurado.
• Acesso do Computer Use a um novo site ou domínio.

A revisão automática não é executada para ações de rotina já permitidas dentro da sandbox. Se um comando puder ser executado ao abrigo do sandbox_mode ativo, ou uma chamada de ferramenta permanecer dentro da política permitida, o agente principal prossegue sem revisão.

O Computer Use constitui um caso distinto. As aprovações de aplicações para o Computer Use continuam a ser apresentadas diretamente ao utilizador, pelo que a revisão automática não substitui esses pedidos ao nível da aplicação.

O que a revisão automática bloqueia

Em termos gerais, a revisão automática foi concebida para bloquear ações como:

• enviar dados privados, segredos ou credenciais para destinos não fidedignos
• procurar credenciais, tokens, cookies ou material de sessão
• enfraquecer a segurança de forma abrangente ou persistente
• realizar ações destrutivas com risco significativo de danos irreversíveis

A política exata encontra-se no repositório Codex de código aberto: policy_template.md e policy.md. Essa política pode ser personalizada por empresa com guardian_policy_config ou por utilizador com um [auto_review].policy local.

O que o revisor vê

O próprio revisor é um agente Codex com uma função mais restrita do que a do agente principal: decidir se uma ação específica que ultrapassa os limites deve ser executada.

O revisor vê uma transcrição compacta, juntamente com o pedido de aprovação exato. Esta inclui normalmente mensagens do utilizador, atualizações do assistente apresentadas, chamadas a ferramentas relevantes e resultados das ferramentas, bem como a ação agora proposta para aprovação. Também pode realizar verificações apenas de leitura para obter contexto em falta, embora raramente o faça.

O raciocínio oculto do assistente não é incluído. A revisão automática vê os elementos retidos da conversa e os elementos de prova das ferramentas, não a cadeia de raciocínio privada.

Recusas e comportamento em caso de falha

Uma recusa explícita não é tratada como um erro normal da sandbox. O Codex devolve a justificação da revisão ao agente principal e acrescenta uma instrução mais rigorosa:

• Não tentar alcançar o mesmo resultado através de uma solução alternativa, execução indireta ou evasão da política.
• Prosseguir apenas com uma alternativa substancialmente mais segura.
• Caso contrário, parar e pedir orientação ao utilizador.

O Codex também aplica um disjuntor de recusas por turno. Na implementação atual de código aberto, a revisão automática interrompe o turno após 3 recusas consecutivas ou 10 recusas numa janela deslizante das últimas 50 revisões no mesmo turno.

Qualquer resultado que não seja uma recusa repõe o contador de recusas consecutivas. Quando o disjuntor é acionado, o Codex emite um aviso e cancela o turno atual com uma interrupção, em vez de permitir que o agente entre num ciclo de novas tentativas de elevação.

Os tempos limite são apresentados separadamente das recusas explícitas, e o agente principal é informado de que um tempo limite, por si só, não prova que a ação não é segura.

Existe também um caminho explícito de substituição para ações recusadas. Na TUI atual de código aberto, execute /approve para abrir o seletor Recusas da revisão automática e, em seguida, selecione uma ação recusada recentemente para a aprovar para uma nova tentativa. O Codex regista até 10 recusas recentes por tarefa. Essa aprovação é restrita: aplica-se à ação recusada exata, não a ações futuras semelhantes; é registada para uma nova tentativa no mesmo contexto; e a nova tentativa continua a passar pela revisão automática. Internamente, o Codex injeta um marcador de aprovação no âmbito do programador para essa ação exata. O revisor vê então essa substituição explícita pelo utilizador como contexto, mas continua a seguir a política e pode recusar novamente se a política determinar que o utilizador não pode substituir essa categoria de recusa.

Configuração

Para obter detalhes sobre a configuração, consulte Configuração gerida.

A política predefinida do revisor encontra-se no repositório Codex de código aberto: core/src/guardian/policy.md. As empresas podem substituir a respetiva secção específica do inquilino por guardian_policy_config nos requisitos geridos. Os utilizadores individuais também podem definir um [auto_review].policy local no respetivo config.toml, mas os requisitos geridos têm precedência:

[auto_review]
policy = """
YOUR POLICY GOES HERE
"""

Para personalizar a política, copie primeiro todo o texto da política predefinida e, em seguida, ajuste-o iterativamente com base no seu perfil de risco individual.

Configurar uma intervenção de cibersegurança autorizada

Para trabalhos de segurança autorizados, combine a revisão automática com um âmbito de intervenção definido por escrito e um perfil de permissões com o mínimo de privilégios. Utilize um alvo de laboratório aprovado, documente as ações e o período da intervenção e mantenha fora do âmbito os sistemas de produção, os anfitriões não relacionados, as credenciais e as alterações persistentes, salvo autorização explícita.

Tanto [auto_review].policy como guardian_policy_config substituem a sua política do revisor atual. Não são combinados com políticas incluídas no seu modelo ou geridas pela sua organização. As instruções de revisão e o formato de resposta incorporados continuam a aplicar-se. Antes de utilizar qualquer um dos exemplos, copie a política atual completa, mantenha todas as regras existentes e adicione as regras para o seu trabalho aprovado. Substitua o marcador de posição em maiúsculas por essa política completa. Se não conseguir aceder à política atual, não a substitua.

O seguinte modelo local de config.toml ativa a revisão e adiciona condições específicas após a política do revisor existente:

approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = ":workspace"

[auto_review]
policy = """
PASTE THE COMPLETE ACTIVE REVIEWER POLICY HERE BEFORE USING THIS EXAMPLE.

## Environment Profile
- Authorized target: lab.example.com.
- Approved actions: inspect the target, reproduce authorized vulnerabilities,
  and validate fixes within the documented engagement window.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Allow only actions against the approved target that match the documented
  engagement scope and approved actions.
- Deny out-of-scope or unknown hosts, production access, credential theft,
  persistence, data exfiltration, destructive operations, and policy bypass.
- Deny ambiguous actions and high-impact changes until a human explicitly
  approves the exact target, action, and side effects.
"""

Substitua o alvo e as ações permitidas do exemplo pelo âmbito efetivamente aprovado. Imponha restrições ao alvo através de regras independentes do sistema de ficheiros e da rede; as instruções do revisor não substituem esses limites.

As organizações podem impor as mesmas condições num requirements.toml gerido:

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
default_permissions = ":workspace"

guardian_policy_config = """
PASTE THE COMPLETE ACTIVE REVIEWER POLICY HERE BEFORE USING THIS EXAMPLE.

## Environment Profile
- Authorized target: lab.example.com.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Allow only approved actions against the documented engagement target.
- Deny out-of-scope hosts, production access, credential theft, persistence,
  data exfiltration, destructive operations, and attempts to bypass policy.
- Deny ambiguous or high-impact actions until a human explicitly approves the
  exact target, action, and side effects.
"""

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# ":danger-full-access" is omitted, so it is denied.

allowed_permission_profiles controla os perfis de permissões atuais. allowed_sandbox_modes também impede o acesso total em implementações que ainda utilizam o sandbox_mode legado.

O guardian_policy_config gerido tem precedência sobre o [auto_review].policy local de um utilizador. Mantenha approval_policy = "on-request" ou outra política de aprovação interativa elegível e mantenha um limite de sandbox que possa ser imposto. Com approval_policy = "never", :danger-full-access ou --yolo, uma ação pode evitar a criação do pedido de aprovação para atravessar o limite exigido pela revisão.

Um destino de rede incluído na lista de permissões não aciona, por si só, uma revisão. Adicione regras de comandos explícitas com decision = "prompt" ou configure ferramentas MCP sensíveis para exigirem aprovação quando as ações dentro da sandbox ainda tiverem de ser encaminhadas para o revisor.

Consulte Modelos e Trusted Access e a configuração recomendada para obter informações sobre o acesso a modelos, a configuração das operações e os fluxos de trabalho de agentes personalizados. Consulte Configuração gerida para conhecer a precedência empresarial e as versões de clientes suportadas. Para mecanismos personalizados de API ou do Agents SDK, utilize Guardrails e revisão humana.

Reduzir o volume de revisões sem enfraquecer a segurança

A revisão automática funciona melhor quando a sandbox já abrange os seus fluxos de trabalho seguros habituais. Se demasiadas ações rotineiras necessitarem de revisão, corrija primeiro os limites, em vez de ensinar o revisor a aprovar continuamente elevações desnecessárias.

Na prática, as alterações com maior impacto são:

• Adicionar writable_roots restritas para diretórios temporários ou repositórios adjacentes que utiliza intencionalmente.
• Adicionar regras de prefixo de âmbito restrito. Prefira prefixos de comandos precisos, como ["cargo", "test"] ou ["pnpm", "run", "lint"], a padrões abrangentes, como ["python"] ou ["curl"]. As regras abrangentes eliminam frequentemente os próprios limites que a revisão automática se destina a proteger.

Por predefinição, as transcrições das sessões de revisão automática são conservadas em ~/.codex/sessions, pelo que pode pedir ao Codex para analisar o tráfego anterior nesse local antes de alterar a política ou as permissões.

Limites

A revisão automática melhora o ponto de funcionamento predefinido para trabalho autónomo de longa duração, mas não constitui uma garantia de segurança determinística.

• Avalia apenas ações que solicitam a ultrapassagem de um limite.
• Pode ainda cometer erros, especialmente em contextos adversos ou invulgares.
• Deve complementar, e não substituir, uma boa conceção da sandbox, a monitorização e a política específica da organização.

Para consultar a fundamentação da investigação e os resultados de avaliação publicados, consulte a publicação da Alignment Research sobre a revisão automática.