Kill switch pour les agents IA : arrêter des actions en urgence sans release

L’idée en 30 secondes

Le kill switch est un contrôle d’urgence en runtime qui permet de stopper immédiatement les nouvelles actions d’un agent pendant un incident, sans release et sans modifier le prompt.

Quand c’est nécessaire :
quand un agent peut exécuter des actions d’écriture, travaille avec des API externes, et qu’une erreur est déjà en train de devenir un incident de production.

Le problème

Quand un agent commence à faire des actions nuisibles, il n’y a généralement pas le temps de "retoucher le prompt et faire un release". Pendant que l’équipe analyse le problème, l’agent peut continuer à faire les mêmes actions. Et chaque minute de retard, ce sont de nouveaux effets secondaires (changements d'état) en production.

Pattern typique :

• doublons d’emails ou de messages
• opérations create/update massives
• appels excessifs à des API externes

Analogie : c’est comme un bouton d’arrêt d’urgence sur une ligne de production. En cas de panne, il faut d’abord stopper le mouvement, puis analyser la cause.

Si kill switch fonctionne seulement dans l’UI, ce n’est pas un contrôle d’urgence. L’arrêt réel doit se faire dans la runtime loop et dans le tool gateway.

La solution

La solution est d’ajouter une couche policy kill switch centralisée, vérifiée après la formation de l’action suivante, mais avant exécution. La policy retourne allow ou stop avec une raison explicite : killed_global, killed_tenant, writes_disabled, tool_disabled.

Modèle de base :

• global kill — stoppe tout le monde en urgence
• tenant kill — stoppe un client précis
• writes disabled — autorise read, bloque write
• tool disabled — bloque un tool précis

C’est une couche d’urgence séparée, pas une partie du prompt ni de la logique UI.

Kill switch ≠ système de gouvernance complet

Kill switch et governance résolvent des besoins différents :

• Kill switch stoppe l’incident "ici et maintenant"
• Governance pilote le comportement de l’agent en continu (RBAC, limites, budgets, approval)

L’un sans l’autre ne fonctionne pas bien :

• sans kill switch, il est difficile d’arrêter un incident immédiatement
• sans governance, les incidents arrivent trop souvent

Enveloppe de contrôle kill switch

Ces vérifications travaillent ensemble comme une enveloppe d’urgence en runtime.

À quoi ça ressemble dans l’architecture

La couche policy kill switch est dans la runtime loop entre planning et exécution de l’action suivante. Chaque décision (allow ou stop) est enregistrée dans l’audit log.

Chaque step passe par ce flow avant exécution : la runtime n’exécute pas les actions directement, elle passe d’abord la décision à la policy.

Résumé du flow :

• Runtime forme l’action suivante
• Policy lit global/tenant flags + writes/tool rules
• allow -> l’action suivante de l’agent est exécutée
• stop -> le run s’arrête avec une reason explicite (killed_global, killed_tenant, writes_disabled, tool_disabled)
• la décision est écrite dans l’audit log

Exemple

Un agent de support a commencé à envoyer email.send en masse à cause d’un scénario défectueux. Un opérateur active writes_disabled pour un tenant précis.

Résultat :

• les nouvelles actions write sont bloquées immédiatement
• les actions read peuvent rester disponibles
• les logs contiennent who/when/why pour chaque blocage

Kill switch stoppe l’incident directement dans la runtime loop au lieu d’attendre un nouveau release.

En code, ça ressemble à ça

Le schéma simplifié ci-dessus montre le flow principal. En pratique, l’état kill est lu de façon centralisée et caché quelques secondes. Point critique : le kill-check doit être O(1) et avec cache court (1-2 secondes), sinon l’arrêt d’urgence réagit trop tard. En production, le même kill-check est souvent dupliqué dans le tool gateway, pour qu’aucun appel ne contourne le contrôle runtime.

Exemple de config kill switch :

kill_switch:
  global_flag: agent_kill_global
  tenant_flag_prefix: "agent_kill_tenant:"
  writes_disabled_default: false
  disabled_tools_key: agent_disabled_tools
  cache_ttl_seconds: 2

while True:
    action = planner.next(state)
    action_key = make_action_key(action.name, action.args)  # clé stable pour dedupe/audit

    kill_state = kill_store.read(tenant_id=state.tenant_id)
    decision = kill_policy.check(kill_state, action)

    if decision.outcome == "stop":
        audit.log(
            run_id,
            decision=decision.outcome,
            reason=decision.reason,
            scope=decision.scope,
            action=action.name,
            action_key=action_key,
            actor=kill_state.last_updated_by,
        )
        return stop(decision.reason)

    result = tool.execute(action.args)

    audit.log(
        run_id,
        decision=decision.outcome,
        reason=decision.reason,
        scope=decision.scope,
        action=action.name,
        action_key=action_key,
        result=result.status,
    )

    if result.final:
        return result

Kill switch stoppe les nouvelles actions. Pour les actions in-flight, il faut en général un mécanisme de cancel best-effort séparé.

À quoi ça ressemble pendant l’exécution

Scénario 1 : global stop

1. Un opérateur active global_kill=true.
2. Runtime forme l’action suivante et lit l’état kill.
3. Policy retourne stop (reason=killed_global).
4. Les nouvelles actions ne s’exécutent pas.
5. Les logs contiennent scope=global et actor.

Scénario 2 : tenant stop

1. tenant_kill=true est activé pour le tenant t_42.
2. Les runs de ce tenant reçoivent stop (reason=killed_tenant).
3. Les autres tenants continuent.
4. L’incident est localisé sans arrêt global.

Scénario 3 : writes disabled

1. writes_disabled=true est activé.
2. Une action read passe avec allow.
3. Une action write reçoit stop (reason=writes_disabled).
4. Le système passe en read-only degrade mode.

Erreurs typiques

• kill switch seulement en UI, mais pas en runtime/tool gateway
• un seul stop global sans mode per-tenant
• absence de mode writes-disabled
• cache TTL long (minutes au lieu de secondes)
• absence d’audit trail pour les actions opérateur
• absence de runbook incident testé

Résultat : l’équipe a un "bouton", mais pas de vrai contrôle d’urgence.

Auto-vérification

Vérification rapide kill switch avant lancement en production :

FAQ

Q : Qu’activer d’abord : global stop ou writes disabled ?
A : Commence par writes_disabled si l’incident concerne des actions write. Utilise global_kill quand le risque est large et qu’un arrêt complet immédiat est nécessaire.

Q : Où vérifier kill switch exactement ?
A : Au minimum à deux endroits : dans la runtime loop avant l’action suivante et dans le tool gateway avant exécution du tool.

Q : Peut-on cacher l’état kill ?
A : Oui, mais brièvement (secondes). En incident, un cache de plusieurs minutes rend kill switch presque inutile.

Q : Comment implémenter techniquement les kill flags ?
A : Généralement via des flags globaux et tenant-scoped dans Redis/config store, lus par la policy avant chaque action.

Q : Kill switch annule les actions déjà lancées ?
A : Pas toujours. Il bloque de façon fiable les nouvelles actions. Les tâches in-flight nécessitent un mécanisme best-effort cancel séparé.

Q : Kill switch peut remplacer RBAC et budgets ?
A : Non. Kill switch est un mécanisme d’arrêt d’urgence. RBAC, limites et budgets restent nécessaires en contrôle permanent.

Où se place Kill Switch dans le système

Kill switch est la couche d’urgence de l’Agent Governance. Avec RBAC, budgets, approval et audit, il forme un système de contrôle production complet.

Pages liées

Suite du sujet :

• Vue d’ensemble Agent Governance — modèle global de contrôle des agents en production.
• Contrôle d’accès (RBAC) — comment limiter qui peut faire quoi.
• Budget Controls — comment limiter les dépenses et runaway runs.
• Step limits — comment stopper les loops au niveau runtime loop.
• Human approval — où une confirmation manuelle est requise avant action risquée.