review-agent-governance — Configuration

Soumettre les actions de révision des agents IA (revues de PR, commentaires, fusions, éditions CI) à une approbation humaine explicite. Chaque tentative, approuvée ou refusée, produit un reçu signé en Ed25519.

Quand utiliser ce plugin

Installez-le dans les projets où un agent Claude Code :

• Révise, commente ou fusionne des pull requests (gh pr review, gh pr merge)
• Trie les issues (gh issue comment, gh issue close)
• Publie des releases (gh release create)
• Modifie la configuration CI (.github/workflows/, .gitlab-ci.yml)
• Pousse vers des branches protégées (main, master, release, production)
• Poste sur des surfaces de notification externes (webhooks Slack, Discord)

Si l'agent ne fait que des éditions locales et exécute des tests, ce plugin est excessif. Utilisez protect-mcp pour l'application de politique générale des appels d'outils et ignorez celui-ci.

Configuration unique

1. Installer le plugin

claude plugin install wshobson/agents/review-agent-governance

2. Copier la politique par défaut dans votre projet

cp .claude/plugins/review-agent-governance/policies/review-agent-governance.cedar \
   ./review-governance.cedar

Vous pouvez éditer ce fichier pour adapter les règles à votre projet. Voir ../agents/review-policy-author.md pour des conseils sur la rédaction de politiques de révision.

3. Créer un répertoire de reçus et une clé de signature

mkdir -p ./review-receipts
echo "./review-receipts/" >> .gitignore
echo "./review-governance.key" >> .gitignore
echo "./.review-approved" >> .gitignore

Le premier appel de protect-mcp sign crée la clé. Committez la clé publique du premier reçu pour que les auditeurs puissent vérifier plus tard.

Workflow par session

La politique Cedar refuse inconditionnellement les actions sur les surfaces de révision. Pour approuver une action spécifique, ouvrez une fenêtre d'approbation avant et fermez-la après.

Fichier flag (plus simple)

# Avant l'action que vous voulez approuver
touch ./.review-approved

# Laisser Claude Code exécuter la révision / le commentaire / la fusion

# Immédiatement après
rm ./.review-approved

Commande slash (dans Claude Code)

/approve-review "Reviewing PR #123 authored by contributor X"

Cela crée ./.review-approved avec la raison fournie intégrée comme note, et écrit un reçu approuvé par un humain dans la chaîne. Un rm ultérieur est nécessaire pour fermer la fenêtre.

Dry-run de tout (forcer l'évaluation complète de la politique)

Si vous voulez que chaque appel d'outil passe par Cedar sans contournement d'approbation :

export REVIEW_APPROVAL_FLAG=./.never-approve

Tout appel d'outil correspondant à une règle forbid sera refusé ; les fenêtres approuvées n'ont aucun effet. Utile pour CI ou pour une exécution d'audit verrouillée.

Vérifier la chaîne

Lister tous les reçus :

ls -la ./review-receipts/

Vérifier la chaîne complète hors ligne :

npx @veritasacta/verify ./review-receipts/*.json

Exit 0 signifie que chaque reçu est authentique et la chaîne est intacte. Exit 1 signifie qu'un reçu a été modifié. Exit 2 signifie qu'un reçu est malformé.

Consulter les refus récents :

/list-pending

Dans Claude Code, cette commande slash parcourt la chaîne de reçus et affiche les entrées decision: deny récentes avec le nom de l'outil, le motif de la commande et l'horodatage.

Exemple : approuver une revue de PR

# 1. L'humain revoit le commentaire proposé par l'agent
$ /list-pending
  Recent denials:
  - 2026-04-17T14:23:01Z  Bash "gh pr review 42 --approve --body 'LGTM'"
  - 2026-04-17T14:23:02Z  Bash "gh pr comment 42 --body 'Looking good'"

# 2. L'humain décide que le premier est approprié et l'approuve
$ /approve-review "Approving LGTM on PR 42 after visual inspection"
  ./.review-approved created

# 3. L'agent réessaie l'action ; cette fois elle réussit
$ agent: gh pr review 42 --approve --body "LGTM"
  [receipt: rec_XXX, decision=allow, reason=human_approved]

# 4. L'humain ferme la fenêtre
$ rm ./.review-approved

Chaque étape est dans la chaîne de reçus. La chaîne est vérifiable hors ligne pour les régulateurs, les contreparties ou les auditeurs en aval qui veulent confirmer qu'aucune action de révision n'a contourné la porte humaine.

Composition avec protect-mcp

Si les deux plugins sont installés, exécutez-les côte à côte :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": ".*",
        "hooks": [
          {
            "type": "command",
            "command": "npx protect-mcp@0.5.5 evaluate --policy ./protect.cedar --tool \"$TOOL_NAME\" --input \"$TOOL_INPUT\" --fail-on-missing-policy false"
          }
        ]
      },
      {
        "matcher": ".*",
        "hooks": [
          {
            "type": "command",
            "command": "if [ -f ./.review-approved ]; then exit 0; fi; npx protect-mcp@0.5.5 evaluate --policy ./review-governance.cedar --tool \"$TOOL_NAME\" --input \"$TOOL_INPUT\" --fail-on-missing-policy false"
          }
        ]
      }
    ]
  }
}

Les deux hooks doivent passer pour que l'appel d'outil proceed. Un Cedar deny dans l'une ou l'autre politique le bloque.

Standards

• Ed25519 — RFC 8032 (signatures numériques)
• JCS — RFC 8785 (canonicalisation JSON déterministe)
• Cedar — langage de politique d'autorisation ouvert d'AWS
• IETF draft — draft-farley-acta-signed-receipts