Un agent peut disposer d’un accès valide et produire une action injustifiée. Il peut aussi reprendre un accord qui ne vaut plus au moment d’agir. Pour comprendre un incident, savoir quel compte a appelé un outil est donc nécessaire, mais insuffisant : il faut relier la demande, son autorité, la décision et l’effet effectivement observé.
Dans Swarm, je travaille sur cette chaîne à travers un moteur de transitions, des contrats de preuve et un pilote de contrôle par action. L’objectif est de rendre examinables les conditions d’un engagement, sans confondre les mécanismes présents avec une protection générale déjà qualifiée.
Premier scénario : le mandat est révoqué après l’accord
Considérons une demande de règlement préparée sous un mandat valide. Un accord est enregistré pour cette opération. Avant son engagement, le mandat est révoqué. Si le système conserve seulement l’état « approuvé », il risque d’exécuter une action dont l’autorité vient de disparaître.
L’écart se situe entre la vérification et l’utilisation de son résultat. Le droit d’agir ne dépend pas uniquement du dossier historique : il dépend aussi de l’état applicable au point qui engage l’effet. Une vérification au lancement du processus ne suffit donc pas à qualifier toutes ses opérations ultérieures.
Une décision passée explique ce qui était autorisé. Elle ne remplace pas la vérification de ce qui l’est encore au moment de l’engagement.
Dans le noyau Trust actuel de Swarm, le contrôle d’engagement relit le mandat, sa révocation, sa période de validité et la révision de politique applicable. Il examine également l’état approuvé et les éléments d’accord liés au contenu de l’action. Ce parcours concerne des effets simulés ; il ne démontre pas un paiement réel.
La limite temporelle compte : une révocation applicable avant le point d’engagement doit être distinguée d’une révocation survenue après un effet déjà engagé. Cette dernière n’annule pas rétroactivement l’opération. Si l’issue reste inconnue, le processus doit conserver cette incertitude et rechercher l’effet avant de décider une reprise.
La modification d’un bénéficiaire ou d’un autre paramètre sensible soulève le même besoin de liaison exacte. Un accord sur A ne devient pas un accord sur B parce que l’agent présente la modification comme mineure. L’OWASP AI Agent Security Cheat Sheet recommande précisément de relier l’accord à l’opération et d’en vérifier la validité dans le composant d’exécution. Cette recommandation ne constitue pas une qualification de Swarm.
Qui désigne-t-on par « l’agent » ?
Le principal auquel un accès est associé, l’agent logique, son instance, le délégant, le demandeur et l’approbateur sont des notions distinctes. Un nom de rôle dans un message ne prouve pas une identité authentifiée. Deux identifiants différents ne suffisent pas non plus à établir deux personnes indépendantes.
Le noyau Trust résout des identités et rôles à partir de sources d’authentification prévues par ses appelants de confiance. Cela ne transforme pas automatiquement un rôle local en personne d’entreprise identifiée, ni une chaîne de données correcte en approbation humaine attestée. Les raccords d’identité et leur qualification doivent rester explicites.
La distinction entre authentification et autorisation figure aussi dans la NIST SP 800-207. Une identité reconnue ne répond pas, à elle seule, à la question des opérations admises sur une ressource dans un contexte donné.
Deuxième scénario : l’autorité est valable, les faits sont faux
Considérons maintenant un agent qui propose une ouverture réseau vers un serveur présenté comme appartenant à un environnement de test. L’opération entre dans le périmètre d’un mandat. Mais la classification vient d’un inventaire ancien : le serveur porte désormais un service de production. Une autorisation techniquement cohérente peut alors affaiblir un isolement qui devait être conservé.
Un contrôle de droits ne découvre pas automatiquement cette erreur. Il faut une représentation vérifiable de la cible et une référence dont la provenance, l’actualité et l’intégrité sont examinées. Lorsqu’une contradiction apparaît, la décision doit exposer les éléments en conflit au lieu de laisser une synthèse les faire disparaître.
L’autorisation établit une condition du droit d’agir ; elle ne garantit pas la vérité de toutes les raisons invoquées pour agir.
Une empreinte de l’ancien inventaire permet d’identifier ce qui a été utilisé. Elle ne rend pas la classification actuelle. De même, une source signée reste susceptible d’être incomplète ou erronée. La comparaison peut démontrer une divergence définie, sans établir à elle seule toute la pertinence métier d’une modification.
Ce que Swarm permet d’examiner aujourd’hui
Le pilote Rust Trust conserve une action attribuée, ses paramètres, son mandat et des éléments de décision. Au point d’engagement simulé, il recontrôle l’autorité applicable et relie l’intention aux données exactes de l’opération. Les contrôles de validation et leurs artefacts constituent un autre contrat : un résultat de test ne devient pas une approbation métier.
Ces mécanismes ne démontrent ni connecteur bancaire ou pare-feu de production, ni classification automatique fiable d’un inventaire. Ils ne prouvent pas non plus l’authentification complète d’un fournisseur de modèle ou d’un approbateur humain. Une réponse du modèle affirmant « validé » ne crée aucun de ces faits.
La couverture des chemins d’accès reste déterminante. Un refus dans Swarm ne protège pas une ressource si un outil ou un processus peut l’atteindre directement par un autre chemin. Le confinement global OS/réseau n’est pas établi par le seul moteur.
Quelle preuve conserver ?
Une investigation doit pouvoir retrouver l’original de la demande, les paramètres effectivement considérés, l’autorité et la politique applicables, les contrôles effectués, la décision, puis le résultat connu ou inconnu. Il faut distinguer ce que déclare l’agent de ce qu’observe le composant d’exécution.
Les journaux ordinaires de Swarm restent soumis à leurs droits d’écriture et à leur rétention. Les preuves du pilote ont un périmètre et des hypothèses de vérification ; elles n’établissent pas un journal global inviolable, un horodatage qualifié ou une valeur juridique générale. Un hachage ne prouve pas l’identité de celui qui a produit les données.
Enfin, contrôler les appels ne détecte pas automatiquement une action nécessaire qui n’a jamais été demandée. Le suivi d’une obligation métier exige ses propres événements attendus, conditions et preuves. Il ne doit pas être déduit d’un simple intercepteur d’outils.
Le code de Swarm permet d’examiner ces contrats et leurs limites. La question « qui a autorisé ? » devient exploitable lorsque l’on peut répondre pour une opération exacte, dans un état identifié, sans confondre autorité, exactitude et effet.