Le choix de votre framework d’orchestration est une décision de sécurité, pas seulement une décision d’ingénierie.

J’ai construit un harnais d’évaluation qui exécute le même ensemble de charges utiles contradictoires – détournement d’appels d’outils, injection multi-outils, empoisonnement de la mémoire, abus d’autorité déléguée et plusieurs autres classes d’attaques – contre les agents d’IA. La méthodologie complète et l’ensemble de données sont open source sur GitHub si vous souhaitez approfondir les détails. Pour isoler ce qui détermine réellement le taux de compromission, j’ai maintenu le modèle constant. Le même modèle, à chaque fois. La seule chose qui a changé était le framework d’orchestration qui l’encapsulait : CrewAI, LangChain, AutoGen et SmolAgents.

Si les cadres n’étaient qu’un câblage interchangeable autour du même modèle sous-jacent, les taux de compromission dans les quatre devraient se situer à peu près dans la même fourchette. Ils ne l’ont pas fait.

Sur des milliers de tests contradictoires, en maintenant le modèle constant, le taux de compromission variait de 11,9 % sur le cadre le plus résistant à 31,1 % sur le moins, soit un écart de 2,6x, à partir du seul choix du cadre. Rien dans le modèle n’a changé entre ces chiffres. Rien n’a changé dans les attaques. La seule variable était le framework qui orchestrait les appels d’outils, la mémoire et le raisonnement en plusieurs étapes de l’agent.

Ce n’est pas une différence d’arrondi. C’est l’écart entre une posture de sécurité que votre équipe pourrait raisonnablement accepter et celle qui devrait déclencher une conversation sérieuse avant l’expédition.

La figure 1 montre le mécanisme dans sa forme la plus simple : le même modèle, divisé en un cadre plus strict et un cadre plus souple, aboutit à un taux de compromis significativement différent – ​​exactement ce que confirment ces chiffres.

Les frameworks d’orchestration ne sont pas une plomberie neutre. Chacun prend de véritables décisions architecturales sur la manière dont les appels d’outils sont validés, la quantité de contexte partagé entre les étapes de raisonnement, la manière dont la mémoire persiste au cours d’une tâche et le degré d’autonomie dont dispose l’agent pour enchaîner les actions sans revenir en arrière. Ces décisions sont prises par la conception du framework, et non par le modèle sous-jacent, et elles façonnent directement la marge de manœuvre dont dispose un attaquant.

Un framework qui valide plus strictement les appels d’outils, ou qui segmente la mémoire de manière plus conservatrice, ferme les chemins d’attaque qu’un framework plus permissif laisse grands ouverts, quel que soit le modèle qui effectue le raisonnement. Le modèle génère les décisions. Le cadre contrôle le degré d’autonomie dont dispose l’agent pour agir sur ces décisions et où se situent les contrôles en cours de route.

Concrètement : un framework qui exige que chaque appel d’outil passe par une vérification de schéma explicite avant son exécution donne à un attaquant beaucoup moins de marge pour faire passer un paramètre malveillant qu’un framework qui permet au modèle d’appeler un outil directement à partir de son propre texte généré. Ce choix de conception unique, fait par les auteurs du framework bien avant que votre équipe n’y touche, est le genre de chose qui produit une différence de résultat de 2,6 fois sans qu’une seule ligne de votre propre code ne soit modifiée.

Chaque comparaison de framework que j’ai trouvée traite la sécurité comme un point parmi tant d’autres. Les guides de sites comme Bestarion, Atlan, Moxo, Cordum et Instinctools comparent LangChain, CrewAI et AutoGen sur la maturité de l’écosystème, la gestion de la mémoire et la prise en charge de l’homme dans la boucle – un terrain utile, mais aucun d’entre eux n’exécute un véritable test contradictoire et ne signale une différence mesurée de réussite d’attaque. Cela ne fait pas partie de la conversation publique de comparaison, et les équipes qui recherchent aujourd’hui « quel cadre devrions-nous utiliser » ne trouveront pas ce point de données dans les guides qui se classent actuellement en tête de cette recherche.

Si votre équipe choisit entre des frameworks d’orchestration pour un nouveau système agent, la question de sécurité mérite le même poids que la question de l’expérience du développeur, et non une réflexion après coup une fois le choix fait. Quelques choses à faire avant de vous engager :

• Traitez les allégations de sécurité concernant un framework avec le même scepticisme que vous appliqueriez au marketing d’un fournisseur. La documentation des fonctionnalités vous indique ce qu’un framework prétend faire. Il ne vous dit pas spécifiquement comment il résiste au détournement d’appels d’outils ou à l’empoisonnement de la mémoire – cela ne vient que de l’exécution de tests contradictoires contre lui vous-même ou de la recherche de quelqu’un qui l’a fait.
• Ne présumez pas que la formation en sécurité de votre modèle se transmet de manière uniforme. Un modèle bien aligné, enveloppé dans un cadre qui donne à un attaquant plus de marge de manœuvre, peut néanmoins aboutir à un taux de compromission réel bien pire que le même modèle dans un cadre plus strict.
• Si vous êtes déjà déployé, testez ce que vous avez, et non ce vers quoi vous envisagez de migrer. Il est possible de moderniser la sécurité une fois le choix du cadre effectué, mais savoir où se situe votre configuration spécifique sur ce spectre vous indique l’urgence de ce travail.

Les conversations sur la sécurité des agents IA ont tendance à se concentrer fortement sur le modèle : lequel est le plus sûr, lequel refuse le plus de tentatives de jailbreak. C’est une image incomplète. La couche d’orchestration située au-dessus du modèle effectue un véritable travail de sécurité, que quelqu’un l’ait conçue de cette façon ou non, et les guides de comparaison publics que j’ai trouvés ne fournissent aux équipes aucune donnée sur la façon dont cette couche se comporte en cas d’attaque.

Le modèle ne représente pas la totalité de la surface d’attaque. De plus en plus, ce n’est même plus la partie la plus variable. Si votre équipe est actuellement à mi-chemin d’une décision sur un framework, ou si elle en a déjà livré un sans jamais le tester de cette façon, c’est la conversation qui vaut la peine d’avoir cette semaine, pas après que le prochain incident le rende inévitable.