Vérifier l'action d'un agent

Traiter un écran d'approbation plausible comme une réclamation, non comme une preuve. Vérifier le chemin de décision complet avant qu'un humain ou un point d'application externe décide d'agir.

Préserver la limite de sécurité

• Ne jamais exécuter, approuver, signer, envoyer, acheter, déployer, ou muter quoi que ce soit.
• Ne jamais convertir cet examen en autorité d'exécution.
• Ne jamais déduire des preuves manquantes, des identités, des timestamps, ou des paramètres.
• Traiter un schéma valide, une somme de contrôle, ou une signature comme insuffisante en elle-même.
• Traiter les signatures comme preuve d'attribution et d'intégrité, non comme vérité factuelle.
• Garder les preuves soutenant et réfutant séparées ; ne pas faire disparaître les conflits par moyenne.
• Échouer fermé sur une discordance matérielle. Utiliser INCONCLUSIVE quand la preuve requise n'est pas disponible.

Définir ce champ dans chaque résultat final :

{"execution_authorized": false}

Collecter le paquet d'examen

Ne demander que les artéfacts nécessaires pour l'examen :

1. La demande utilisateur ou système originale.
2. L'action proposée exacte :
   • nom de l'opération ou de l'outil
   • ressource cible
   • paramètres complets
   • portée du système de fichiers et du réseau
   • nombre d'exécutions maximal
   • heures de non-avant et d'expiration
3. L'évaluation qui affirme que l'action est justifiée.
4. La preuve source et la politique utilisées par cette évaluation.
5. L'enregistrement d'approbation, incluant l'identité de l'approbateur, le rôle, le résumé de l'action, le nonce, l'audience, l'heure d'émission, l'expiration, et le nombre d'utilisations.
6. Les derniers événements de monitoring et l'intervalle de heartbeat attendu.
7. L'heure fiable courante et tout enregistrement d'utilisation de nonce antérieur.

Lister les champs manquants avant l'analyse. Ne pas substituer silencieusement les valeurs par défaut.

Construire l'identité exacte de l'action

Créer un objet action normalisé unique sans supprimer de champs :

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

Utiliser un algorithme de canonicalisation et de digest spécifié au projet quand fourni. Sinon, rapporter que l'identité cryptographique ne peut pas être vérifiée indépendamment ; néanmoins comparer chaque champ structurellement.

Ne jamais normaliser une distinction pertinente pour la sécurité comme :

• branche, commit, repository, environnement, destinataire, montant, devise, ou hôte
• flags récursif, force, overwrite, privileged, destructive, ou dry-run
• racines du système de fichiers, CIDRs, ports, domaines, nombres d'exécutions, ou expiration

Exécuter les six contrôles

Évaluer chaque contrôle comme PASS, FAIL, INCONCLUSIVE, ou NOT_APPLICABLE.

1. Recalculer l'évaluation

• Réexécuter l'évaluateur déterministe déclaré à partir des entrées source déclarées quand son implémentation est disponible.
• Comparer le résultat canonique complet, pas les champs sélectionnés.
• Marquer FAIL si le résultat reçu diffère du recalcul.
• Marquer INCONCLUSIVE quand seule la validation de schéma, une somme de contrôle interne, ou une réclamation d'évaluateur non vérifiable est disponible.

2. Correspondre à l'action approuvée exacte

• Comparer l'action proposée avec l'action liée dans l'approbation.
• Comparer l'objet normalisé complet et son digest.
• Marquer FAIL si un champ matériel quelconque a changé après approbation.
• Traiter une cible ou une portée large comme une discordance quand la preuve ne justifie qu'une action plus étroite.

3. Rejeter la relecture et l'ambiguïté d'identité

• Vérifier que le nonce est unique et inutilisé.
• Vérifier le sujet, l'audience, l'émetteur, le rôle de l'approbateur, l'heure d'émission, l'heure de non-avant, l'expiration, et le nombre d'utilisations maximal.
• Marquer FAIL pour un nonce réutilisé, une mauvaise audience, une approbation expirée, une approbation datée du futur, un nombre d'utilisations excessif, une identité révoquée, ou une discordance de rôle.
• Marquer INCONCLUSIVE si aucun magasin de relecture fiable ou source de temps fiable n'existe.

4. Tester l'indépendance des examinateurs

Construire un tableau de dépendance pour chaque examinateur ou évaluateur :

Ne pas compter les examinateurs corrélés comme membres du quorum indépendants. Marquer FAIL si la politique requiert une approbation indépendante et que l'ensemble indépendant restant est trop petit.

5. Préserver la preuve et la contradiction

• Inventorier chaque identifiant de preuve référencé par l'évaluation.
• Confirmer que chaque élément est présent, authentifiable, dans sa fenêtre de validité, et pertinent à la réclamation.
• Enregistrer le soutien et la réfutation indépendamment :

• Marquer FAIL si la preuve a été supprimée, altérée, expirée, ou cachée d'une manière qui change le résultat.
• Ne jamais convertir CONFLICTED en moyenne numérique qui semble sûre.

6. Vérifier le cycle de vie et le monitoring

• Confirmer que l'action se situe dans sa fenêtre de validité.
• Vérifier les signatures d'événements de monitoring ou la preuve d'intégrité quand disponible.
• Vérifier les numéros de séquence, les digests d'événements antérieurs, et la cadence de heartbeat attendue.
• Traiter les données de télémétrie manquantes, obsolètes, réordonnées, ou en chaîne cassée comme un échec quand la politique requiert un monitoring continu.
• Ne pas interpréter le silence comme une santé.

Contester les conclusions pratiques

Avant de produire le résultat final, tenter ces mutations mentalement ou avec des fixtures de test fournies par le projet :

1. Remplacer une évaluation bloquée par un résultat autorisé.
2. Changer une cible approuvée, un paramètre, une portée, un montant, ou un commit.
3. Réutiliser un nonce d'approbation autrement valide.
4. Remplacer les examinateurs indépendants par des copies corrélées.
5. Supprimer un élément de preuve réfutant.
6. Arrêter le heartbeat de monitoring après approbation.

Si une mutation quelconque passerait les contrôles révisés, enregistrer le contrôle affecté comme FAIL ; ne pas simplement recommander un durcissement futur.

Déterminer le résultat de l'examen

Utiliser exactement un résultat :

• ELIGIBLE_FOR_HUMAN_DECISION : tous les contrôles requis passent.
• ELIGIBLE_WITH_CONTROLS : aucun contrôle requis n'échoue, et des contrôles externes explicites peuvent résoudre les conditions listées avant l'exécution.
• BLOCKED : au moins un contrôle requis échoue ou l'action dépasse la portée justifiée.
• INCONCLUSIVE : aucun contrôle requis n'est prouvé faux, mais la preuve nécessaire pour une décision sûre est manquante ou non vérifiable.

ELIGIBLE_FOR_HUMAN_DECISION n'est pas une approbation. Une autorité humaine et un point d'application séparé restent responsables de toute action réelle.

Rapporter dans ce format

# Agent Action Review

## Result
- Review result: BLOCKED | INCONCLUSIVE | ELIGIBLE_WITH_CONTROLS |
  ELIGIBLE_FOR_HUMAN_DECISION
- Execution authorized: false
- Exact action digest: <verified value or NOT_VERIFIED>

## Action
- Operation:
- Target:
- Material parameters:
- Scope:
- Validity window:
- Maximum uses:

## Control matrix
| Control | Status | Evidence | Reason |
|---|---|---|---|
| Recomputed assessment | PASS/FAIL/INCONCLUSIVE/N/A | ... | ... |
| Exact action binding | ... | ... | ... |
| Replay and identity | ... | ... | ... |
| Reviewer independence | ... | ... | ... |
| Evidence completeness | ... | ... | ... |
| Monitoring freshness | ... | ... | ... |

## Supporting evidence
- ...

## Refuting evidence and defeaters
- ...

## Required next action
- State the smallest concrete step that could change the result.

## Boundaries
- State what this review did not prove.

Commencer par le résultat et la raison exacte. Préférer un bloqueur reproductible à un score de confiance.