Human Gate validation humaine

Le problème #

Le « humain dans la boucle » d’aujourd’hui est soit un flot interminable de demandes, soit rien du tout. Anthropic indique que les utilisateurs de Claude Code approuvent 93 % à 97 % des demandes d’autorisation ; dans son expérience contrôlée, les participants n’ont repéré que 13,6 % des commandes dangereuses introduites à dessein, et faisaient moins bien à mesure que les sessions s’allongeaient. C’est une recherche de fournisseur menée pour promouvoir le mode automatique, et elle mesure la détection de demandes introduites à dessein plutôt que des taux d’incidents en production, mais la tendance est claire.

Les mêmes données contiennent un autre chiffre : les utilisateurs rejettent 39 % des plans mais seulement 3 % des demandes d’autorisation individuelles. Ce que les gens jugent sérieusement, ce sont les plans et les fusions, pas chaque appel d’outil.

Fonctionnement #

• Elle n’apparaît que dans peu d’endroits : fusion dans un arbre protégé, suppression dans un arbre protégé, partage ou publication vers l’extérieur, sortie de données, élargissement d’une habilitation et abaissement d’une étiquette. Les écritures sur une branche n’exigent aucune approbation.
• La granularité est un plan ou une fusion. Relire une PR, pas cinquante demandes.
• La Gate Card est produite par le NAS : le vrai diff, un résumé du manifeste de lecture, l’habilitation et la contamination de session, jamais le récit de l’agent lui-même. Options : approuver, approuver en restreignant, refuser ; un délai dépassé vaut refus par défaut.
• Une approbation est liée à l’empreinte de l’action : elle lie le hachage du diff et l’habilitation et ne peut pas être rejouée.
• Remise : push, messagerie, e-mail ou CLI ; elle peut être déléguée ; les passkeys sont une authentification forte facultative.
• Escalade seulement. Un classifieur de risque facultatif (y compris un LLM) peut seulement escalader une action vers une validation et jamais en approuver une. Un modèle ne peut que resserrer, jamais relâcher.
• La fatigue est mesurée : taux d’approbation et délai d’approbation ; quand le taux d’approbation est anormalement élevé, cela suggère de regrouper les validations ou de resserrer la politique.

Commencer petit #

• Un main protégé plus une revue de PR (n’importe quelle plateforme Git convient) et une notification push.
• Ou une CLI : nas gate approve <gate_id>.
• Faites d’abord afficher le « vrai diff » par la Gate Card ; ne vous précipitez pas vers des interfaces sophistiquées.

Esquisse d’interface #

À titre d’illustration seulement. Les noms de champs peuvent changer avant la spécification v0.3.

{
  "gate_id": "gt_2Mx4",
  "run": "run_91ab",
  "action": {
    "op": "merge",
    "from": "cleo/run_91ab",
    "into": "main",
    "files_changed": 4,
    "diff_sha256": "7d2a..."
  },
  "why": "Release notes are ready for review",
  "risk": {
    "session_taint": ["external"],
    "sources": ["web:example.com/changelog"],
    "destructive": false,
    "egress": false
  },
  "options": ["approve", "approve_narrowed", "deny"],
  "default": "deny",
  "expires_at": "2026-11-12T12:00:00Z"
}

Ce que demande la spécification #

• Une Gate Card DOIT montrer le vrai diff calculé par le NAS, pas la description qu’en donne l’agent.
• Une approbation DOIT être liée à l’empreinte de l’action et à l’habilitation et NE DOIT PAS pouvoir être rejouée.
• Le résultat par défaut d’un délai dépassé DOIT être le refus.
• Un classifieur ou un LLM NE DOIT PAS accorder d’approbation ; il PEUT escalader une action vers une validation.
• La fusion dans un arbre protégé, la suppression dans un arbre protégé, le partage externe, la sortie de données, l’élargissement d’une habilitation et l’abaissement d’une étiquette DOIVENT passer par une validation.
• Le NAS DEVRAIT rapporter le taux d’approbation et le délai d’approbation.

Ce qui est emprunté, et ce qui est nouveau #

Tout ce qui précède est une pratique établie. Ce qui est nouveau : ancrer l’approbation sur la fusion au niveau de la couche de stockage et faire produire le contenu par le NAS (pas par l’agent). L’approbation et les PR ne sont pas nouvelles en elles-mêmes.

• How we built Claude Code auto mode
• Anthropic: approval data behind auto mode
• CaMeL
• WebAuthn
• OpenID CIBA

Limites assumées #

• Une personne peut quand même approuver la mauvaise action ; la revue par lots provoque aussi de la fatigue.
• Les canaux de notification peuvent être victimes d’hameçonnage.
• Une approbation ne peut pas arrêter quelque chose en dehors de ce qui a été approuvé ; c’est le travail de l’habilitation.

Questions ouvertes #

• Quelle est la meilleure interface pour une revue par lots et par niveaux ?
• Comment mesurer et régler le seuil de fusion automatique ?

Questions #

Concepts liés #

• Capability Lease (habilitation de capacité) Une autorisation étroite pour une exécution, avec une expiration et des budgets. Les habilitations filles ne peuvent être que plus étroites.
• Trust Labels (étiquettes de confiance) Deux petites étiquettes plus la contamination de session appliquent la Rule of Two.
• Agent Branch (branche d’agent) Chaque exécution travaille sur une branche en copy-on-write. Seule une fusion relue atteint la ligne principale.