Microsoft décrit quatre niveaux de contrôle pour un agent IA qui modifie les paramètres réseau

Un agent IA peut déterminer la cause d’une panne de connexion réseau, puis proposer une correction touchant l’infrastructure en exploitation. Dans un article d’ingénierie publié le 13 octobre, Microsoft décrit une architecture en couches, où des règles logicielles distinctes limitent l’accès de l’agent et vérifient ses actions.

L’auteur de l’article, Arun Malik, ingénieur principal chez Azure Networking de Microsoft, examine un scénario de connexion instable dans un centre de données. L’agent recueille l’état des appareils et la télémétrie, met en regard les changements récents, classe la panne et prépare un résumé. Le système peut ensuite passer à la correction — par exemple, désactiver une session BGP sur un appareil acheminant le trafic des utilisateurs — au moyen des mécanismes de contrôle prévus par l’architecture.

Microsoft décrit quatre limites : l’identité, les outils, les modifications et le temps. L’agent agit dans le cadre des droits de la personne qui l’a appelé, accède aux systèmes par une interface contrôlée, s’arrête avant toute modification de l’état de production pour obtenir la confirmation d’un humain et, avec le temps, les procédures répétitives qui ont fait leurs preuves peuvent être formalisées en scénarios déterministes.

Les droits de l’agent suivent ceux de l’utilisateur

La première limite concerne les identifiants. Dans le modèle proposé, l’agent agit au nom de l’utilisateur et ne reçoit pas davantage d’autorisations que lui. Si un compte de service est nécessaire, ses droits doivent être encore plus restreints. Cela limite les conséquences d’une erreur ou d’un texte malveillant dans les journaux et les réponses des outils : le modèle ne peut pas obtenir des privilèges dont l’utilisateur ou le compte dédié ne dispose pas.

La deuxième limite concerne les outils. Chaque opération passe par une interface typée, fait l’objet d’une autorisation distincte, accepte des données d’entrée structurées et laisse une trace dans un journal. Malik précise que la restriction ne porte pas sur la ligne de commande elle-même, mais sur l’accès incontrôlé à l’interpréteur : une commande limitée peut être fournie comme outil contrôlé, tandis qu’un accès libre au shell complique la séparation des privilèges et l’audit.

La lecture et la modification obéissent à des règles différentes

Dans l’architecture décrite, le diagnostic peut être automatisé. Toute action qui modifie l’état d’un système en production est suspendue jusqu’à l’approbation d’une personne. Selon l’auteur, cette restriction doit être appliquée par le code de l’environnement d’exécution, et non par une simple consigne adressée au modèle. Le modèle peut analyser la sortie non structurée d’un appareil, mais la décision d’agir et la vérification des autorisations relèvent de la logique logicielle.

L’article donne l’exemple d’une interface réseau : le modèle convertit la sortie d’une commande en champs structurés, un validateur les compare au schéma et une condition déterministe choisit l’action suivante. Si une étape modifie la configuration, l’exécution attend une approbation. Le texte de la tâche est ainsi séparé des autorisations nécessaires pour modifier le réseau.

La quatrième limite concerne la répétabilité. Microsoft propose de formaliser les procédures de diagnostic vérifiées sous forme de scénarios déterministes, qui, dans les cas connus, peuvent être exécutés sans nouvel appel au modèle. Selon l’entreprise, cela réduit le coût des raisonnements répétés, améliore la reproductibilité et diminue la surface exposée aux erreurs et aux attaques. La publication ne fournit pas de résultats quantitatifs issus d’un déploiement industriel.

Points à vérifier lors du déploiement

L’article de Microsoft est une description technique d’une architecture et d’un scénario, et non une évaluation indépendante de la fiabilité d’un produit fini. Pour les équipes qui conçoivent leurs propres agents, la démarche pratique consiste à rattacher les actions à l’identité de l’utilisateur, à énumérer les opérations autorisées, à typer et journaliser les appels, à séparer la lecture de l’écriture et à exiger une confirmation explicite pour les modifications. Après vérification des conditions de déclenchement et du résultat, les cas répétitifs peuvent être convertis en procédures classiques.

La conclusion essentielle porte sur la séparation des rôles : le modèle aide à analyser un incident inédit et à produire une sortie structurée, tandis que le système d’exécution détermine quelles opérations sont autorisées et quand une confirmation est requise. C’est cette séparation que Microsoft propose pour passer des suggestions à l’opérateur à une automatisation limitée de l’infrastructure réseau.