Un agent peut respecter une procédure et produire malgré tout un effet non autorisé. Tout dépend de l’origine de cette procédure, des outils accessibles et du contrôle appliqué au moment où une information sort ou une ressource change. La qualité du modèle compte ; elle ne suffit pas à établir ces conditions.
J’appelle armature l’organisation des contextes, méthodes, outils, décisions et observations qui encadre un usage agentique. C’est une grille d’architecture que je propose, pas un standard de certification. Elle aide à examiner les relations entre composants, plutôt qu’à compter les outils installés.
Une procédure de maintenance devient une instruction d’export
Considérons une équipe qui autorise un agent à analyser une panne. Le contexte inclut une procédure de maintenance provenant d’un espace documentaire. Une modification de cette page lui demande de constituer une archive de diagnostic et de l’envoyer à une nouvelle adresse de support. L’archive peut réunir des configurations, des noms de machines et des secrets présents dans des journaux.
L’agent dispose d’un outil d’archivage et d’un outil réseau. S’il traite la procédure comme une autorisation, une source documentaire obtient indirectement le pouvoir d’exposer ces données. L’erreur traverse plusieurs composants : récupération du texte, choix d’une méthode, constitution du fichier, puis transmission. Un contrôle limité au dernier message affiché à l’utilisateur arriverait après l’exposition.
Un document peut expliquer comment préparer une opération. Il ne décide pas, à lui seul, qui peut l’autoriser ni à qui ses données peuvent être transmises.
Le processus doit maintenir la distinction entre la demande initiale, le contenu rencontré et l’autorité de l’action. La préparation de l’archive peut rester utile ; sa transmission exige une destination autorisée et un contenu compatible avec cette destination. Une adresse joignable ou une clé API valide ne règle pas cette question.
Les relations à examiner dans l’armature
Le contexte décrit la mission, les ressources et les contraintes. Les skills formalisent des méthodes et leurs conditions d’emploi. Les outils définissent les actions techniquement possibles. Les points de contrôle vérifient les préconditions avant les effets qu’ils peuvent bloquer. L’orchestration distribue les tâches, les décisions et les reprises. L’observation conserve les événements utiles à l’enquête. La gouvernance de l’information suit les sources, leurs versions, leurs droits d’usage et leur devenir.
L’identité et l’autorisation traversent cet ensemble. Un nom de rôle n’authentifie pas une instance ; une instance authentifiée n’acquiert pas tous les droits nécessaires à ses propositions. Le NIST SP 800-207 distingue précisément authentification et autorisation et écarte la confiance implicite fondée sur la seule localisation.
Ces éléments ne forment pas une échelle universelle où ajouter une couche garantirait le résultat. Un outil supplémentaire peut aussi ouvrir un chemin de contournement. Une observation externe doit être protégée et complète dans son périmètre ; sa séparation logique ne la rend pas inaltérable. Un contrôle fondé sur une analyse IA garde les limites de cette analyse.
Relier le contrôle à l’effet réel
Dans notre maintenance, il faut retrouver la version de la procédure consultée, qualifier son origine, déterminer les données de l’archive et vérifier le destinataire avant l’envoi. Si un canal de transfert est refusé, un autre outil ne devrait pas permettre le même export hors contrôle. Le risque résiduel se juge sur ces voies effectives.
L’OWASP AI Agent Security Cheat Sheet recommande de limiter les privilèges et de séparer proposition et contrôle d’exécution. Ces principes orientent une conception ; leur citation ne prouve pas leur application dans un produit.
Il faut aussi organiser la reprise. Retirer une procédure ne retire pas les contextes déjà délivrés. Bloquer un nouvel envoi n’efface pas une transmission antérieure. Une erreur réseau peut laisser son résultat incertain : la décision suivante doit conserver ce qui est connu et ce qui ne l’est pas.
La place de Swarm
Swarm est mon terrain de développement pour relier plans, tâches, responsabilités, validations et preuves. Ses contrats Rust comprennent des contrôles sur les preuves de validation et un noyau Trust liant des actions à des mandats et à des paramètres. Le pilote Trust produit des effets simulés. Les mécanismes Biba et Bell–LaPadula traitent des frontières ciblées d’intégrité et de confidentialité ; leur présence ne démontre pas une couverture de toutes les mémoires, de tous les outils ou de toutes les sorties.
L’armature recherchée dépasse donc la seule orchestration. Elle suppose aussi l’intégration aux ressources, la maîtrise des secrets et les protections système et réseau. Swarm ne constitue pas, par son seul moteur, un confinement global ni une certification de cette architecture.
Le dépôt Swarm rend ces contrats examinables. La question utile reste concrète : pour cette opération, quelles données ont été utilisées, quelle autorité reste valable et quel composant peut encore empêcher un effet non autorisé ?