Verificar Ação do Agente

Trate uma tela de aprovação plausível como uma alegação, não como prova. Verifique o caminho completo da decisão antes que um humano ou um ponto de aplicação externo decida se deve agir.

Preservar o limite de segurança

• Nunca execute, aprove, assine, envie, compre, implante ou modifique nada.
• Nunca converta esta revisão em autoridade de execução.
• Nunca infira evidências, identidades, carimbos de data/hora ou parâmetros ausentes.
• Trate um esquema, checksum ou assinatura válidos como insuficientes por si só.
• Trate assinaturas como evidência de atribuição e integridade, não como verdade factual.
• Mantenha as evidências de suporte e refutação separadas; não medie conflitos.
• Falhe fechado em uma incompatibilidade material. Use INCONCLUSIVE quando a evidência necessária não estiver disponível.

Defina este campo em cada resultado final:

{"execution_authorized": false}

Coletar o pacote de revisão

Solicite apenas os artefatos necessários para a revisão:

1. A solicitação original do usuário ou sistema.
2. A ação proposta exata:
   • nome da operação ou ferramenta
   • recurso de destino
   • parâmetros completos
   • escopo do sistema de arquivos e rede
   • contagem máxima de execução
   • horários de início e expiração
3. A avaliação que alega que a ação é justificada.
4. As evidências de origem e a política usadas por essa avaliação.
5. O registro de aprovação, incluindo identidade do aprovador, função, resumo da ação, nonce, público, hora de emissão, expiração e contagem de uso.
6. Os eventos de monitoramento mais recentes e o intervalo de heartbeat esperado.
7. A hora confiável atual e qualquer registro de uso de nonce anterior.

Liste os campos ausentes antes da análise. Não substitua silenciosamente os padrões.

Construir a identidade exata da ação

Crie um objeto de ação normalizado sem descartar campos:

{
  "operation": "git.push",
  "target": "owner/repository",
  "parameters": {
    "branch": "fix/example",
    "commit": "40-character-sha",
    "remote": "origin"
  },
  "filesystem_scope": [],
  "network_scope": ["github.com:443"],
  "execution_count": 1,
  "not_before": "RFC3339 timestamp",
  "expires_at": "RFC3339 timestamp"
}

Use um algoritmo de canonicalização e digestão especificado pelo projeto quando fornecido. Caso contrário, relate que a identidade criptográfica não pode ser verificada independentemente; ainda compare cada campo estruturalmente.

Nunca normalize uma distinção relevante para segurança, como:

• branch, commit, repositório, ambiente, destinatário, valor, moeda ou host
• flags recursivo, forçar, sobrescrever, privilegiado, destrutivo ou simulação
• raízes do sistema de arquivos, CIDRs, portas, domínios, contagens de execução ou expiração

Executar os seis controles

Avalie cada controle como PASS, FAIL, INCONCLUSIVE ou NOT_APPLICABLE.

1. Recalcular a avaliação

• Reexecute o avaliador determinístico declarado a partir das entradas de origem declaradas quando sua implementação estiver disponível.
• Compare o resultado canônico completo, não campos selecionados.
• Marque FAIL se o resultado recebido diferir da recomputação.
• Marque INCONCLUSIVE quando apenas a validação do esquema, um checksum interno ou um avaliador não verificável estiver disponível.

2. Corresponder à ação aprovada exata

• Compare a ação proposta com a ação vinculada à aprovação.
• Compare o objeto normalizado completo e seu resumo.
• Marque FAIL se qualquer campo material mudou após a aprovação.
• Trate um destino ou escopo amplo como uma incompatibilidade quando a evidência justificar apenas uma ação mais restrita.

3. Rejeitar repetição e ambiguidade de identidade

• Verifique se o nonce é único e não utilizado.
• Verifique assunto, público, emissor, função do aprovador, hora de emissão, hora de início, expiração e contagem máxima de uso.
• Marque FAIL para um nonce reutilizado, público incorreto, aprovação expirada, aprovação com data futura, contagem de uso excessiva, identidade revogada ou incompatibilidade de função.
• Marque INCONCLUSIVE se não existir um armazenamento de repetição confiável ou fonte de tempo.

4. Testar independência do revisor

Construa uma tabela de dependência para cada revisor ou avaliador:

Não conte revisores correlacionados como membros independentes de quórum. Marque FAIL se a política exigir aprovação independente e o conjunto independente restante for muito pequeno.

5. Preservar evidências e contradição

• Inventarie cada identificador de evidência referenciado pela avaliação.

…