Agent 365 et Azure API Management. Où le contrôle des outils des agents s’applique
L’intégration en préversion relie inventaire et contrôle des serveurs MCP. Comprendre les niveaux de passerelle et les limites d’un examen après l’action.
Microsoft relie Agent 365 à Azure API Management pour encadrer les outils utilisés par des agents d’IA. Le billet officiel du 9 octobre 2026 présente cette intégration en préversion publique. L’objectif consiste à réunir un inventaire central et des contrôles appliqués lors des appels. Certaines fonctions dépendent toutefois du niveau de passerelle choisi.
L’inventaire et le contrôle jouent deux rôles
Un agent peut atteindre des logiciels par un serveur MCP. Ce protocole expose des outils que l’agent peut appeler. Voir ces outils dans un catalogue ne suffit pourtant pas à empêcher un appel. L’intégration distingue donc l’endroit où l’organisation définit ses décisions de l’endroit où le trafic passe réellement.
Agent 365 rassemble les serveurs et les métadonnées accessibles. Azure API Management applique les décisions sur les appels qui traversent sa passerelle. Le guide de l’intégration explique que les agents peuvent conserver leur point d’accès existant lorsque celui-ci utilise déjà cette passerelle. La fonction ne force pas tous les agents à adopter le même moteur.
Un accord qui donne de vrais droits
La découverte demande un consentement au niveau de l’organisation. Il donne à l’identité de service Agent 365 des droits de lecture et d’écriture sur les politiques concernées. Le périmètre comprend les souscriptions Azure existantes et futures de cette organisation. Ça dépasse donc l’ajout d’une simple vue dans un tableau de bord.
Bloquer un serveur entier ou seulement un outil
Les niveaux v2 d’API Management prennent en charge l’inventaire central et le blocage d’un serveur MCP entier. Le niveau AI Gateway ajoute le contrôle d’outils individuels. Il apporte aussi le suivi de leur activité et la protection des appels. Les niveaux v1 ne sont pas pris en charge par cette intégration.
Le contrôle individuel peut servir à laisser un outil de consultation disponible tout en coupant un outil de suppression. Cet exemple illustre la portée du mécanisme. Il ne décrit pas un réglage effectué sur votre environnement. La distinction permet d’éviter qu’une seule fonction sensible impose de retirer tout un serveur.
Le guide demande une liste statique d’outils autorisés pour le contrôle depuis Agent 365. Une liste dynamique ne bénéficie pas du même fonctionnement. Autre limite essentielle, Agent 365 ne redirige pas automatiquement les agents vers la passerelle. Un appel direct qui la contourne sort de son chemin de contrôle. L’architecture de connexion reste donc déterminante.
Examiner la demande et le résultat
La protection des appels d’outils utilise des capacités de Microsoft Defender et Microsoft Purview. Elle examine les demandes ou les résultats pour repérer des risques. Microsoft cite notamment les contenus malveillants et les instructions piégées. La politique s’applique à un serveur MCP et à ses outils. Ce périmètre diffère du blocage individuel d’un outil.
Après l’appel ne signifie pas avant l’action
L’examen peut intervenir avant l’exécution ou après celle-ci. Il peut aussi intervenir aux deux étapes. Un contrôle avant l’appel peut empêcher l’outil de fonctionner. Un contrôle après l’appel peut retenir son résultat avant qu’il revienne à l’agent. Il ne peut pas annuler une action déjà réalisée.
Cette différence compte lorsqu’un outil modifie des données. Retenir sa réponse ne signifie pas que la modification a été empêchée. La documentation avertit aussi contre une nouvelle tentative automatique après une exécution dont le résultat a été retenu. Répéter l’appel peut répéter l’action alors que sa première réponse manque.
Une préversion avec des conditions précises
Le guide situe AI Gateway en préversion dans East US 2 et Sweden Central. La protection demande une licence Defender ou Purview et un jeton utilisateur Microsoft Entra ID délégué. Un appel utilisant seulement une identité d’application ne répond pas à cette condition. Il faut distinguer cette identité d’évaluation de celle qui administre les politiques.
Le mode choisi dans Defender compte également. Le mode d’audit observe sans bloquer. Le mode de blocage applique le refus. La présence d’une politique ne prouve donc pas que chaque appel risqué sera empêché. Les guides décrivent les conditions de configuration. Ils ne démontrent pas une disparition de tous les risques.
Comprendre où la supervision agit
Pour les équipes qui apprennent à utiliser les agents, l’intérêt est de rendre ces étapes visibles. Définir un droit et examiner un résultat ne produisent pas le même effet. Une formation peut partir de cette différence pour expliquer le chemin d’un appel. Ça permet de discuter de la responsabilité et des limites sans confondre supervision et protection absolue.
Pour travailler ces questions avec vos équipes, vous pouvez me contacter.
Retrouvez aussi les actions inattendues observées dans les évaluations de Claude. Elles éclairent la différence entre une réponse générée et une action sur un système réel.