Résumé

  • La présentation de HPE à l’APNIC 62 cite load_and_commit_config parmi les outils Junos MCP capables de valider une configuration; cela décrit une possibilité technique, pas un usage en production.
  • Le compte rendu d’APNIC du 30 septembre indique qu’une démonstration de reconfiguration restait supervisée par un humain et que l’autonomie complète était un objectif futur. Il ne dit pas que l’outil Junos cité a servi à cette démonstration.

Une fonction d’écriture dans la liste des outils

À l’APNIC 62, la présentation de HPE Networking sur l’IA dans les opérations réseau montrait un serveur Junos MCP entre un agent d’IA et des équipements réseau. La liste mêlait observation et action : get_junos_config et junos_config_diff côtoyaient execute_junos_cmd, render_and_apply_j2_template et load_and_commit_config. La présentation indique que le serveur peut exécuter des commandes Junos et valider une configuration.

Cette liste délimite deux opérations différentes. Lire une configuration ou comparer un changement proposé n’équivaut pas à le charger puis à le valider. Un agent relié à un outil d’écriture dispose d’un chemin possible entre un plan généré et une modification d’équipement. La diapositive ne précise ni les identifiants utilisés, ni les cibles, ni les contrôles d’approbation configurés pour la démonstration.

Le compte rendu maintient un contrôle humain distinct

Le compte rendu d’APNIC indique qu’Akhilesh Thakur a présenté une implémentation Junos MCP. Plus loin, il décrit une démonstration de reconfiguration réseau par IA agentique sous supervision humaine, tandis que l’exploitation entièrement autonome reste un objectif futur. APNIC dit que les déploiements actuels conservent une intervention humaine dans la boucle.

Le texte ne relie pas explicitement la fonction load_and_commit_config à cette démonstration de reconfiguration. Cette lacune compte : un catalogue décrit les opérations exposées, mais ne dit pas quel outil l’agent a appelé, si une personne a approuvé le changement ou si un réseau de production était concerné. Les sources ne permettent d’affirmer ni qu’un réseau Junos a été modifié de façon autonome, ni que la fonction de validation était inutilisable.

Les garde-fous restent un programme de conception

La diapositive sur les risques cite les actions erronées dues aux hallucinations, le rayon d’impact des changements, l’exposition des identifiants, la dérive des modèles et les journaux incomplets. Elle propose notamment des validations confirmées, un seuil de confiance de 85 %, des faits issus des outils, une limite d’impact au niveau MCP, un déploiement progressif, une validation par jumeau numérique, des comptes à portée limitée et des journaux append-only. Ce sont des mesures proposées dans la présentation, pas des contrôles dont l’application dans le système montré aurait été vérifiée.

Le dépôt public Junos MCP de Juniper avertit lui aussi que le serveur autorise des changements de configuration. Il demande de relire la configuration générée par un LLM avant de la charger et de la valider, et de sécuriser le serveur avant tout déploiement en production. L’interface peut donc offrir une capacité d’écriture; chaque opérateur doit encore déterminer l’autorité qui lui est accordée.

Le compte rendu d’APNIC rapporte aussi des questions sur la prudence face à l’automatisation, le coût cumulé du contrôle humain et des jetons d’IA, les méthodes de test et les modèles open source. La supervision est à la fois un coût d’exploitation et une limite de sécurité.

Analyse

The important distinction is between a tool’s available operations and the authority granted to a running agent. A commit-capable interface can sit behind a strict approval process, or it can inherit broad credentials; the slides and APNIC’s report do not say which arrangement governed the Junos demonstration. The event record therefore supports a question about the control boundary, not a claim that an autonomous network was operating.

Sources