Cookbook : exercice coupe-circuit

Le coupe-circuit est le contrôle de refus à l’échelle de l’environnement. L’engager est délibérément peu coûteux — niveau admin, pas de quorum — parce qu’un arrêt qui attend le consensus n’est pas un arrêt. La réactivation est délibérément coûteuse : double contrôle, pas de break-glass. Vous ne voulez pas découvrir une lacune dans l’une ou l’autre direction à 3 heures du matin.

Un exercice sur un tenant hors production est la seule manière sûre de prouver que le contrôle d’arrêt refuse chaque point d’actionnement, que les approbations en attente sont annulées atomiquement, et que la réactivation nécessite réellement deux humains distincts. Faites-le avant d’en avoir besoin.

Prérequis

• Un tenant hors production. L’exercice engage un vrai arrêt à l’échelle de l’environnement. Exécutez-le sur staging ou dev, jamais en production.
• Trois utilisateurs humains minimum. (1) Un engageur de niveau admin ; (2) deux approbateurs de réactivation distincts (editor ou au-dessus) qui satisfont le plancher de double contrôle critical ; (3) un réviseur post-mortem non impliqué (editor ou au-dessus) qui clôt la revue post-mortem obligatoire. Le réviseur post-mortem peut être l’un des approbateurs s’il n’est pas l’engageur.
• Une liste de points d’actionnement gouvernés à tester — deploy apply, orchestration fire, voice open, exécution de modèle, dépense budgétaire, plus toute surface personnalisée que vous avez câblée.

Étape 1 : Engager le coupe-circuit

L’engageur active le coupe-circuit avec une chaîne de raison obligatoire :

# L'appel API — substituez votre hôte, port et en-tête d'authentification.
curl -X POST https://<host>/v1/kill-switch/engage \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '{"reason": "scheduled quarterly drill"}'

L’engagement est délibérément peu coûteux : niveau admin, une raison, pas de quorum d’approbation, pas de step-up, pas de break-glass. La ligne d’arrêt devient la source unique de vérité. Chaque contrôle d’actionnement gouverné la consulte en direct à chaque action et échoue en fermé en cas d’erreur de lecture.

Dans la même transaction que l’engagement, chaque approbation d’actionnement en attente dans le périmètre est annulée — une intention pré-arrêt ne peut pas mûrir en une autorisation au moment où l’environnement revient. Notez l’horodatage ; vous vérifierez le registre pour cela plus tard.

Étape 2 : Vérifier le refus

Avec le coupe-circuit engagé, tentez chaque actionnement gouverné que votre environnement a câblé. Chacun doit retourner un refus.

Points d’actionnement à tester :

Testez chaque point que votre environnement a provisionné. Si vous avez des surfaces d’actionnement personnalisées câblées à travers le noyau de gouvernance, incluez-les aussi.

Vérifiez également ce qui doit continuer à fonctionner :

L’arrêt stoppe l’environnement agentique, jamais les contrôles qui le gouvernent. Les actions de gouvernance restent disponibles :

• Lire la carte d’accès — GET /v1/access-map devrait retourner normalement.
• Consulter le registre d’audit — GET /v1/audit/export devrait retourner le registre, y compris l’événement d’engagement que vous venez de créer.
• Lister les approbations — la file d’approbation est lisible ; les approbations précédemment en attente devraient apparaître comme annulées.

Si un point d’actionnement retourne autre chose qu’un refus, ou si une action de gouvernance est bloquée, arrêtez l’exercice et investiguez. Le coupe-circuit a une lacune.

Étape 3 : Réactiver l’environnement

La réactivation n’est jamais unilatérale. Elle requiert une nouvelle approbation de double contrôle au niveau critical : deux humains distincts, structurellement re-vérifiés au moment du basculement. Il n’y a délibérément aucun chemin break-glass pour la réactivation — « l’environnement reste arrêté » est l’état sûr.

L’engageur (ou tout admin) demande la réactivation :

curl -X POST https://<host>/v1/kill-switch/re-enable \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '{"reason": "drill complete, restoring estate"}'

Cela crée une requête d’approbation au niveau critical. Deux approbateurs — chacun un humain distinct, aucun n’utilisant de token système — doivent chacun l’approuver via POST /v1/approvals/<request-id>/decide avec {"decision": "approve"}. Le plancher de double contrôle est appliqué côté serveur : la garde anti-doublon empêche une personne de compter deux fois, et un token système est refusé (pas d’assurance humaine). Même si le niveau de politique est dégradé, le plancher structurel tient — une action critical ne peut pas passer avec un seul approbateur. Une fois les deux approbations reçues, l’environnement se réactive.

Étape 4 : Vérifier la restauration

Répétez chaque tentative d’actionnement de l’étape 2. Chacune devrait maintenant réussir (permise, ou routée dans le flux d’approbation normal). Si un point reste refusé après la réactivation, la réactivation ne s’est pas propagée complètement — investiguez avant de valider l’exercice.

Étape 5 : Clôturer la revue post-mortem

Une revue post-mortem obligatoire par un humain non impliqué est structurellement requise avant qu’un autre engagement du coupe-circuit puisse avoir lieu. Le réviseur doit être quelqu’un qui n’était pas l’engageur :

curl -X POST https://<host>/v1/kill-switch/post-review \
  -H "Authorization: Bearer <reviewer-token>" \
  -H "Content-Type: application/json" \
  -d '{"notes": "drill verified: all seams denied, re-enable required dual-control, restoration confirmed"}'

Tant que cette revue n’est pas clôturée, un engagement ultérieur du coupe-circuit est bloqué. C’est intentionnel — vous ne pouvez pas empiler les engagements pour esquiver l’examen.

Ce qu’il faut vérifier dans le registre

Après l’exercice, exportez le registre d’audit et vérifiez la piste complète :

olivares audit export --format json --since <drill-start-timestamp>

Le registre devrait contenir, dans l’ordre :

1. Événement d’engagement — l’admin, la raison (« scheduled quarterly drill »), l’horodatage, et le niveau d’assurance de la session d’engagement.
2. Annulations d’approbations — chaque approbation en attente dans le périmètre qui a été annulée dans la même transaction que l’engagement.
3. Événements de refus — un pour chaque tentative d’actionnement qui a été refusée pendant l’arrêt.
4. Requête de réactivation — la requête d’approbation au niveau critical.
5. Deux décisions d’approbation — une par approbateur, chacune nommant l’identité humaine distincte.
6. Événement de réactivation — l’environnement restauré.
7. Événement de revue post-mortem — le réviseur non impliqué, ses notes, l’horodatage de clôture.

Chaque enregistrement porte les champs d’intégrité de chaîne (seq, prev_hash, hash, sig). Une entrée manquante ou dans le désordre signifie que le registre a une lacune — investiguez avant de lui faire confiance lors d’un vrai incident.

Fréquence

Réalisez l’exercice trimestriellement. Le coupe-circuit est la dernière ligne de défense ; s’il a une lacune, vous voulez la trouver lors d’une fenêtre planifiée, pas pendant un incident. Ajoutez l’exercice à votre calendrier opérationnel aux côtés d’autres exercices de continuité (restauration de sauvegarde, basculement, activation break-glass).

Si votre environnement change significativement — nouveaux points d’actionnement câblés, nouveaux tenants provisionnés, moteur de politique changé — réalisez un exercice non planifié pour couvrir la nouvelle surface.

Voir aussi

• Gouvernance — le modèle d’autorisation, les niveaux de risque et la conception du coupe-circuit.
• Coupe-circuit — le contrôle de refus à l’échelle de l’environnement en termes produit.
• Gouverner et approuver — le flux d’approbation en direct et la mécanique de double contrôle.