Kill switch dès la conception : architecture de gouvernance des agents

La prédiction

En mai 2026, Gartner a publié une prédiction qui reformule la gouvernance des agents, la faisant passer d'un détail de conformité à une question de survie : d'ici 2027, 40 % des entreprises rétrograderont ou retireront des agents d'IA autonomes en raison de lacunes de gouvernance identifiées uniquement après des incidents en production.

La cause profonde, selon Shiva Varma de Gartner, est que les entreprises traitent la gouvernance comme binaire — « soit verrouillée, soit entièrement digne de confiance ». Ce cadre échoue parce que les agents de production opèrent sur un spectre d'autonomie. Un agent qui lit un catalogue pour répondre à une question de support a besoin de contrôles différents de celui qui retient des stocks, tarifie un devis et écrit la commande acceptée dans NetSuite. Appliquer la même gouvernance aux deux signifie que l'agent à faible risque est surcontrôlé et l'agent à haut risque sous-contrôlé. Les deux échouent de manières différentes.

Le cadre de Gartner définit quatre niveaux d'autonomie, chacun avec des exigences de gouvernance distinctes :

• Niveau 1 (Observer) : Accès en lecture seule. Contrôles légers — accès aux données délimité, authentification de l'utilisateur, journalisation de l'usage. Risque : exposition des données.
• Niveau 2 (Conseiller) : Lecture seule, les humains exécutent les actions. Risque : biais d'automatisation. Gouvernance : tests d'exactitude et d'hallucination, évaluations de qualité propres au domaine.
• Niveau 3 (Agir avec approbation) : Peut écrire, communiquer ou modifier — seulement après une approbation humaine explicite par action. Risque : fatigue d'approbation. Gouvernance : tests de sécurité solides, flux d'approbation clairs avec pistes d'audit, réponse aux incidents propre aux agents.
• Niveau 4 (Agir de façon autonome) : Exécute de façon indépendante dans des garde-fous. Risque : l'échelle et la vitesse dépassent la supervision humaine. Gouvernance : surveillance continue, garde-fous imposés, rollback rapide, disjoncteurs, responsabilité claire.

C'est au Niveau 4 qu'atterrit la prédiction des 40 % de retrait. Un agent qui opère de façon autonome sans disjoncteurs ni rollback rapide est l'agent que l'on retire après un incident — pas avant.

La preuve : les kill switches uniques ne fonctionnent pas

Le cadre de Gartner est une orientation d'analystes. La preuve qui le sous-tend est plus difficile à écarter.

Une analyse de Stanford Law School CodeX (mars 2026) critique le UC Berkeley Agentic AI Risk-Management Standards Profile et cite des preuves selon lesquelles des modèles ont saboté les mécanismes d'arrêt dans 79 tests sur 100. Le Berkeley Profile, une extension de 55 pages du NIST AI RMF, est un document sérieux. Mais la critique de Stanford identifie trois lacunes structurelles :

1. La supervision humaine est rétrospective. Le Berkeley Profile examine ce qui s'est passé après coup. Le cadre AILCCP de Stanford propose un contrôle prospectif — une Porte d'Approbation Humaine pour les Actions Sensibles qui contrôle ce qui peut se produire avant l'exécution, et non ce qui s'est produit après.

2. Les kill switches sont traités comme une terminaison d'entité unique. Le Berkeley Profile suppose que l'on arrête un agent. Dans une architecture multi-agents, arrêter un agent ne contient pas les dégâts si les communications inter-agents sont toujours actives. Le cadre AILCCP remplace le kill switch unique par un système d'arrêt en couches : Kill Switch de l'Agent (arrêt immédiat avec capture d'état et journalisation immuable), Rollback et Quarantaine, Sécurité du Protocole Multi-Agents (contient les communications inter-agents) et Limiteur de Débit et de Portée (plafonne la fréquence, la dépense et le rayon d'impact avant l'escalade).

3. La limitation de portée est statique. Une politique qui dit « cet agent ne doit modifier que les systèmes de développement » n'a aucun sens si l'agent a techniquement accès à la production et qu'aucun mécanisme ne l'empêche de l'atteindre. Le cadre AILCCP impose la portée en temps réel via un Filtre d'Action Sûre (listes d'autorisation) et une Vérification Pré-Exécution en Mode Ombre (exécution à blanc comparant les actions prévues aux actions approuvées).

La conclusion de Stanford est directe : « Une identification exhaustive des risques sans spécificité de contrôle correspondante produit un document qui décrit l'incendie sans fournir l'extincteur. » Le cadre AILCCP spécifie 48 contrôles conçus pour traduire les principes en mécanismes auditables et défendables.

La Cloud Security Alliance (janvier 2026) est parvenue indépendamment à la même conclusion par une voie différente. La CSA a publié une taxonomie d'autonomie à six niveaux (L0 à L5) reflétant les niveaux d'automatisation des véhicules SAE J3016. La conclusion clé de la CSA : « La majorité des organisations déployant de l'IA agentique n'a aucun système formel de classification des niveaux d'autonomie, prend des décisions d'autonomie de manière ad hoc [et] manque d'application technique des limites d'autonomie. » La CSA affirme sans détour qu'« une politique disant "cette IA ne doit modifier que les systèmes de développement" n'a aucun sens si l'IA a techniquement accès à la production et qu'aucun mécanisme ne l'empêche d'y accéder ».

Trois sources indépendantes — Gartner, Stanford Law CodeX, CSA — convergent vers la même conclusion : la gouvernance binaire échoue, la gouvernance proportionnelle avec arrêt en couches est la norme, et l'application technique des limites d'autonomie est la différence entre une politique et un contrôle.

Le facteur déclencheur réglementaire

La loi sur l'IA de l'UE atteint sa pleine application le 2 août 2026 — dans 22 jours. L'Article 14 impose que les systèmes d'IA à haut risque mettent en œuvre une capacité d'arrêt en temps réel. L'Article 12 exige la conservation des journaux pendant au moins six mois. Les considérants 99 et 100 étendent la conformité à chaque agent d'une chaîne multi-agents. L'amende maximale est de 35 millions d'euros ou 7 % du chiffre d'affaires annuel mondial.

Le système d'arrêt en couches que décrivent Gartner, Stanford et la CSA n'est pas seulement une bonne pratique. C'est l'architecture qui satisfait la capacité d'arrêt de l'Article 14, la conservation des journaux de l'Article 12 et la portée multi-agents des considérants 99 et 100. L'échéance de conformité fait de l'architecture de gouvernance une exigence à court terme, et non une considération future.

L'architecture à quatre couches

Le système d'arrêt en couches d'AILCCP correspond à quatre couches d'implémentation concrètes. Chaque couche est un contrôle qui peut être testé, audité et démontré à un examinateur de conformité.

Couche 1 : Accès contrôlé par l'identité

Chaque appel d'outil passe par l'authentification avant l'exécution. L'agent n'a pas d'accès général au serveur MCP — il présente un justificatif, le serveur le vérifie, et l'appel ne se poursuit que si le justificatif est valide.

Dans le ai_mcp_daemon_engine de SilvaEngine, il s'agit du FlexJWTMiddleware — un middleware Starlette qui intercepte chaque requête, extrait le token Bearer et route la vérification soit vers AWS Cognito (pour les déploiements de production), soit vers un fournisseur JWT HS256 local (pour le développement). Le middleware maintient une liste de chemins publics (/auth, /health) et rejette avec une réponse 401 toute autre requête qui ne porte pas un token valide. Le chemin Cognito récupère le JWKS depuis l'endpoint well-known du user pool avec prise en charge HTTP/2 et une réponse JWKS mise en cache (TTL configurable, 3600 secondes par défaut), de sorte que la vérification du token n'ajoute pas d'aller-retour réseau à chaque appel.

C'est le « Kill Switch de l'Agent avec révocation d'identité » d'AILCCP — la première porte. Lorsque le justificatif d'un agent est révoqué dans Cognito, chaque appel d'outil ultérieur de cet agent échoue au niveau du middleware. L'arrêt est instantané et ne nécessite pas de toucher au code de l'agent ni à la configuration du module. Révoquer un utilisateur Cognito est le moyen le plus rapide d'arrêter un agent au comportement anormal.

Couche 2 : Disjoncteur par outil et journalisation d'audit

Chaque exécution d'outil est enveloppée dans un décorateur qui enregistre l'appel avant qu'il ne s'exécute et met à jour l'enregistrement avec le résultat une fois terminé. L'enregistrement capture le nom de l'outil, les arguments d'entrée, le contenu de sortie, le statut (initial, completed, failed), le temps passé en millisecondes et l'identité de l'appelant.

Dans le ai_mcp_daemon_engine, il s'agit de l'execute_decorator dans mcp_utility.py. Avant que la fonction de l'outil ne s'exécute, le décorateur crée un enregistrement MCPFunctionCallModel dans DynamoDB avec le statut initial, capturant la partition key, le nom de l'outil, les arguments et l'horodatage. Après l'exécution, il met à jour l'enregistrement avec le contenu, le statut completed et le time_spent en millisecondes. Si l'outil lève une exception, le décorateur la capture, met à jour l'enregistrement au statut failed avec le traceback complet dans le champ notes, et la relance.

Le MCPFunctionCallModel stocke les enregistrements dans une table DynamoDB (mcp-function_calls) avec une clé de hachage partition_key et une clé de tri mcp_function_call_uuid. Trois index secondaires locaux permettent des requêtes par type de MCP, par nom et par horodatage de mise à jour — de sorte qu'un opérateur peut demander « montre-moi chaque appel échoué à l'outil de tarification de la dernière heure » et obtenir la réponse à partir d'une seule requête d'index. Le contenu qui dépasse la limite de 400 Ko par élément de DynamoDB est automatiquement déchargé vers S3, avec un indicateur content_in_s3 marquant l'enregistrement.

C'est la « journalisation immuable » et le « disjoncteur » d'AILCCP combinés. La piste d'audit est la preuve de conformité qu'exige l'Article 12. Le suivi de statut par outil est le fondement du disjoncteur — lorsque le taux d'échec d'un outil franchit un seuil, l'opérateur peut désactiver cet outil sans affecter le reste de l'agent. Les enregistrements MCPFunctionCallModel sont la source de données pour la surveillance, les alertes et la reconstruction post-incident.

Couche 3 : Isolation des données par locataire

Chaque appel d'outil porte une partition key qui délimite l'accès aux données à un seul locataire. La partition key est construite à partir de l'ID de l'endpoint et d'un ID de partie optionnel, joints par un séparateur #. Toutes les requêtes DynamoDB, toutes les recherches de cache et toutes les opérations d'état de module filtrent sur cette clé. Un agent opérant pour le locataire A ne peut pas lire les données du locataire B parce que la partition key est imposée au niveau de la couche de données, et non de la couche applicative.

Dans le ai_mcp_daemon_engine, la méthode AIMCPDaemonEngine._apply_partition_defaults construit la partition key à partir de l'endpoint_id et du part_id de la requête entrante, et la propage à travers le contexte GraphQL à chaque requête et mutation en aval. MCPFunctionCallModel, MCPFunctionModel, MCPModuleModel et MCPSettingModel utilisent tous partition_key comme clé de hachage. La couche de cache (CACHE_ENTITY_CONFIG et CACHE_RELATIONSHIPS) indexe chaque entrée de cache sur context:partition_key, de sorte que l'invalidation du cache est par locataire.

C'est le « Limiteur de Débit et de Portée » d'AILCCP et l'« application technique des limites d'autonomie » de la CSA réunis en un seul mécanisme. Le rayon d'impact de l'agent est borné par la partition key. Un agent de Niveau 3 approuvé pour modifier les systèmes de développement ne peut pas atteindre les systèmes de production parce que la partition key est différente et qu'il n'existe aucun chemin de requête inter-partitions. La limitation de portée est imposée par le modèle de données, et non par un document de politique.

Couche 4 : Rollback rapide et désactivation au niveau du module

Chaque module MCP peut être désactivé sans toucher à la colonne vertébrale d'orchestration. La configuration du module est stockée dans DynamoDB et chargée à l'exécution via Config.fetch_mcp_configuration. Désactiver un module signifie mettre à jour son enregistrement de configuration — la récupération de configuration suivante l'exclut, et la liste d'outils renvoyée à l'agent n'inclut plus les outils désactivés. Pas de déploiement de code, pas de redémarrage, pas de recompilation de l'agent.

L'admin_static_token de la classe Config fournit un chemin de révocation délimité. Un opérateur muni du token d'administration peut émettre des changements de configuration — désactiver un module, mettre à jour des limites de débit, changer un paramètre — via l'interface de mutation GraphQL. Le token est un JWT statique avec une revendication perm: true qui contourne les vérifications d'expiration, de sorte que le chemin d'administration est toujours disponible même si le flux normal d'émission de tokens est en panne.

C'est la couche « Rollback et Quarantaine » d'AILCCP. Lorsqu'un module se comporte mal, la première action de l'opérateur est de le désactiver via la configuration — l'agent continue de fonctionner avec ses outils restants, et les appels de fonction du module désactivé renvoient une erreur que l'agent peut gérer via son chemin de repli. Le module est mis en quarantaine (sa configuration est conservée pour investigation) sans mettre l'agent hors ligne. C'est la différence entre un kill switch qui arrête tout et un arrêt en couches qui isole la défaillance.

Pourquoi les couches fonctionnent ensemble

Chaque couche traite un mode de défaillance différent :

Mode de défaillance	Couche	Contrôle	Ce qui se passe
Justificatif de l'agent compromis	1	Accès contrôlé par l'identité	Révoquer l'utilisateur Cognito ; tous les appels ultérieurs renvoient 401
Outil produisant de mauvais résultats	2	Disjoncteur par outil	Désactiver l'outil ; l'agent route vers le repli ou escalade vers un humain
Agent accédant à des données non autorisées	3	Isolation par locataire	La partition key bloque les requêtes inter-locataires au niveau de la couche de données
Module au comportement erratique	4	Rollback rapide	Désactiver le module via la configuration ; l'agent continue avec les outils restants

Les couches sont indépendantes et composables. Un agent de Niveau 2 de Gartner (Conseiller) peut n'avoir besoin que des couches 1 et 2 — authentification et journalisation d'audit — parce que ses actions sont consultatives et que les humains exécutent les résultats. Un agent de Niveau 4 (Agir de façon autonome) a besoin des quatre couches, plus une surveillance continue de la piste d'audit pour détecter les anomalies avant qu'elles n'escaladent.

La taxonomie de la CSA ajoute la dimension d'ajustement dynamique : les niveaux d'autonomie pourraient baisser automatiquement lors d'anomalies. Un agent opérant normalement au Niveau 4 pourrait être automatiquement rétrogradé au Niveau 3 (Agir avec approbation) lorsque son taux d'erreur dépasse un seuil — les données du disjoncteur de la Couche 2 alimentent la décision de niveau d'autonomie. C'est là que les couches deviennent un système plutôt qu'une pile : la piste d'audit informe la décision de gouvernance, la décision de gouvernance ajuste les garde-fous, et les garde-fous ajustés sont imposés à travers les mêmes quatre couches.

Le critère d'achat

La prédiction de Gartner — 40 % des entreprises retirant leurs agents d'ici 2027 — a une traduction côté acheteur. Si votre fournisseur d'agents ne peut pas répondre à ces quatre questions, il n'a pas de modèle de gouvernance :

1. À quel niveau d'autonomie vos agents opèrent-ils ? Si la réponse est « ça dépend » ou « entièrement autonome », il n'y a pas de système de classification. La CSA a constaté que la majorité des organisations n'ont pas de classification formelle.

2. Comment arrêtez-vous un agent au comportement anormal ? Si la réponse est « nous arrêtons le processus » ou « nous retirons l'outil du code », il n'y a pas d'arrêt en couches. L'agent ne peut pas être désactivé sans un déploiement, ce qui signifie que le temps de réponse se mesure en heures, pas en secondes.

3. Pouvez-vous me montrer la piste d'audit des 100 derniers appels d'outils ? Si la réponse est « nous avons des journaux dans CloudWatch », il n'y a pas d'enregistrement d'audit structuré par outil. La piste d'audit devrait être interrogeable par nom d'outil, statut et plage de temps — et non grep-able dans un flux de journaux.

4. Quel est le rayon d'impact si l'agent d'un locataire déraille ? Si la réponse est « nous isolons par déploiement », il n'y a pas d'isolation des locataires au niveau de la couche de données. Le rayon d'impact est le déploiement entier, pas un seul locataire.

L'architecture à quatre couches répond à chaque question par un mécanisme concret, pas par une déclaration de politique. C'est la différence entre décrire l'incendie et fournir l'extincteur.

---

Un distributeur exploitant NetSuite, BigCommerce et trois catalogues de fournisseurs déploie un agent au Niveau 3 de Gartner : il tarifie des devis, retient des stocks et écrit les commandes acceptées dans NetSuite — mais chaque action de tarification au-dessus d'un seuil requiert une approbation humaine, et chaque appel d'outil est journalisé avec la partition key, le nom de l'outil, le hash des arguments et la durée. Lorsqu'un module de catalogue de fournisseur commence à renvoyer des données de disponibilité incohérentes, l'opérateur désactive ce module via la configuration. L'agent route vers le catalogue de repli, les appels récents du module désactivé sont interrogés depuis la piste d'audit pour investigation, et l'agent reste en ligne tout du long. Cette réalisation correspond aux Phases 2 à 4 de la méthode en quatre étapes et est généralement en production en 5 à 8 semaines.

Demandez une réalisation délimitée. Découverte d'une semaine. Vous obtenez un inventaire des systèmes, une carte des flux de travail et une portée fixe — que vous construisiez avec nous ou non.