Connecter un agent à AI Server : valider la boucle complète d'appel d'outil

AI Server fournit une API compatible OpenAI pour des applications sur une infrastructure contrôlée par l'organisation. Une intégration d'agent nécessite un test d'acceptation plus spécifique qu'une simple réponse de chat réussie : le modèle choisi doit proposer l'opération prévue, et l'application hôte doit gérer correctement cette proposition. Notre page produit AI Server décrit le rôle de déploiement ; la procédure suivante explique comment nous recommandons de vérifier une intégration individuelle.

La documentation du benchmark agentique edge de MLCommons de juillet 2026 illustre cette distinction. Ses exemples envoient des définitions d'outils à un endpoint Chat Completions et inspectent les appels structurés retournés par le modèle.[1] Le seul nom d'un endpoint ne garantit pas que chaque combinaison modèle, runtime et framework exécutera le même flux de travail.

Commencez par une requête qui ne peut pas modifier les données métier

Choisissez un espace de travail de test jetable et un modèle destiné à la tâche. Enregistrez la version du serveur, le runtime, l'identifiant du modèle et la version du framework agent. Incluez le endpoint effectif et les paramètres de transport, mais excluez les identifiants d'accès du rapport. L'enregistrement doit distinguer l'installation testée d'un modèle au nom similaire ou d'un serveur plus ancien encore en fonctionnement ailleurs.

Commencez par une requête textuelle ordinaire. Confirmez quel endpoint l'a reçue, quel modèle l'a traitée et si l'appelant a reçu une réponse complète. Répétez via le framework qui sera utilisé dans le pilote. Un succès HTTP direct et un succès via framework sont des observations distinctes ; conservez les deux résultats.

Utilisez une entrée courte avec une réponse prévisible afin que les échecs de connexion soient faciles à distinguer de la difficulté de la tâche. Un salut généré établit très peu sur un flux d'achat, mais c'est un premier contrôle utile de la route. N'ajoutez pas d'identifiants métier simplement pour rendre ce test initial plus réaliste.

Vérifiez une proposition d'outil inoffensive avant exécution

Définissez une opération de test étroite, comme rechercher un article dans un inventaire fictif. Donnez-lui un petit schéma avec des champs obligatoires et un ensemble explicite de valeurs autorisées. À ce stade, capturez l'opération proposée par le modèle sans l'exécuter. Vérifiez le nom de l'opération, les arguments analysés et le traitement par le framework des champs manquants ou inattendus.

Gardez le dispositif assez simple pour qu'une personne puisse inspecter chaque résultat. Un modèle qui retourne une prose plausible sur un article n'a pas nécessairement produit un appel d'outil utilisable. Inversement, un appel bien formé peut toujours nommer le mauvais article. Enregistrez séparément l'acceptation du format et la justesse de la tâche.

Si l'application de production diffuse les réponses en streaming, effectuez la même vérification en streaming. Vérifiez que le consommateur attend que la valeur structurée pertinente soit complète avant de l'interpréter. Considérez toute différence entre le traitement en streaming et hors streaming comme une anomalie d'intégration nécessitant une résolution, plutôt que de supposer que le chemin réussi couvre les deux.

Complétez le cycle avec un résultat contrôlé

Après que la proposition a passé la validation, autorisez l'hôte à appeler l'inventaire fictif et à retourner son résultat au modèle. Inspectez la réponse suivante. Elle doit utiliser le résultat fourni et préserver l'identité de l'article demandé. Incluez une recherche qui ne retourne aucune correspondance afin que l'application doive représenter honnêtement l'absence.

Ensuite, effectuez une courte séquence nécessitant une deuxième recherche. Vérifiez comment le framework associe chaque résultat à son appel d'origine et comment la requête suivante fait avancer la conversation. Enregistrez une trace assainie montrant la séquence sans conserver de documents clients réels.

C'est à ce stade qu'une démonstration à tour unique devient un test de flux de travail. La trace doit révéler une mauvaise association, une répétition inutile ou une tâche abandonnée. L'article de référence d'octobre explique pourquoi les limites de charge de travail sont importantes lors de l'évaluation de ces interactions plus longues.

Maintenez les vérifications d'autorisation en dehors du jugement du modèle

OWASP identifie une fonctionnalité excessive, des permissions et une autonomie excessives comme causes d'une agence excessive. Ses recommandations placent les contrôles d'autorisation dans les systèmes qui exécutent les actions et préconisent une approbation humaine pour les opérations à fort impact.[2] Pour cette intégration, testez ces contrôles indépendamment du fait que le modèle demande habituellement des actions sensées.

Étendez le jeu de données d'inventaire fabriqué avec une opération que l'appelant n'est pas autorisé à effectuer. Vérifiez que l'hôte ou le service en aval la refuse même lorsque les arguments proposés semblent valides. Le refus doit rester compréhensible pour l'utilisateur et ne doit pas amener le framework à substituer un identifiant plus privilégié.

Incluez un document de test récupéré contenant une instruction non pertinente. OWASP décrit l'injection indirecte de prompt via du contenu externe et note que la génération augmentée par récupération ne supprime pas totalement la vulnérabilité.[3] Le critère d'acceptation ici est concret : la prose récupérée ne doit pas accorder à l'application des permissions supplémentaires. Ce test est un contrôle utile, non une preuve que toute tentative d'injection sera bloquée.

Terminez par une interruption et une portée enregistrée

Interrompez l'outil de test, annulez une requête et rendez une dépendance temporairement indisponible. Observez ce que l'utilisateur voit et ce que le framework retente. Avant d'introduire un outil modifiant des enregistrements, convenez de la manière dont une nouvelle tentative évitera de dupliquer une action déjà réalisée. Cette décision appartient à la conception de l'application et au contrat du service en aval.

Notre enregistrement d'acceptation proposé liste les opérations exactes testées, les identités autorisées et tout comportement non résolu. Une recherche d'inventaire réussie ne doit autoriser que la portée pilote convenue. Un nouveau connecteur, une permission plus large ou un modèle différent doivent déclencher une révision des contrôles affectés.

Pour une discussion sur le déploiement, apportez cet enregistrement à une revue d'intégration Software Tailor, accompagnée d'un exemple échoué expurgé s'il en existe un. L'étape suivante utile est un écart reproductible avec un responsable. La passation opérationnelle doit préserver ces responsables après la fin des travaux d'intégration initiaux.

Références

[1] MLCommons. Appel à contributions : Edge Agentic Inference Benchmark pour MLPerf Inference v6.1. Juillet 2026. Consulté le 26-09-2026.

[2] Projet de sécurité OWASP Gen AI. LLM06:2025 Agence excessive. Édition 2025. Consulté le 26-09-2026.

[3] Projet de sécurité OWASP Gen AI. LLM01:2025 Injection de prompt. Édition 2025. Consulté le 26-09-2026.