Découverte sécurisée d’outils pour les agents d’IA d’entreprise : registre, passerelle et politiques.

La question derrière les outils pour agents

Donnez à un agent quelques API, laissez le modèle choisir laquelle appeler, et l’accès aux outils semble être un problème résolu. Une entreprise change la donne : le catalogue contient alors des centaines ou des milliers d’outils. Certains ne sont que des recherches lues sans risque, d’autres peuvent modifier des données clients ou des informations personnelles, et un petit groupe peut encore lancer des transactions financières, réconfigurer des comptes ou effectuer des opérations administratives. « Comment l’agent trouve-t-il l’outil approprié ? » est la question facile. La plus difficile est de garantir que l’agent ne voie et n’utilise que les outils auxquels il a droit pour cette demande d’utilisateur en particulier.

C’est ce qui est exploré ici dans le cadre d’une étude de conception. Il s’agit d’une architecture raisonnée pour un environnement de services financiers et ne doit pas être interprété comme un rapport sur un système de paiement déployé.

Éloigner le modèle de la zone de sécurité

La production d’IA enseigne une leçon importante : le processus essentiel à l’activité ne réside pas à l’intérieur du modèle. Un modèle peut prédire, recommander ou classifier, tandis que la sécurité, la validation, les règles métier, l’autorisation et le traitement des transactions relèvent d’un logiciel déterministe extérieur à lui. Les agents rendent ces règles plus strictes, et non plus souples, car ils peuvent prendre des actions. Un LLM peut être un excellent raisonneur, mais il reste un mauvais choix pour définir les limites de sécurité d’un système d’entreprise.

Un scénario financier simple illustre pourquoi. Un client demande à l’agent d’examiner une transaction récente et de déterminer si un remboursement a été effectué. L’agent doit comprendre la demande et utiliser des outils de recherche de clients et de transactions, ce qui est une tâche courante.

Modifions maintenant la demande : si le remboursement n’a pas encore été traité, procédez-y. L’agent ne se contente plus de récupérer des informations, car cela peut avoir des conséquences financières. Ce petit changement met en avant le principe sur lequel tout repose :

L’agent peut réfléchir à une action et la suggérer. C’est la plateforme déterministe qui décide si cette action est effectivement mise en œuvre.

La séparation entre la réflexion et l’exécution permet à un système d’utiliser les forces des LLM sans avoir recours à eux pour des tâches qu’ils ne peuvent pas accomplir de manière fiable.

Un registre d’outils plutôt qu’une liste gigantesque

Comment l’agent doit-il apprendre quels outils existent ? Une option consiste à fournir au modèle une liste très longue de définitions d’outils et à le laisser déterminer leur pertinence. Cela peut suffire pour un prototype, mais échoue à l’échelle d’une entreprise. Des milliers de descriptions entraînent des coûts en termes de contexte et de latence, et une découverte non restreinte augmente les risques de sécurité sans aucun avantage.

Une solution plus adaptée est un Registre d’outils, un catalogue d’entreprise des capacités disponibles. Il contient bien plus que des noms d’API et des schémas. Chaque entrée comprend des métadonnées que la plateforme peut utiliser pour la découverte, la gouvernance et la prise de décisions stratégiques :

• domaine d’activité, responsable et version
• le fait que l’outil soit en lecture seule ou capable d’écrire
• classification des risques et capacités requises
• classification des données
• schémas d’entrée et de sortie
• caractéristiques d’idempotence
• exigences en matière d’audit

Les métadonnées sont particulièrement importantes pour distinguer les différents types d’opérations. Une recherche de transaction est une lecture à faible risque, un remboursement est une écriture financière à fort impact, tandis qu’une opération administrative peut présenter encore plus de risques. Ces distinctions ne peuvent pas rester uniquement dans la documentation ; elles doivent exister au sein de la plateforme afin que l’infrastructure déterministe puisse y agir.

La découverte n’est pas une autorisation

Ce pourrait être la distinction la plus utile dans tout le design : découvrir un outil et être autorisé à l’utiliser sont deux choses différentes.

La découverte permet de déterminer quels outils doivent être mis à disposition de cet agent pour cette tâche. L’autorisation répond à la question de savoir si cette requête spécifique est autorisée en ce moment même.

Les métadonnées du registre alimentent donc une étape de filtrage qui a lieu avant même que le LLM n’évalue ses options. D’abord, la plateforme détermine qui est l’utilisateur, quel agent agit, quel est le locataire, quel est le contexte environnant et quel est l’objectif de la demande. Ensuite, elle établit une liste restreinte d’outils correspondant à cette intention, puis affine cette liste en fonction des capacités de l’agent, des permissions de l’utilisateur, des limites du locataire, de la région et des politiques de risque. Le modèle ne voit que ce qui reste.

Ce filtre ne peut pas pour autant constituer la dernière ligne de défense. Le modèle pourrait émettre une requête inattendue, interpréter mal l’intention de l’utilisateur ou être influencé par une injection de prompt. Ainsi, chaque appel passe par un Tool Gateway contrôlé avant d’atteindre l’API d’entreprise sous-jacente.

En principe, le gateway évalue ensemble un ensemble de faits (qui est l’utilisateur, quel agent effectue l’appel, quelle demande est formulée, sur quel ressource, avec quels paramètres, dans quel contexte) et applique la politique de correspondance correspondante.

Autoriser l’intention, et non seulement l’outil

L’exemple du remboursement met en évidence un autre point : l’autorisation ne peut pas dépendre uniquement de l’outil utilisé. Elle doit également prendre en compte l’intention ainsi que l’action qui en résulte.

Vérifier l’état d’un remboursement et lancer un remboursement ne correspondent pas à la même fonctionnalité : l’une est une opération de lecture tandis que l’autre a un effet financier. La plateforme doit les modéliser explicitement. Une demande classée comme une demande d’information sur l’état du remboursement peut être transmise aux outils de recherche des clients et des transactions, mais cette classification ne confère pas automatiquement l’autorisation d’exécuter l’opération de remboursement. Même si le modèle décide à tort qu’un remboursement doit être accordé, la couche d’autorisation peut comparer l’action réellement demandée à l’intention autorisée et la rejeter.

Ici, la réflexion en matière de sécurité passe de la question de savoir si un agent a accès à l’API de remboursement à celle de savoir si cet utilisateur, cet agent, cette intention, cette ressource et cette action sont autorisés dans ce contexte.

Lorsque la moitié d’un flux de travail échoue

Lorsqu’une action est autorisée, un second problème apparaît : que se passe-t-il si une partie d’un flux de travail réussit tandis qu’une autre échoue ? Supposons que le remboursement soit effectué avec succès mais que l’e-mail de confirmation ne le soit pas. Redémarrer l’ensemble du flux de travail de l’agent pourrait entraîner l’exécution du remboursement deux fois.

Un modèle plus sûr fait du effet secondaire une étape au sein d’un flux de travail durable. L’autorisation valide le remboursement, l’API de remboursement est exécutée, et le résultat positif est enregistré. Cet résultat enregistré génère un événement RefundCompleted qui déclenche les notifications. En cas d’échec de l’e-mail, cela provoque une tentative de relance uniquement pour les notifications, sans que l’opération financière ne soit répétée.

La présence d’un LLM dans le système ne remplace pas l’ensemble d’outils classiques des entreprises. Les tentatives répétées et la déduplication, les disjoncteurs électriques et les actions compensatoires, les opérations idempotentes, l’état durable ainsi que le traitement basé sur des événements restent tous pertinents. Les agents peuvent contribuer à décider de ce qui doit se produire, tandis que l’infrastructure déterministe gère les changements d’état critiques.

Les approbations relèvent des politiques

Le LLM ne devrait pas non plus décider quand un humain doit approuver quelque chose. C’est une question de politique interne. Une organisation peut autoriser les remboursements inférieurs à un certain seuil à se faire automatiquement et exiger une approbation pour ceux qui dépassent ce seuil, exiger toujours une approbation pour les opérations administratives, et ajouter des contrôles pour les transactions destinées à des lieux inhabituels ou présentant un risque élevé. Le modèle peut indiquer qu’une action pourrait être nécessaire. Le système de politique décide s’une approbation est requise, et le Tool Gateway met en œuvre cette décision. La gouvernance en bénéficie également, car les règles sont explicites, révisables, versionnées et auditable, et ne sont pas cachées à l’intérieur d’un prompt.

Plan de contrôle et plan d’exécution

Après avoir examiné ces scénarios, cette conception ressemble beaucoup moins à un simple pipeline Utilisateur → LLM → Outils et ressemble beaucoup plus à une plateforme de gouvernance d’entreprise. Elle se divise naturellement en deux domaines.

Le plan de contrôle est l’endroit où l’organisation définit ses règles. Il comprend le catalogue des agents, le registre des outils, les définitions de capacités, les classes de risque, les politiques d’autorisation et d’approbation, ainsi que les paramètres de gouvernance généraux.

Le plan d’exécution est ce qui fonctionne en temps réel. Il contient les passerelles pour les API et les agents, les agents eux-mêmes, les résultats de découverte déjà filtrés, l’application des politiques, l’échange de identifiants, les outils qui sont exécutés, l’état du flux de travail et le flux des événements d’audit. Les règles peuvent être gérées de manière centralisée, tandis que leur application a lieu plus près de l’endroit où les charges de travail sont exécutées.

Cette séparation est cruciale à grande échelle. Avec des centaines ou des milliers d’agents et un grand nombre d’outils, personne ne souhaite que chaque vérification d’autorisation attende un service central unique. Les politiques sont gérées en un seul endroit, tandis que les points d’application sont distribués et les données des politiques sont mémorisées en cache ou répliquées selon les besoins.

Évaluation des actions, pas seulement des réponses

La conception s’intègre parfaitement aux systèmes d’IA d’entreprise tout en ajoutant une nouvelle catégorie de problèmes. L’IA traditionnelle se concentre sur la précision, la qualité des données, le dérive, la latence, la sécurité, le suivi et la fiabilité opérationnelle. Les agents conservent tous ces aspects tout en ajoutant l’évaluation des actions.

Une réponse finale correcte ne suffit pas. Les évaluateurs doivent également savoir si l’agent a choisi l’outil adéquat et transmis les paramètres appropriés, s’est tenu dans les limites autorisées, a évité les actions pour lesquelles il n’avait pas le droit d’agir, a suivi le flux de travail prévu, a demandé l’approbation d’un humain lorsque c’était nécessaire, et a engendré les effets secondaires attendus. L’évaluation passe alors de l’évaluation des réponses à l’évaluation des actions.

Le principe fondamental

Une règle revient constamment : traiter le LLM comme un composant de prise de décision peu fiable et jamais comme la barrière de sécurité. L’agent peut raisonner, découvrir des capacités pertinentes et proposer des actions. L’infrastructure d’entreprise déterministe décide de ce que l’agent peut faire, quels ressources il peut utiliser, quels paramètres sont acceptables, s’une approbation humaine est requise, comment les effets secondaires peuvent être gérés en toute sécurité, et comment l’ensemble du processus est audité.

C’est là le véritable défi architectural de l’IA agente. Faire en sorte qu’un agent soit suffisamment intelligent pour utiliser un outil est la partie facile. Créer une plateforme sur laquelle des milliers d’agents interviennent pour des millions d’utilisateurs, tout en maintenant sous contrôle l’identité, l’autorisation, les règles métier et la fiabilité opérationnelle, c’est là la partie difficile.