Delegation-Aware Runtime Contracts for Open LLM Multi-Agent Systems: Constraint Preservation, Capability Revocation, and State Recovery

Imaginez un monde où vous ne parlez pas seulement à un seul robot intelligent, mais à toute une équipe de robots travaillant ensemble. Dans ce monde, un robot « gestionnaire » pourrait dire : « Hé, toi, va trouver le meilleur prix pour un nouvel ordinateur portable », puis ce robot pourrait dire à un troisième robot : « Toi, va vérifier les sites web ». C'est ce qu'on appelle un système multi-agents. C'est comme une course de relais numérique où le témoin est une tâche. Mais voici la partie délicate : quand le premier robot transmet la tâche au second, il se contente généralement de lui murmurer les instructions en langage clair. Si le premier robot dit : « Ne dépense pas plus de 500 $, » le second robot pourrait n'entendre que « Trouve un ordinateur portable » et oublier totalement la limite de prix. Cela arrive parce que les ordinateurs sont excellents pour suivre des règles, mais ils ne sont pas toujours très bons pour se souvenir des détails importants lorsqu'ils transmettent une conversation. Les scientifiques craignent que si nous laissons ces équipes de robots agir sans de meilleures règles, elles puissent accidentellement dépenser tout notre argent, divulguer nos secrets ou faire des choses que nous ne leur avons jamais demandées.

Ce document présente une nouvelle façon de gérer ces transferts de tâches entre robots, appelée DARC (Delegation-Aware Runtime Contracts - Contrats d'exécution sensibles à la délégation). Imaginez cela comme le fait de donner aux robots un sac à dos spécial et incassable plutôt qu'un simple murmure. Chaque fois qu'un robot transmet une tâche à un autre, il ne se contente pas de dire « va » ; il transmet un contrat numérique à l'intérieur de ce sac à dos. Ce contrat liste exactement ce que le nouveau robot est autorisé à faire, ce qu'il ne peut pas faire, combien d'argent il peut dépenser et quand sa mission expire. Le document montre que si vous utilisez ces contrats, vous pouvez prouver mathématiquement que le nouveau robot ne peut pas soudainement obtenir plus de pouvoir que l'ancien, et qu'il ne peut pas oublier les limites budgétaires. L'auteur a construit un système pour vérifier ces sacs à dos automatiquement. Il a découvert que sans ces contrats, les règles disparaissent souvent au fur et à mesure que les tâches sont transmises, mais avec eux, les règles restent verrouillées. Cependant, le document précise que si les parties « mathématiques » (comme les limites d'argent ou de temps) sont parfaitement sûres, les parties qui nécessitent de comprendre le sens du langage humain (comme « être poli ») sont encore un peu délicates et nécessitent plus de tests.

Le Problème : Le « Jeu du Téléphone » des Équipes de Robots

Imaginez jouer au jeu du « Téléphone » avec un groupe d'amis. Vous murmurez un secret à la première personne, qui le murmure à la suivante, et ainsi de suite. Au moment où il atteint la dernière personne, le secret a généralement changé. Peut-être que « Ne mange pas le gâteau » est devenu « Mange le gâteau ! ».

Dans le monde de l'IA, c'est exactement ce qui se passe lorsqu'une équipe d'agents de modèles de langage étendu (LLM) travaille ensemble. Un agent (le patron) donne une tâche à un autre agent (l'ouvrier). Le patron peut dire : « Trouve un vendeur, mais ne dépense pas plus de 1 000 $ et ne montre pas notre liste d'employés. » L'ouvrier entend cela et transmet la tâche à un troisième agent (le surfeur du web). Mais comme le message n'est que du texte brut, le troisième agent n'entend peut-être que : « Trouve un vendeur. » La limite budgétaire et la règle de confidentialité se sont évanouies dans la nature !

Ceci est dangereux. Si une équipe de robots gère le budget d'une entreprise ou manipule des données privées, perdre ces règles signifie que les robots pourraient accidentellement dépenser des millions ou divulguer des secrets. Le problème n'est pas que les robots sont « mauvais » ; c'est que la façon dont ils se parlent traite les règles de sécurité importantes comme des suggestions optionnelles plutôt que comme des lois strictes.

La Solution : Le Sac à Dos Incassable (DARC)

L'auteur de ce document, dirigé par Vinay Bamil, propose une solution appelée DARC. Au lieu de simplement transmettre un message textuel, chaque fois qu'un agent délègue une tâche, il doit remettre un Contrat de Délégation.

Considérez ce contrat comme un sac à dos spécial et incassable qui accompagne la tâche. À l'intérieur de ce sac à dos, il y a des étiquettes claires et lisibles par machine qui disent :

• Ce que vous pouvez faire : (ex. : « Vous pouvez vérifier les prix, mais vous ne pouvez rien acheter. »)
• Ce que vous ne pouvez pas faire : (ex. : « Vous ne pouvez pas consulter les dossiers des employés. »)
• Le budget : (ex. : « Il vous reste exactement 500 $ à dépenser. »)
• L'expiration : (ex. : « Cette tâche n'est valable que pour 1 heure. »)
• L'historique : (ex. : « Cette tâche provient de l'Agent A, qui l'a reçue du Patron. »)

La magie de DARC est qu'il traite ces règles comme des mathématiques, et non comme de simples mots. Lorsqu'un robot tente de transmettre une tâche à un nouveau robot, un « Médiateur » (un garde de sécurité) vérifie le sac à dos. Si le nouveau robot essaie de prendre une règle qui n'était pas là, ou s'il essaie d'ajouter un nouveau pouvoir qu'il n'avait pas auparavant, le garde dit : « Non ! » et arrête le transfert.

Comment cela fonctionne : Le Garde de Sécurité et le Sac à Dos

Le système fonctionne en trois étapes principales, comme un point de contrôle de sécurité dans un aéroport :

1. Le Transfert (Médiateur) : Lorsque l'Agent A veut donner une tâche à l'Agent B, le Médiateur vérifie le sac à dos. Il s'assure que l'Agent B ne demande pas plus de pouvoir que l'Agent A n'en avait. Si l'Agent A avait un budget de 500 $, l'Agent B ne peut pas obtenir un budget de 600 $. Si l'Agent A avait une règle sur le « non-accès aux données des employés », l'Agent B doit conserver cette règle. Le sac à dos est construit avant que la tâche ne soit transmise, il est donc impossible d'oublier les règles.
2. L'Action (Passerelle) : Lorsque l'Agent B essaie de réellement faire quelque chose (comme acheter un ordinateur portable ou lire un fichier), la Passerelle vérifie à nouveau le sac à dos. Elle demande : « Avez-vous la permission de faire cela ? Avez-vous assez de budget restant ? Les données que vous essayez de lire sont-elles autorisées ? » Si la réponse est non, l'action est immédiatement bloquée.
3. Le Nettoyage (Contrôleur d'Incidents) : Et si un robot est piraté ou devient incontrôlable ? Le système peut « révoquer » le sac à dos. Si le Patron dit : « Arrêtez l'Agent B ! », le système ne se contente pas d'arrêter l'Agent B ; il remonte l'historique du sac à dos. Il trouve chaque robot auquel l'Agent B a donné une tâche et les arrête aussi. Il met également en quarantaine toutes les données que ces robots ont touchées, s'assurant que « l'infection » ne se propage pas.

Ce que l'Auteur a Découvert (et ce qu'il n'a pas découvert)

L'auteur a construit un prototype de ce système et l'a testé rigoureusement. Voici ce qu'il a découvert :

• Les Mathématiques fonctionnent : Il a prouvé que si vous utilisez ces contrats, les règles ne peuvent pas être accidentellement abandonnées. Si un budget est fixé à 500 $, il reste à 500 $ (ou moins) quel que que soit le nombre de fois où la tâche est transmise. Il a constaté que sans ce système, les règles disparaissent souvent après seulement quelques transferts.
• Le Bug d'« Omission » : Lors de ses tests, il a découvert un bug sournois. Il s'est rendu compte que si un robot parent oubliait de noter une limite spécifique (comme un montant budgétaire), le robot enfant pourrait penser qu'il avait un budget illimité. Il a corrigé cela en créant une nouvelle règle : si une limite est manquante, le système doit supposer la limite la plus stricte possible (comme 0 $) pour être en sécurité. C'est une grande leçon pour la construction d'une IA sûre.
• Le Problème de la « Signification » : Le système est parfait pour vérifier les chiffres, les dates et les règles claires. Mais il n'est pas parfait pour comprendre les nuances du langage humain. Par exemple, si une règle dit « Soyez poli », le système ne peut pas prouver mathématiquement si un robot a été poli ou non. L'auteur admet que pour ces règles « basées sur le sens », son système n'est qu'un moniteur de type « meilleur effort », et non une garantie parfaite. Il est honnête à ce sujet : il peut prouver que les mathématiques fonctionnent, mais il ne peut pas encore prouver que la « politesse » fonctionne.
• Les Tests : Il a mené une étude pilote pour voir si un juge automatisé pouvait détecter ces erreurs. Cependant, le juge n'a pas encore passé leur test strict d'accord. Par conséquent, ils ne prétendent pas avoir résolu le problème de la « politesse » pour l'instant ; ils montrent simplement que leur système peut suivre ces problèmes et que des tests supplémentaires sont nécessaires.

Pourquoi cela importe

Ce document est un pont entre deux mondes : le vieux monde de la sécurité informatique stricte (où les règles sont dures et incassables) et le nouveau monde des équipes d'IA flexibles (où les robots communiquent en langage naturel).

L'auteur démonte que nous ne pouvons pas simplement laisser les robots d'IA se parler librement si nous voulons qu'ils soient sûrs. Nous devons leur donner un « contrat » qui voyage avec la tâche. Cela garantit que même si les robots sont bavards et créatifs, ils ne peuvent pas briser les règles que nous fixons pour eux.

Bien que le système ne soit pas encore parfait (particulièrement pour comprendre les significations humaines complexes), il constitue une base solide. Il prouve que nous pouvons construire des équipes d'IA qui sont puissantes mais aussi sûres, en protégeant notre argent et nos secrets, en traitant chaque transfert comme un contrat sérieux et vérifié plutôt que comme un simple murmure dans l'obscurité.