Architecture de sécurité TAKpilot : portes d'approbation/refus et journal d'audit opérateur

Lorsqu'un système IA génère des appels API structurés à partir d'entrées en langage naturel et les soumet à une image opérationnelle commune (COP) en direct, le coût d'une action erronée n'est pas un fichier mal placé ou une valeur incorrecte dans un tableur. Un marqueur hostile placé sur une grille occupée par une unité amie, une mission supprimée qui coordonnait une évacuation médicale, un canal effacé qui distribuait des flux ISR à un élément de reconnaissance actif — ces erreurs ne sont pas corrigeables avec Contrôle-Z. TAK Server ne dispose pas d'annulation native pour la plupart des opérations de données. La suppression s'exécute, les données disparaissent, et la COP que chaque opérateur du réseau navigue reflète l'erreur jusqu'à ce que quelqu'un le remarque et reconstruise manuellement ce qui a été perdu.

C'est le contexte de sécurité dans lequel TAKpilot — le coopilote de chat IA pour CloudTAK — a été conçu. L'architecture de sécurité du produit n'est pas un ensemble d'avertissements consultatifs ou de confirmations souples que les opérateurs peuvent cliquer précipitamment. Il s'agit d'un ensemble de contraintes structurelles strictes : des cartes d'outils en streaming qui rendent chaque action IA visible avant et pendant l'exécution, des portes d'approbation/refus obligatoires qui interceptent toutes les opérations destructives au niveau de la couche d'exécution avant tout appel API, un isolement des données par session qui limite le rayon d'action des actions d'une seule session, et un journal d'audit horodaté complet qui préserve l'attribution de l'opérateur pour chaque écriture assistée par l'IA. Cet article explique chaque mécanisme en détail — comment il est implémenté, ce qu'il intercepte et où se trouvent ses limites.

Les enjeux : pourquoi les erreurs IA dans une COP en direct sont catégoriquement différentes

Un assistant IA intégré dans un outil de productivité — un éditeur de documents, un IDE de code, une plateforme de support client — opère dans un environnement où les erreurs sont récupérables. L'historique des versions, les journaux de transactions et les chemins de correction manuelle existent à chaque couche. Le pire résultat d'une commande en langage naturel mal comprise est du temps perdu et un fichier qui doit être réédité.

Une image opérationnelle commune en direct ne partage pas ces propriétés de récupération. CloudTAK et TAK Server sont des systèmes d'état partagé en temps réel : chaque écriture est immédiatement visible par chaque opérateur du réseau. Il n'existe pas de mode brouillon, pas de couche de mise en attente, pas de flux de travail de type « proposer une modification pour examen ». Lorsque TAKpilot appelle place_marker, le marqueur apparaît sur chaque client connecté en quelques secondes. Lorsqu'il appelle delete_mission, la mission disparaît de chaque client et du magasin de missions du serveur simultanément. Une mission de soutien au feu supprimée parce que l'IA a mal interprété « mettre à jour le statut de » comme « supprimer » n'est pas récupérable depuis l'interface — elle nécessite une restauration de sauvegarde de base de données, ce qui dans un contexte de déploiement en avant-garde signifie qu'elle n'est effectivement pas récupérable du tout.

L'architecture de sécurité de TAKpilot a été conçue selon ces contraintes dès le départ, et non ajoutée après coup. Chaque décision de conception — le format de carte d'outil en streaming, l'implémentation de la porte, le modèle d'isolation de session, le schéma du journal d'audit — découle de l'exigence qu'aucune action destructive n'atteigne CloudTAK sans autorisation explicite de l'opérateur, et que chaque action qui atteint CloudTAK soit entièrement attribuable et auditable.

Cartes d'outils en streaming : transparence totale avant, pendant et après l'exécution

La première couche de l'architecture de sécurité de TAKpilot est la transparence : chaque action que l'IA effectue doit être visible par l'opérateur en temps réel, avec suffisamment de détails pour que l'opérateur puisse reconnaître si l'action correspond à son intention avant que l'effet ne se propage à la COP. TAKpilot implémente cela via des cartes d'outils en streaming — des panneaux d'interface repliables qui apparaissent dans le chat à mesure que chaque appel de fonction est initié et terminé.

Une carte d'outil en streaming contient quatre éléments. Premièrement, le nom de la fonction en langage courant — pas un identifiant API interne, mais la description lisible par l'humain issue du schéma d'outil : « Création de mission » plutôt que create_mission. Deuxièmement, l'ensemble complet des paramètres d'entrée affiché en JSON structuré — chaque champ, chaque valeur, afin que l'opérateur puisse lire les coordonnées de grille exactes, l'indicatif, le type CoT ou le nom de mission qui sera écrit. Troisièmement, le statut d'exécution, qui se diffuse en temps réel : en attente, en cours d'exécution, succès ou échec avec les détails de l'erreur. Quatrièmement, la latence d'exécution entre la soumission et la réponse de l'API CloudTAK, en millisecondes.

Pour les opérations multi-étapes — où le modèle enchaîne plusieurs appels d'outils pour exécuter une seule commande en langage naturel — chaque étape génère sa propre carte, apparaissant en séquence à mesure que la chaîne s'exécute. Un opérateur qui envoie « créer une mission logistique à la grille 37U DP 55555 44444 et notifier le canal LOG-NET » voit deux cartes : une pour create_mission et une pour notify_channel, chacune affichant ses paramètres et le résultat d'exécution de manière indépendante.

Les cartes sont réduites par défaut après la réussite de l'opération, ce qui réduit l'encombrement visuel lors des sessions prolongées. Elles sont développées par défaut en cas d'échec de l'opération, ou lorsque l'opération est en attente d'approbation/refus. L'historique du chat de session conserve toutes les cartes pour la durée de la session, fournissant une reconstruction complète opération par opération de tout ce que TAKpilot a fait et quand.

Implémentation de la porte d'approbation/refus pour les opérations destructives

Les cartes d'outils en streaming rendent les actions IA transparentes. La porte d'approbation/refus rend les actions destructives soumises à une autorisation explicite. Ce sont des mécanismes distincts abordant des modes de défaillance distincts : les cartes d'outils interceptent les erreurs d'interprétation que l'opérateur peut reconnaître et interrompre ; la porte empêche une catégorie d'actions à haute conséquence de s'exécuter même si l'opérateur ne les remarque pas à temps.

TAKpilot classifie chaque outil de sa bibliothèque comme additif ou destructif. Les opérations additives — place_marker, create_mission, subscribe_channel, create_data_package — créent ou augmentent des données de COP. Elles peuvent être annulées par une commande de suivi, qui passe elle-même par la porte destructive. Les opérations destructives — delete_mission, remove_track, clear_channel, delete_data_package et les opérations en masse affectant plusieurs enregistrements — suppriment ou modifient considérablement les données de COP de manière qui ne peut pas être trivialement annulée.

La classification est stockée dans config/gates.json et est vérifiée par la couche d'exécution de TAKpilot avant que tout appel API ne soit soumis à CloudTAK. Lorsque le modèle renvoie un appel d'outil pour une opération destructive, la couche d'exécution l'intercepte et lance le flux de porte au lieu de procéder à l'API. Le flux de porte comporte quatre étapes :

1. Énumération de la portée — TAKpilot interroge CloudTAK pour énumérer exactement ce qui sera affecté par l'opération : pour delete_mission avec un filtre de secteur, cela signifie récupérer chaque mission dans ce secteur. Pour clear_channel, cela signifie récupérer les abonnés actuels du canal et les messages en attente.
2. Affichage de la carte de porte — les enregistrements énumérés sont affichés dans le chat sous forme de carte de porte. Chaque enregistrement est affiché avec son symbole NATO le cas échéant, son nom, son indicatif ou propriétaire assigné, et son horodatage de dernière modification. L'opérateur voit les enregistrements réels qui seront affectés, pas un compte abstrait comme « 3 missions seront supprimées ».
3. Décision de l'opérateur — l'opérateur tape « confirmer » ou clique sur le bouton Approuver pour autoriser l'exécution, ou clique sur Refuser pour rejeter. La porte n'a pas de délai d'expiration. Si l'opérateur ne répond pas, l'opération ne s'exécute jamais. La fermeture de la carte de porte ou l'envoi d'un autre message annule l'opération en attente.
4. Routage d'exécution ou de refus — lors de l'approbation, l'appel API est soumis et le flux standard de cartes d'outils en streaming se termine. Lors du refus, TAKpilot renvoie le refus au modèle sous forme de résultat d'outil avec le statut denied_by_operator. Le modèle génère une question de suivi pour demander s'il faut affiner, réduire la portée ou annuler la demande.

La porte est implémentée comme un intercepteur strict de pré-exécution — et non comme un avis consultatif. Il n'existe aucun indicateur de configuration qui la désactive, aucun contournement administrateur, et aucune circonstance dans laquelle une opération destructive atteint l'API CloudTAK sans une approbation enregistrée de l'opérateur. C'est intentionnel : la valeur de la porte découle entièrement de sa nature inconditionnelle. Une porte qui peut être contournée sous la pression opérationnelle du temps est une porte qui sera contournée, et toute la propriété de sécurité disparaît.

Gestion d'une action refusée

Lorsqu'un opérateur refuse une opération en attente, le refus n'est pas simplement une annulation — c'est un signal de rétroaction qui réintègre le contexte du modèle. TAKpilot renvoie le refus sous forme de résultat d'outil structuré : {"status": "denied_by_operator", "reason": "<texte de l'opérateur si fourni>"}. Le modèle reçoit ce résultat dans le cadre de la conversation en cours et génère une réponse qui accuse réception du refus et propose des alternatives.

En pratique, les réponses aux refus suivent des schémas prévisibles. Si l'opérateur refuse parce que la portée était trop large (« Je ne voulais pas supprimer toutes les missions, juste celles du Peloton 2 »), le modèle utilise la raison du refus pour affiner la portée et présente une carte de porte révisée. Si l'opérateur refuse parce que l'opération a été déclenchée par une commande mal comprise, le modèle demande des éclaircissements plutôt que de réessayer. Si aucune raison n'est fournie, le modèle pose une seule question : « Souhaitez-vous modifier la portée de cette opération, ou l'annuler entièrement ? »

Chaque refus est enregistré dans le journal d'audit de session avec son propre horodatage, les paramètres de l'opération refusée et toute raison fournie par l'opérateur. Cela fournit un enregistrement complet non seulement de ce qui a été exécuté, mais de ce qui a été proposé et rejeté — ce qui a une valeur indépendante dans l'analyse après action de la façon dont la prise de décision assistée par l'IA a affecté le rythme opérationnel.

Isolation des données par session et modèle d'identité opérateur

L'architecture de session de TAKpilot est conçue pour contenir l'impact des actions d'une seule session et pour garantir que les opérations assistées par l'IA sont attribuées au bon opérateur humain dans chaque système d'audit qui les enregistre.

Chaque session de chat est isolée dans un bac à sable par session. Le contexte de session — historique de conversation, résultats d'appels d'outils, tout contenu de fichier téléchargé — est conservé en mémoire et supprimé à la fin de la session. TAKpilot ne conserve pas l'historique des conversations sur disque ou dans une base de données. Il n'y a pas de fuite de contexte entre sessions : une commande émise dans une session ne peut pas référencer ou affecter des données d'une session d'un autre opérateur. Pour les déploiements CloudTAK multi-utilisateurs où plusieurs opérateurs partagent un nœud, l'isolation de session garantit que la carte de porte en attente de l'Opérateur A n'est pas visible par l'Opérateur B et que les appels d'outils de l'Opérateur B n'apparaissent pas dans le journal d'audit de l'Opérateur A.

Tous les appels API CloudTAK sont soumis en utilisant le propre jeton de session de l'opérateur — pas un compte de service, pas une identité de bot, pas un identifiant partagé. Cela signifie que du point de vue de CloudTAK, chaque écriture exécutée par TAKpilot est indiscernable d'une écriture effectuée directement par l'opérateur dans l'interface CloudTAK. Le journal d'audit natif de CloudTAK affiche le nom d'utilisateur de l'opérateur pour chaque action assistée par TAKpilot. Les autorisations de contrôle d'accès de l'opérateur s'appliquent : si l'opérateur n'a pas l'autorisation de supprimer une mission dans le modèle d'autorisation de CloudTAK, la tentative de suppression de TAKpilot recevra un 403 de l'API, et l'opération échouera avec la carte d'erreur appropriée dans le chat.

Format et contenu du journal d'audit

TAKpilot maintient un journal d'audit structuré par session qui capture la provenance de chaque action effectuée pendant la session. Le format du journal est conçu à la fois pour la lisibilité humaine pendant la session et pour l'exportation analysable par machine vers les systèmes de révision après action.

Chaque entrée du journal contient :

• Horodatage — ISO 8601 avec précision à la milliseconde (2026-05-30T14:32:17.441Z).
• Identité de l'opérateur — le nom d'utilisateur CloudTAK associé au jeton de session (sgt_kovalenko), pas une identité de bot ou de service.
• Entrée en langage naturel — le message exact de l'opérateur qui a déclenché l'action, conservé mot pour mot, y compris les artefacts de transcription par dictée le cas échéant.
• Outil appelé — le nom de la fonction (delete_mission).
• Paramètres d'entrée — le JSON de paramètre complet tel que soumis à la couche d'exécution.
• Statut de la porte — si l'opération a été exécutée automatiquement (additive) ou a nécessité une approbation/refus, et si soumise à une porte, l'horodatage de confirmation et tout enregistrement de refus.
• Statut de réponse HTTP — le code de réponse de l'API CloudTAK (200, 403, 404).
• Latence d'exécution — millisecondes entre la soumission de l'API et la réponse.

Le journal est accessible dans l'interface de chat pour la durée de la session. Les opérateurs qui ont besoin d'un enregistrement persistant — pour la documentation formelle après action, les rapports d'unité ou les enquêtes sur les incidents — doivent exporter le journal de session avant de fermer la session. TAKpilot ne conserve pas le journal après la fin de session par conception : le modèle d'isolation de session exige que les données de session ne persistent pas au-delà de la limite de session.

Comment vérifier les garanties de sécurité de TAKpilot pour votre déploiement

Les étapes suivantes expliquent comment vérifier que l'architecture de sécurité de TAKpilot est correctement configurée pour un déploiement donné :

1. Examiner config/gates.json — confirmer que toutes les opérations destructives de votre bibliothèque d'outils sont listées dans le tableau gated. Tous les outils personnalisés ajoutés à la bibliothèque pour votre déploiement doivent être classifiés explicitement — l'omission d'un outil dans la classification est par défaut additive (non soumise à une porte).
2. Tester la porte avec une mission de test — dans un environnement CloudTAK hors production, envoyer une commande de suppression ciblant une mission de test connue. Vérifier qu'une carte de porte apparaît, qu'elle énumère le bon enregistrement, et que l'opération ne s'exécute pas jusqu'à ce que vous tapiez « confirmer ».
3. Tester le flux de refus — répéter ce qui précède et refuser l'opération. Vérifier que le refus est enregistré dans le journal de session et que le modèle génère une réponse de suivi plutôt que de réessayer silencieusement.
4. Vérifier l'identité de l'opérateur dans l'audit CloudTAK — après l'exécution d'une opération soumise à une porte, vérifier le journal d'audit natif de CloudTAK. L'écriture doit apparaître sous votre nom d'utilisateur opérateur, pas sous un compte de service.
5. Vérifier l'isolation de session — ouvrir deux sessions sur le même nœud avec des identifiants d'opérateur différents. Confirmer que les cartes d'outils et les entrées du journal d'audit de la Session A n'apparaissent pas dans le chat de la Session B.
6. Examiner le journal de session avant fermeture — à la fin d'une session de test, examiner le journal d'audit complet dans le chat et confirmer que chaque action, y compris les refus, est enregistrée avec les bons horodatages et valeurs de paramètres.
7. Documenter le modèle et la configuration de la porte dans votre SOP d'unité — enregistrer quel modèle est actif sur chaque type de nœud, quelles opérations sont soumises à une porte, et la procédure d'exportation des journaux de session pour la révision après action. Cette documentation fait partie de l'architecture de sécurité, ce n'est pas un complément facultatif.

Questions fréquemment posées

Lecture connexe : Pour un aperçu de la façon dont TAKpilot traduit le langage naturel en opérations CloudTAK de bout en bout, voir TAKpilot : contrôle de la COP en langage naturel pour les opérateurs tactiques CloudTAK. Pour les schémas API CloudTAK sous-jacents sur lesquels repose la bibliothèque d'outils de TAKpilot, voir Intégration API CloudTAK : connexion de systèmes externes à TAK Server. Pour la façon dont les architectures d'agents LLM gèrent l'appel d'outils et la sécurité avec opérateur humain en boucle de manière plus générale, voir Coopilote IA pour applications tactiques : comment les agents LLM contrôlent la COP.