Que prouvent les tests de fermeture forcée sur une passerelle d'agent ?

Une passerelle qui conserve les identifiants d'un agent IA doit rester sûre lorsque son processus disparaît au pire moment. Un test du parcours normal peut montrer qu'une approbation apparaît, qu'une requête réussit et qu'un enregistrement d'audit existe ensuite. Il ne peut pas montrer si un identifiant s'est échappé pendant une requête interrompue ni si la piste d'audit prétend qu'un travail terminé n'a jamais été effectué.

Les tests de fermeture forcée révèlent les écarts entre des affirmations comme « la requête a commencé », « l'identifiant a été ajouté », « le système distant l'a reçu » et « l'enregistrement est durable ». Ce sont des faits distincts. Les traiter comme un seul événement conduit à déployer une passerelle d'actions qui semble maîtrisée jusqu'à ce qu'un plantage transforme une nouvelle tentative ordinaire en double déploiement ou en appel sortant impossible à retracer.

Pour une passerelle macOS, distinguez la fermeture normale de la mort du processus. Apple décrit la fin normale d'une application comme un parcours du cycle de vie durant lequel l'application peut enregistrer son état et gérer sa terminaison. Une terminaison forcée peut ne lui laisser aucune occasion de le faire. Apple identifie également SIGKILL comme un type de terminaison pouvant se produire lorsqu'un utilisateur force la fermeture d'une application. Votre plan de test doit donc partir du principe que les gestionnaires de nettoyage, les écritures différées et la télémétrie de dernier recours ne s'exécutent pas.

La bonne question n'est pas « l'application redémarre-t-elle ? ». La bonne question est la suivante : à chaque point d'interruption, pouvez-vous dire exactement quels effets secondaires sont possibles, lesquels sont impossibles et quelles preuves subsistent ?

Une fermeture forcée doit couper court au nettoyage

Un test de fermeture forcée n'est valable que s'il retire à la passerelle la possibilité de ranger les choses. Si le test appelle une fonction d'arrêt polie, attend que les files se vident, force l'écriture des journaux, puis quitte, vous avez testé une terminaison ordonnée. C'est utile, mais cela ne correspond pas au scénario qui préoccupe les ingénieurs sécurité.

Utilisez deux modes de terminaison et nommez-les correctement :

• Une demande de terminaison normale teste la gestion de l'annulation, la fermeture ordonnée des fichiers et la manière dont l'interface signale une session interrompue.
• Un arrêt brutal teste l'état de la mémoire, des tampons de fichiers, des sockets ouvertes et du travail en cours lorsqu'aucun nettoyage de l'application ne s'exécute.

Sur macOS, un banc de test peut utiliser kill -TERM dans le premier cas et kill -KILL dans le second. SIGTERM laisse à un processus la possibilité de gérer sa terminaison. SIGKILL ne la lui laisse pas. N'appelez pas les deux cas « fermeture forcée » dans le tableau de résultats, car ils répondent à des questions différentes.

# Find the gateway process you started for the test.
pgrep -fl Sallyport

# Graceful termination case.
kill -TERM 48192

# Abrupt termination case.
kill -KILL 48192

# Confirm the process is gone.
ps -p 48192
# PID TTY           TIME CMD
# 48192 ttys003    0:00.42 gateway-test
# After SIGKILL, ps should print no process row.

L'identifiant du processus n'est pas l'identifiant du test. Donnez à chaque exécution un identifiant d'exécution, un identifiant d'action et un identifiant de requête distante. Placez ces identifiants dans les enregistrements du dispositif de test et dans ceux de la passerelle. Sans identifiants communs, vous finirez par comparer des horodatages et deviner si un POST distant appartenait à l'exécution que vous avez tuée.

Ne testez pas sur un point d'accès de production, même si vous pensez que l'appel est sans danger. Le but est de créer volontairement des résultats ambigus. Construisez un récepteur qui peut s'arrêter avant d'accepter un corps, après la lecture des en-têtes, après l'enregistrement du corps ou avant la libération de sa réponse. Une véritable API tierce ne vous offrira pas forcément ces limites et peut imposer des nouvelles tentatives ou une mise en cache que vous n'avez pas demandées.

La requête a besoin de points d'interruption explicites

Vous ne pouvez pas tuer un processus « pendant l'injection des identifiants » tant que l'implémentation n'a pas défini ce que cela signifie. Ajoutez des points d'attente observables autour du parcours d'action. Ce sont des contrôles de test, pas un langage de règles ni un mécanisme d'autorisation de production.

Pour une action HTTP, utilisez une séquence comme celle-ci :

1. La passerelle accepte une description d'action autorisée et lui attribue un identifiant d'action.
2. Elle écrit un enregistrement d'intention, si la conception l'exige avant toute opération réseau.
3. Elle résout l'identifiant dans le processus protégé.
4. Elle construit la requête sortante et y injecte l'identifiant.
5. Elle ouvre la connexion et écrit la requête.
6. Elle reçoit assez de la réponse pour classer le résultat distant.
7. Elle écrit un enregistrement d'achèvement ou de résultat inconnu, puis renvoie le résultat à l'agent.

Installez une pause après chacune des opérations numérotées. Cette pause doit être observable depuis un autre processus. Un socket local réservé aux tests, un tube nommé ou un descripteur de fichier contrôlé par le banc de test convient. Un appel à sleep convient mal, car les variations de temps transforment un test de limite en course entre les tâches.

Un protocole compact pour le dispositif de test peut ressembler à ceci :

{
  "action_id": "fq-2026-07-22-017",
  "hold_after": "request_headers_built",
  "release": false
}

La passerelle s'arrête après la création des en-têtes, mais avant toute tentative de connexion. Le banc de test confirme cet état, tue le processus, puis demande au récepteur s'il a vu une connexion. Le résultat attendu est de zéro requête entrante et de zéro en-tête contenant un identifiant. Si le récepteur a vu une requête à ce stade, votre point de contrôle arrive trop tard ou une tâche en arrière-plan a franchi la limite sans être prise en compte.

Gardez les points de contrôle précis. « Avant toute opération réseau » est trop large si la résolution DNS, la création de la connexion, la négociation TLS et la transmission du corps s'exécutent dans des tâches différentes. Il n'est pas nécessaire d'ajouter un point de contrôle dans chaque appel de bibliothèque, mais il faut assez de structure pour dire si le serveur distant pouvait recevoir des identifiants ou un corps qui modifie l'état.

La même idée s'applique à SSH, avec des preuves différentes. Arrêtez-vous avant que sp-ssh ne reçoive une demande de connexion utilisant un identifiant, après le démarrage de l'assistant mais avant l'authentification, après l'authentification mais avant le début de la commande et après le retour de la commande distante mais avant la validation locale de l'achèvement. Enregistrez le début et la fin de la commande distante sur un hôte de test jetable. N'inférez pas l'exécution d'une commande à partir d'une connexion TCP ouverte.

Tuer le processus avant l'injection ne doit laisser aucune trace distante

Le scénario d'échec le plus précoce a le résultat attendu le plus net : si la passerelle meurt avant d'avoir ajouté un identifiant ou commencé le transport, aucun service externe ne doit rien voir de cette action.

Cela paraît évident, mais les implémentations mélangent souvent préparation et envoi. Une bibliothèque cliente peut commencer une connexion pendant qu'une autre tâche récupère ou formate un en-tête. Un mécanisme de nouvelle tentative peut créer une requête sortante avant le code qui écrit l'enregistrement de journal prévu. Un rappel de métriques peut écrire une description d'action contenant un paramètre d'URL que votre parcours normal de masquage ne traite jamais.

Testez quatre interruptions avant l'envoi :

• Après l'autorisation, mais avant toute recherche d'identifiant.
• Après la recherche de l'identifiant, mais avant la construction de la requête.
• Après la construction de la requête, mais avant le début d'une connexion socket.
• Après le début de la connexion, mais avant que le moindre octet contenant un identifiant ne quitte le processus.

Chaque interruption appelle une assertion différente. Avant la recherche de l'identifiant, inspectez les diagnostics et les journaux qui ne risquent pas d'exposer la mémoire, afin de vérifier l'absence de valeurs ou de marqueurs susceptibles d'être remplacés ensuite. Après la recherche, inspectez les mêmes sorties et vérifiez que le secret n'a jamais franchi la limite du processus. Avant la connexion, le récepteur ne doit avoir aucun enregistrement de connexion. Pendant l'établissement de la connexion, il peut voir un échec de négociation ou une tentative de connexion, mais il ne doit recevoir ni en-tête d'autorisation, ni champ basic-auth, ni en-tête d'identifiant personnalisé, ni tentative d'authentification SSH.

Cette distinction compte parce qu'une tentative de connexion n'est pas une action authentifiée. Ne signalez pas « aucune action ne s'est produite » si le point distant a enregistré une tentative de connexion. Énoncez la vérité précise : aucun identifiant n'a été envoyé et aucune requête applicative n'a été reçue. Les enregistrements de sécurité perdent de leur valeur lorsqu'ils effacent des preuves dont les opérateurs auront besoin lors d'un examen d'incident.

La conception de Sallyport rend cette limite particulièrement importante à tester : l'agent ne doit jamais détenir un identifiant en clair, tandis que l'application effectue l'action HTTP ou SSH utilisant cet identifiant et renvoie un résultat. Le test n'est pas terminé parce que l'agent ne possède pas le secret. Il l'est lorsque la mort de la passerelle ne peut pas non plus transformer une action à moitié préparée en requête sortante contenant un secret.

L'injection est un événement local, pas une preuve d'envoi

L'injection des identifiants est le point où les équipes commettent l'erreur de suivi la plus grave. Elles journalisent « identifiant utilisé » lorsque le code construit un en-tête ou remet une identité à une bibliothèque SSH. Cet événement indique que la passerelle s'est préparée à s'authentifier. Il ne prouve pas qu'un pair l'a reçu.

Séparez au moins quatre états locaux :

Tuez le processus après la résolution de l'identifiant, puis une autre fois après la création de l'objet de requête, mais avant le début de l'écriture du transport. Dans les deux cas, l'agent ne doit recevoir aucun secret et le dispositif distant ne doit enregistrer aucune requête contenant un identifiant. Le journal d'action doit afficher soit un état de préparation interrompue, soit aucun enregistrement persistant, selon l'emplacement de votre limite de durabilité. Ne fabriquez pas une action terminée simplement pour donner au journal une apparence ordonnée.

Tuez ensuite le processus au premier point où la bibliothèque de transport peut écrire. C'est le test difficile. Le processus local a peut-être appelé une fonction d'écriture, mais le noyau, le proxy, la couche TLS ou le service distant n'a peut-être pas reçu la requête complète. Votre résultat attendu doit être outcome=unknown, sauf si le récepteur possède une preuve positive qu'il a reçu ou n'a pas reçu la requête.

Évitez de journaliser tous les en-têtes de requête pour simplifier ce test. Ce raccourci crée un second chemin d'exposition du secret. Faites plutôt calculer au dispositif de test un marqueur irréversible à partir de la valeur reçue et ne stockez que ce marqueur. La passerelle peut conserver une référence d'identifiant ou un identifiant interne. Pendant le test, comparez les identifiants et les marqueurs sans afficher l'identifiant lui-même.

Un enregistrement utile du dispositif de test peut avoir cette forme :

{
  "action_id": "fq-2026-07-22-017",
  "connection_seen": true,
  "headers_complete": true,
  "credential_marker": "sha256:7b8c...",
  "body_complete": false,
  "response_sent": false
}

Utilisez un identifiant réservé aux tests, dont la valeur n'existe nulle part ailleurs que dans le dispositif de test. Même ainsi, gardez-le hors des captures d'écran, de l'historique du shell et des journaux ordinaires. Un secret jetable reste un objet qui ressemble à un secret, et les habitudes de test finissent souvent par atteindre le code de production.

Les opérations réseau créent un état inconnu honnête

Dès qu'une requête qui modifie l'état peut quitter la machine, la certitude locale disparaît avant que le système distant ait forcément répondu. Ce cas doit guider le comportement des nouvelles tentatives, le texte de l'interface et la sémantique de l'audit.

Prenons un POST qui demande à un service de déploiement de lancer une livraison. La passerelle écrit la requête complète. Le service conserve la tâche de déploiement. Avant que la réponse n'atteigne la passerelle, vous tuez son processus. Au redémarrage, trois réalités sont possibles :

1. Le service n'a jamais reçu la requête.
2. Le service a reçu la requête, mais l'a refusée.
3. Le service a accepté la requête et créé un déploiement.

La passerelle locale peut ne pas savoir laquelle s'est produite. Un enregistrement marqué failed est faux dans le troisième cas. Un enregistrement marqué succeeded est faux dans les deux premiers. Marquez-le unknown et conservez l'identifiant d'action, l'identifiant de requête distante, la destination, la méthode et le point auquel l'observation locale s'est arrêtée.

C'est aussi le moment où les nouvelles tentatives aveugles causent des dommages. Les équipes aiment les nouvelles tentatives automatiques parce que les défaillances réseau temporaires sont fréquentes et que les démonstrations réussies donnent une impression de fluidité. Pour un GET, une nouvelle tentative est généralement acceptable si elle ne provoque pas de comptage côté serveur ni de problème de limitation. Pour un POST, un PATCH, une commande distante ou un appel d'API capable d'écrire, elle exige un mécanisme d'idempotence ou une réconciliation ultérieure.

Utilisez la fonction d'idempotence du système distant lorsqu'elle existe. Fournissez un jeton d'idempotence propre à l'action, et non un jeton réutilisé pendant toute la session de l'agent. Si l'API distante ne la prend pas en charge, créez un parcours de recherche distant qui puisse répondre à la question : l'identifiant d'action a-t-il déjà été accepté ? Faites cette vérification avant de réessayer. Si aucune de ces solutions n'existe, demandez à un humain de décider. C'est moins élégant qu'une récupération automatique, mais bien plus sûr qu'une double exécution.

Testez exactement cette séquence avec votre récepteur :

Gateway writes intent record
Gateway sends POST with action ID fq-2026-07-22-017
Receiver stores action ID and body
Receiver delays its HTTP response
Harness kills gateway with SIGKILL
Gateway restarts
Agent requests retry
Gateway checks receiver for action ID before another POST

Le résultat doit montrer une seule action distante enregistrée et un seul enregistrement local présentant un résultat interrompu ou inconnu, qui est ensuite rapproché de l'état distant. Si le second POST apparaît avant la vérification de réconciliation, le test a trouvé un défaut de nouvelle tentative. Si le journal écrase l'incertitude et ne conserve qu'un enregistrement de réussite propre, il a trouvé un défaut d'audit.

Ne vous appuyez pas sur les événements de fermeture TCP pour prouver qu'une application distante n'a pas agi. Une socket peut se fermer après que le pair a déjà remis la requête à son code applicatif. L'enregistrement durable de l'action côté récepteur est la preuve importante.

La validation de l'audit doit avoir une promesse de durabilité définie

Un journal d'audit ne devient pas fiable parce qu'il contient une chaîne de hachage. Une chaîne de hachage peut révéler une modification ou une suppression dans la séquence qui subsiste. Elle ne peut pas récupérer un événement qui n'a jamais atteint un stockage durable avant la mort du processus.

Écrivez cette promesse en une phrase. Par exemple : « Avant qu'une passerelle ne commence une action externe qui modifie l'état, elle enregistre durablement l'intention de l'action ; après avoir observé un résultat, elle enregistre durablement ce résultat avant de le renvoyer à l'agent. » Testez ensuite les deux verbes, « commence » et « durablement », au lieu de traiter un objet en mémoire horodaté comme un enregistrement.

POSIX définit fsync() comme une demande de transfert des données d'un fichier vers le stockage associé et précise que l'appel ne renvoie pas la main avant la fin de cette opération ou le signalement d'une erreur. La norme avertit également que les garanties du stockage dépendent de l'implémentation et de la configuration. Cet avertissement n'est pas une raison pour ignorer l'appel. Il signifie que vous devez préciser ce que votre logiciel peut promettre et tester le comportement de récupération qu'il contrôle.

Pour un journal chiffré et chaîné par hachage, testez au moins les interruptions suivantes :

• Tuer le processus après l'écriture d'une entrée proposée, mais avant sa barrière de durabilité.
• Tuer le processus après la barrière de durabilité, mais avant la mise à jour de l'index en mémoire.
• Tuer le processus après la durabilité d'une entrée d'achèvement, mais avant que l'agent ne reçoive la réponse.
• Tuer le processus pendant la compaction, la rotation ou tout processus de projection du journal.

Après chaque redémarrage, exécutez la commande de vérification hors ligne et inspectez à la fois la séquence d'audit brute et les vues présentées à l'utilisateur. Sallyport fournit sp audit verify pour vérifier son journal d'audit chiffré et chaîné par hachage sans exiger la clé du coffre. Cela le rend utile dans cette série de tests, mais la vérification doit rester une assertion parmi d'autres, pas constituer tout le test.

Vos résultats attendus doivent être nuancés. L'absence d'un enregistrement après un arrêt avant sa limite de durabilité peut être acceptable si aucune action externe n'a commencé. L'absence d'un enregistrement après le début d'une requête qui modifie l'état n'est pas acceptable si la conception promet une intention écrite à l'avance. Un enregistrement présent avec un résultat inconnu est souvent correct. Un enregistrement qui affirme l'achèvement avant l'observation de la réponse distante est faux, même si le test réussit généralement par hasard.

Séparez l'historique d'exécution de l'agent de l'historique des appels d'action lorsque vous inspectez la reprise. Une session peut se terminer brutalement alors que plusieurs actions ont des résultats différents. Une seule entrée au niveau de l'exécution indiquant « terminée » ne remplace pas les enregistrements propres à chaque appel, notamment pour une requête qui a atteint le système distant et une autre qui n'a jamais quitté la mémoire.

L'état d'approbation ne doit pas survivre à son sujet

Un redémarrage teste l'état de l'autorisation autant que la durabilité. Si une passerelle autorise un processus d'agent précis pour une session, le fait de la tuer ne doit pas transformer cette autorisation en permis réutilisable par un nouveau processus qui effectuerait une requête similaire.

La règle sûre la plus simple est de rattacher l'approbation de session à l'identité observée du processus et de la faire disparaître avec cette exécution. Après un redémarrage, un nouveau processus d'agent a besoin d'une nouvelle autorisation de session. Un processus qui est resté en vie pendant le redémarrage de la passerelle a également besoin d'une nouvelle décision, sauf si la passerelle peut rétablir exactement le lien d'identité et si le produit documente volontairement ce comportement. Ne restaurez pas une approbation depuis un enregistrement de cache vague comme le nom de la commande, le répertoire de travail ou un libellé de processus convivial.

Testez la limite du redémarrage avec deux agents qui semblent identiques sur la ligne de commande, mais dont l'autorité de signature ou l'origine de l'exécutable diffère. Approuvez le premier. Arrêtez la passerelle pendant une action. Redémarrez-la. Faites ensuite exécuter la même action par le second agent. La passerelle doit afficher une nouvelle décision d'approbation, sans hériter de la session du premier agent.

L'approbation par appel appelle un test différent. Tuez la passerelle lorsque la carte d'approbation est visible, puis redémarrez-la et répétez l'action. L'ancien événement d'interface ne doit pas autoriser le nouvel appel. Tuez le processus après l'approbation de l'utilisateur, mais avant la résolution de l'identifiant, puis vérifiez que le nouveau processus ne peut pas réutiliser l'ancienne approbation. Ces tests détectent une erreur fréquente : conserver le booléen « approuvé » sans le rattacher à un identifiant d'action, à une session précise et à une condition d'expiration.

Les contrôles fixes de Sallyport donnent une forme claire à ce test. Sa porte de coffre refuse les actions lorsqu'il est verrouillé, son autorisation de session est liée à un nouveau processus d'agent et certains identifiants peuvent exiger une approbation à chaque utilisation. Les tests de fermeture forcée doivent prouver que ces limites restent vraies lorsque l'interface, l'état du coffre et le parcours d'action redémarrent à des moments différents.

Préparez une matrice de résultats avant d'exécuter la suite

Un test qui dit simplement « tuer le processus à l'étape X » laisse trop de place à l'interprétation. Créez une matrice avec les points d'interruption en lignes et les résultats observables en colonnes. Examinez le résultat attendu avant d'écrire le code du test. Si l'équipe ne parvient pas à s'entendre sur ce qui doit se passer, l'implémentation ne possède pas encore de contrat de défaillance défini.

Utilisez ces colonnes :

Les mots « peut-être » et « inconnu » ne sont pas des faiblesses. Ils décrivent honnêtement le travail distribué. Le mot dangereux est « échouée » lorsque la passerelle n'a aucune preuve que le service distant n'a pas agi.

Exécutez chaque ligne plusieurs fois, mais ne faites pas de la répétition un substitut au contrôle. Cent arrêts aléatoires peuvent manquer la limite entre l'ajout au journal et sa barrière de durabilité. Un seul arrêt contrôlé sur un point d'attente peut montrer ce que fait cette limite. Répétez ensuite pour détecter les courses, les erreurs d'ordonnancement et le déplacement accidentel du point de contrôle.

Récupérez les éléments des deux côtés à chaque exécution : la chronologie des événements du banc de test, la liste durable des actions du dispositif distant, les informations de sortie du processus, les diagnostics de reprise de la passerelle, le résultat de vérification de l'audit et la sortie visible par l'agent. Placez l'identifiant d'exécution dans le nom du fichier. En cas d'échec, conservez les preuves avant de relancer le test. La seconde exécution détruit souvent le seul indice utile.

Traitez les écarts comme un travail de conception, pas comme du bruit de test

Lorsqu'un test de fermeture forcée révèle un désaccord entre le journal de la passerelle et le dispositif distant, résistez à l'envie de modifier l'assertion jusqu'à ce qu'elle passe. Le désaccord est généralement le résultat du test.

Si le dispositif indique qu'une requête a été acceptée alors que la passerelle n'enregistre aucune intention, déplacez la limite d'intention durable plus tôt ou arrêtez l'action avant cette limite. Si la passerelle indique un achèvement alors que le dispositif ne présente aucune action, déterminez si elle a confondu une écriture locale avec un résultat distant. Si un agent redémarré peut agir sans nouvelle approbation, corrigez le lien d'identité au lieu d'ajouter un délai plus long.

Le meilleur résultat n'est pas un tableau de bord rempli de tests verts. C'est un contrat de défaillance utilisable par un opérateur sous pression : cette action n'a certainement pas quitté la machine ; cette action a peut-être atteint le système distant et doit être réconciliée ; cette action est terminée et son enregistrement a survécu à la vérification. Ce sont les seules catégories qui permettent de justifier une décision après un plantage.

Exécutez cette suite chaque fois que vous modifiez la gestion des identifiants, les bibliothèques de transport, la journalisation, le comportement des nouvelles tentatives, la supervision des processus ou la gestion des approbations. Une passerelle mérite la confiance lorsqu'elle se comporte de façon prévisible alors qu'elle n'a aucune occasion de s'expliquer.