Un tableau de bord peut montrer une action dangereuse sans pouvoir l’arrêter. Cette distinction devient essentielle lorsqu’un agent IA dispose de droits sur des systèmes utilisés par plusieurs équipes. Connaître ce qu’il a fait et maîtriser ce qu’il peut engager sont deux propriétés différentes.
Dans ma grille de lecture de la maturité agentique, j’appelle « niveau 6 » l’effort consistant à relier l’orchestration à des conditions d’exécution explicites et vérifiables. Cette numérotation appartient à ma proposition ; elle ne désigne ni une norme reconnue ni un niveau de qualification obtenu par Swarm. Le critère utile est observable : une action privée de ses conditions requises peut-elle atteindre la ressource ?
Un compte, plusieurs applications touchées
Considérons un agent d’exploitation chargé d’examiner un compte suspect. Son nom ressemble à celui d’un utilisateur, mais il s’agit d’un compte de service partagé par plusieurs applications. L’agent propose sa suspension. S’il dispose d’un chemin direct vers l’administration des comptes, une erreur d’identification pourrait interrompre ces applications.
Un journal peut expliquer ensuite qui a demandé la suspension. Une alerte peut accélérer la réaction. Aucun des deux ne garantit que l’interruption n’aura pas lieu. Pour empêcher l’effet dans ce scénario, une condition doit être appliquée avant la modification de la ressource : la suspension de cette catégorie de compte exige un accord explicite portant sur la cible exacte.
L’observation éclaire l’action ; une condition obligatoire n’agit sur l’effet que si son application précède cet effet.
Le refus ne doit pas empêcher toute investigation. L’analyse autorisée peut continuer, les dépendances du compte être vérifiées et une demande corrigée être examinée. La distinction entre analyse et engagement évite que l’urgence supposée devienne une extension implicite du mandat.
Déterministe ne signifie pas infaillible
Un modèle supplémentaire peut aider à repérer une anomalie ou à enrichir l’analyse. Il ne suffit pas, par sa seule recommandation, à établir une condition obligatoire. Les règles déterministes servent ici à vérifier des entrées explicites et à produire une décision définie pour un état et une politique donnés.
Il faut conserver toutes les entrées qui comptent : identité, délégation, ressource, opération, paramètres, état observé, version de politique et conditions temporelles. Rejouer un dossier historique permet d’examiner sa décision. Cela ne réautorise pas la même opération aujourd’hui : le mandat peut être révoqué et l’état du compte avoir changé.
Une règle peut par ailleurs être erronée ou s’appuyer sur un inventaire périmé. Un moteur qui l’applique de façon reproductible ne corrige pas cette insuffisance. Le déterminisme facilite l’examen de la décision ; il ne prouve pas la vérité de toutes ses entrées.
Relier la décision à son point d’application
Produire les règles et les appliquer aux ressources sont deux responsabilités. Une architecture peut séparer leur gestion, leur diffusion et leur consommation, mais la signature d’un paquet ne prouve ni sa fraîcheur ni la réception de la dernière révocation.
Si la source de politiques devient indisponible, la conduite à tenir doit être définie selon l’action, les conditions de validité et le risque accepté. Conserver une politique en cache n’autorise pas à supposer qu’elle reste toujours valable. Pour une action sensible dont les conditions ne peuvent plus être établies, maintenir l’engagement en attente peut être nécessaire. Ce choix a un coût de disponibilité qu’il faut examiner.
Le chemin d’accès est tout aussi important. Un contrôle que l’agent peut ignorer en choisissant un autre outil n’impose pas sa décision à cette ressource. Il faut vérifier les accès effectifs, y compris ceux des processus descendants et des identités de service.
Une référence vérifiable, dans sa portée exacte
Pour notre compte, un référentiel d’identités peut aider à vérifier la catégorie et les dépendances. Il faut néanmoins examiner son origine, son actualité et les possibilités d’altération. Une empreinte lie des octets ; elle ne prouve pas qu’une classification est juste.
De même, comparer une valeur extraite à une référence fiable peut détecter une divergence définie. Cela ne tranche pas toute la pertinence métier. La compilation ou un test constituent des contrôles partiels, sans être un oracle universel de justesse. La justification doit être confrontée aux faits observables et aux conditions de l’opération.
Ce que cette proposition implique pour Swarm
Swarm contient un moteur de transitions et de vérification des preuves ainsi qu’un pilote Trust à effets simulés. Les contrôles réussis restent distincts de l’approbation humaine lorsqu’elle est exigée. Ces mécanismes constituent un terrain pour examiner le lien entre demande, conditions et décision.
Ils ne démontrent pas un connecteur d’administration des comptes, la suspension effective d’une identité ou le confinement global des accès système et réseau. Les contrats d’identité et de mémoire restent partiels, et la qualification globale demeure ouverte. Aucun délai de décision, journal inviolable ou conformité réglementaire générale n’est déduit de cette architecture.
L’évaluation utile porterait sur une cible mal classée, une approbation devenue périmée, un contrôle indisponible et un accès alternatif. Il faudrait observer l’effet réellement empêché ou engagé, puis les conditions de reprise. La maturité recherchée se mesure par ces contrats et ces preuves, plutôt que par le numéro inscrit sur un schéma. Le dépôt Swarm permet d’en examiner l’état actuel.