Microsoft a publié le 4 septembre 2026 des recommandations pour sécuriser l’intelligence artificielle en périphérie (Edge AI), avertissant que le transfert de l’exécution des modèles vers des appareils, des passerelles ou des environnements locaux appartenant aux clients ne modifie pas seulement le lieu de traitement des données, mais redistribue également la responsabilité de la confiance et de la sécurité. Dans ce modèle, les poids des modèles, les données des clients, les identifiants et la capacité d’influencer des systèmes réels peuvent se trouver au sein d’une infrastructure que le fournisseur du modèle ne contrôle pas directement.
Microsoft définit l’Edge AI comme l’exécution de l’inférence sur l’appareil ou à proximité, là où les données sont produites et utilisées pour prendre des décisions, plutôt que de dépendre entièrement d’un service cloud centralisé. Les organisations peuvent choisir cette approche pour des raisons de coût, de choix du modèle, de souveraineté des données, de réduction de la latence ou de capacité à fonctionner en cas d’interruption de la connexion.
Qu’est-ce qui change dans le modèle de confiance ?
Dans les services d’intelligence artificielle cloud, la propriété du matériel et de la plateforme, les poids des modèles et l’attestation de leur état sont souvent répartis entre des fournisseurs capables de présenter des preuves uniformes concernant l’environnement. En revanche, dans l’Edge AI, le client gère une plus grande partie de la pile, ce qui signifie qu’il doit vérifier le matériel, le micrologiciel, l’environnement d’exécution, le modèle et les composants intégrés avant d’autoriser leur accès à des actifs sensibles.
Les risques augmentent également parce que l’environnement lui-même peut contenir le modèle, les données, les clés et les moyens d’accès à des systèmes physiques. Les vecteurs d’attaque potentiels comprennent l’injection de commandes, la manipulation du modèle, la modification du micrologiciel, l’empoisonnement des données de récupération, la configuration des outils et la chaîne d’approvisionnement du modèle. Dans les opérations Edge isolées du réseau, il n’est pas toujours possible de compter sur une détection cloud directe, sur des mises à jour immédiates des politiques ou sur une révocation centralisée des autorisations.
Quatre piliers de vérification avant la libération
- Attestation de l’environnement d’exécution : il faut s’assurer que l’environnement d’exécution est mesurable, capable de rendre compte de son état et conforme à une référence approuvée.
- Attestation de la provenance des composants : il convient de vérifier les poids du modèle, les définitions des outils, les définitions des agents, les index de récupération ainsi que leur processus de construction et de livraison.
- Médiation déterministe des actions : le modèle doit recommander l’action, et non accorder directement l’autorisation de l’exécuter. Une couche extérieure au modèle doit appliquer une liste d’autorisation, restreindre les paramètres, contrôler la répétition et libérer les identifiants conformément à une politique définie.
- Liaison des actifs sensibles à l’environnement de confiance : les clés, les données ou les poids des modèles ne doivent être remis qu’après collecte des éléments de preuve requis et réussite de la politique de vérification.
L’attestation seule ne suffit pas
Microsoft précise que l’attestation de l’environnement d’exécution et l’attestation de la provenance des composants répondent à deux questions différentes. Un environnement d’exécution acceptable peut charger un composant compromis, tandis qu’un composant fiable peut fonctionner sur une plateforme compromise. Il faut donc combiner les deux types de preuves et suivre la chaîne d’attestation depuis le processus de construction et de distribution jusqu’au matériel accepté par le vérificateur.
Le calcul confidentiel peut soutenir ce modèle lorsqu’il couvre l’ensemble du parcours conformément au modèle de menace déclaré de la plateforme. Un hôte privilégié ou un chemin d’accélérateur non protégé peut être capable de lire les poids, les clés ou les données après leur déchiffrement. Toutefois, la protection contre l’accès de l’hôte n’empêche pas le modèle d’exécuter une action nuisible via une interface autorisée ; c’est pourquoi la médiation et les politiques indépendantes restent indispensables.
La libération des actifs ne devrait pas non plus être considérée comme une décision permanente. Les recommandations proposent de la traiter comme une location renouvelable qui prend fin lorsque les preuves récentes ne correspondent plus à l’état approuvé. Ces preuves peuvent être utilisées pour contrôler la planification des charges, le stockage, l’identité et la disponibilité des identifiants.
Pourquoi les contrôles traditionnels de sécurité logicielle ne suffisent-ils pas ?
Les logiciels traditionnels fonctionnent selon du code livré par le développeur, tandis que le comportement des systèmes d’intelligence artificielle est influencé par les requêtes, les données de récupération, les instructions des agents et les entrées d’exécution. La simple signature des fichiers exécutables ou la vérification de l’intégrité du code ne suffit donc pas à protéger le système. Une signature peut prouver la provenance des données, mais elle ne prouve pas que leur contenu est sûr à interpréter pour un modèle d’intelligence artificielle.
Microsoft insiste sur le fait qu’il faut supposer que l’injection de commandes se produira, qu’elle soit directe ou indirecte, et que les sorties de l’agent ainsi que les entrées d’écran ne constituent pas en elles-mêmes une autorisation. En outre, le caractère non déterministe du comportement limite la fiabilité de la seule détection par signatures ou des tests traditionnels. Il faut donc établir des limites déterministes aux points d’autorité, en exigeant une approbation indépendante, un mécanisme de séparation ou un comportement sûr pour les actions lourdes de conséquences ou irréversibles.
Qu’est-ce que cela signifie pour les organisations ?
En pratique, l’organisation doit cartographier les actifs sensibles, les environnements d’exécution et les composants auxquels ils ont accès, ainsi que l’entité responsable de chaque décision de libération. Elle devrait également définir les preuves requises à chaque limite de confiance et faire apparaître les modifications locales sous la forme d’un écart dans les mesures, plutôt que de les adopter silencieusement comme une nouvelle référence.
Lecture éditoriale de certi.news : la valeur principale de ces recommandations est qu’elles déplacent la sécurité de l’Edge AI de la protection du modèle en tant que fichier vers la gestion de l’ensemble de la chaîne de confiance, du matériel jusqu’aux actions que le système peut exécuter. Elles ne garantissent toutefois pas que chaque action autorisée par la médiation soit sûre et n’éliminent pas la nécessité de contrôles physiques ni d’un examen indépendant des opérations à haut risque. La question ouverte pour chaque déploiement local reste donc la suivante : quelle preuve démontre que l’environnement, les composants et la politique actuels justifient la libération de l’actif sensible maintenant ?