# Human Gate (validation humaine)

*N’apparaît qu’avant les actions irréversibles, tournées vers l’extérieur ou qui élèvent les privilèges, et montre le vrai diff.*

> **Une Human Gate** est un point de contrôle déclenché par la politique : avant qu’une action **irréversible, tournée vers l’extérieur ou élevant les privilèges** ne prenne effet, une personne (ou un approbateur désigné) approuve une action concrète, entièrement affichée. Elle est conçue pour être rare, précise et difficile à valider par réflexe.

**AN-05** · Niveau de conformité : L1 Authority · Groupe : Autorité

## 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-card.json*

```json
{
  "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](https://www.anthropic.com/research/claude-code-auto-mode)
- [Anthropic: approval data behind auto mode](https://claude.com/resources/articles/auto-mode-default-in-claude-code)
- [CaMeL](https://arxiv.org/abs/2503.18813)
- [WebAuthn](https://www.w3.org/TR/webauthn-3/)
- [OpenID CIBA](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html)

## 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

### N’est-ce pas simplement une boîte de dialogue « confirmer » de plus ?

Délibérément non. Une boîte de dialogue se déclenche à chaque appel d’outil et les gens finissent vite par cliquer sur « approuver ». Une validation n’apparaît qu’avant quelques actions irréversibles ou tournées vers l’extérieur, montre le vrai diff calculé par le NAS, et l’approbation lie le hachage du diff : si le diff change, l’approbation est nulle.

### Un LLM peut-il décider de laisser passer une action ?

Il peut suggérer qu’« une personne devrait regarder cette étape » ; il ne peut pas approuver. La décision de laisser passer doit être une règle déterministe ou l’approbation d’une personne. Ainsi, la sécurité ne dépend du jugement d’aucun modèle.

### Que se passe-t-il à l’expiration du délai ?

Refus par défaut. L’exécution reçoit un refus clair et peut emprunter une autre voie, ou laisser la proposition sur sa branche pour qu’une personne s’en occupe.

## Concepts liés

- [Capability Lease (habilitation de capacité)](https://agentnas.com/fr/concepts/capability-lease/): 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)](https://agentnas.com/fr/concepts/trust-labels/): Deux petites étiquettes plus la contamination de session appliquent la Rule of Two.
- [Agent Branch (branche d’agent)](https://agentnas.com/fr/concepts/agent-branch/): Chaque exécution travaille sur une branche en copy-on-write. Seule une fusion relue atteint la ligne principale.

---

URL canonique : https://agentnas.com/fr/concepts/human-gate/
Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0