Définir un contrat d’exécution pour les agents qui continuent après la déconnexion

Objectif

État au 25 octobre 2026. Définir ce qu’un agent peut faire après la déconnexion de son opérateur, la quantité de ressources qu’il peut consommer et la manière dont ses pouvoirs prennent fin. Vérifier à nouveau le comportement de redémarrage du superviseur déployé, le cycle de vie des identifiants d’accès et la prise en charge de l’annulation à distance. Ce contrat proposé complète la configuration des comptes de service par des contrôles portant sur l’ensemble d’une exécution sans supervision.

Prérequis

Désigner un responsable, un stockage durable des tâches et un superviseur capable d’arrêter le travail indépendamment du modèle. Inventorier les processus locaux, les agents enfants délégués et les traitements distants. Contrairement à une session interactive, ce flux de travail exige une réponse définie lorsqu’aucune clarification n’est disponible : enregistrer durablement un état bloqué et avertir le responsable par un canal approuvé.

Étapes

1. Consigner le contrat d’exécution. Enregistrer la révision de l’objectif, les ressources et actions permises, l’emplacement de sortie, l’échéance, le budget et la voie d’escalade. Attribuer au service sa propre identité restreinte et consigner séparément l’utilisateur à l’origine de l’exécution. Ne pas utiliser une copie du stockage d’identifiants d’une session interactive comme configuration d’identité du service.
2. N’accorder que les accès nécessaires. Utiliser les mécanismes d’identité des charges de travail de la plateforme. La documentation des comptes de service Kubernetes décrit des identités distinctes pour les charges de travail et automountServiceAccountToken: false pour les Pods qui ne doivent pas recevoir d’identifiants d’API montés automatiquement. Appliquer des permissions restreintes au niveau de la ressource à laquelle le service accède. Le renouvellement des identifiants d’accès ne doit pas prolonger implicitement la période d’autorisation de la tâche.
3. Budgéter l’ensemble de la tâche. Conserver durablement la consommation cumulée des enfants, des relances et des redémarrages de processus. Définir des limites pour le temps écoulé, les appels au modèle et aux outils, la concurrence d’exécution, le stockage et les services facturables. Réserver de la capacité avant le lancement lorsque des workers concurrents pourraient dépasser une enveloppe commune. Documenter les limites que le superviseur ou la passerelle applique réellement ; une phrase dans le prompt ne constitue qu’une demande.
4. Prévoir un mécanisme d’arrêt indépendant. À l’échéance ou lors d’un arrêt demandé par l’opérateur, bloquer tout nouveau lancement, désactiver le redémarrage automatique pour cette exécution et demander l’annulation des travaux suivis. Faire respecter l’expiration de l’autorisation au niveau de la passerelle d’écriture, lorsqu’elle existe. Rapprocher les opérations déjà acceptées à distance de leur état réel avant d’annoncer un arrêt terminé. Garder les effets non résolus visibles et empêcher tout rejeu aveugle après un redémarrage.
5. Préciser la portée des contrôles de la plateforme. Les Jobs Kubernetes prennent en charge activeDeadlineSeconds et la suspension. Suspendre un Job termine ses Pods actifs ; le reprendre réinitialise le compteur de durée maximale d’activité. Il faut donc conserver une échéance d’autorisation absolue en dehors de ce compteur. Traiter la suspension comme un contrôle du cycle de vie des processus, avec des points de reprise applicatifs durables nécessaires à la récupération, et vérifier séparément les résultats distants.
6. Rendre consultable l’état des exécutions sans supervision. Consigner les identifiants de tâche et de tentative, la révision de l’objectif, la référence d’identité, la consommation du budget, le résultat de l’outil et le motif d’arrêt, sans secrets. La propagation du contexte OpenTelemetry permet la corrélation des traces entre services. Exporter les journaux nécessaires avant le nettoyage des charges de travail. Pour un Job Kubernetes, kubectl get job JOB -o yaml affiche son état enregistré ; kubectl logs jobs/JOB constitue un point de départ pour examiner les sorties, pas un historique complet de toutes les tentatives.

Résultat attendu

Un opérateur déconnecté peut déterminer qui a autorisé une exécution, ce qui reste actif et si cette exécution est encore autorisée à écrire. Le redémarrage du worker conserve le budget restant et l’échéance initiale. Il reste possible de distinguer l’achèvement, l’attente d’une réponse, l’arrêt en cours et les résultats distants non résolus.

Limites et base de vérification

Il s’agit d’une procédure proposée, pas d’un déploiement testé. Dans un environnement isolé, tester la déconnexion de l’opérateur, l’épuisement du quota, le redémarrage et l’expiration pendant qu’une opération distante simulée est en attente. Vérifier qu’aucune nouvelle action n’est admise une fois la limite franchie et que les effets en attente restent enregistrés. La fin d’un processus ne peut pas prouver qu’une action distante a été annulée.