Les agents IA peuvent hériter des droits d’administrateur local

Même jeton, mêmes droits

Windows n’a pas de niveau de permission distinct pour le « AI process ». Un agent, qu’il s’agisse d’une extension de navigateur, d’une application de bureau ou d’un service en arrière-plan, démarre comme un processus enfant de celui qui l’a lancé et hérite du jeton d’accès du parent. Connectez-vous en tant qu’utilisateur standard, lancez l’agent, et il fonctionne en tant qu’utilisateur standard. Connectez-vous avec un compte disposant de local admin rights, et l’agent fonctionne également avec ces droits, ainsi que tout ce qu’il génère pour accomplir son travail : un appel PowerShell, un binaire d’aide, un runtime local qu’il installe pour pouvoir fonctionner en dehors du sandbox du navigateur.

Les jetons de processus fonctionnent ainsi depuis des décennies. La nouveauté réside dans ce que font les agents avec le jeton qu’ils héritent. Les applications privilégiées traditionnelles exécutent des chemins de code fixes approuvés par les fournisseurs ; les agents sont différents. Ils lisent et écrivent des fichiers locaux, lancent des commandes en ligne de commande, appellent les API du système d’exploitation pour interagir avec d’autres applications et, dans un nombre croissant de cas, installent un composant local lors du premier lancement. Chacune de ces actions s’exécute avec le niveau de privilège que le compte possédait déjà.

Sur un compte avec des droits d’administrateur local, cette empreinte atteint HKEY_LOCAL_MACHINE, le Service Control Manager, les tâches planifiées s’exécutant sous SYSTEM, la mémoire du processus LSASS où se trouvent les informations d’identification, l’installation des pilotes et les ACL protégeant Program Files et System32. Y accéder ne nécessite pas que l’agent fasse quelque chose d’inhabituel. Le compte a déjà la porte ouverte. L’agent passe simplement comme n’importe quel autre processus.

Ce n'est pas le même profil de risque qu'une application privilégiée normale

Les équipes informatiques savent comment gérer le risque lié aux logiciels privilégiés qui exécutent un ensemble fixe de chemins de code écrits par le fournisseur. Les agents brisent ce modèle car le chemin de code n’est pas fixe. Le prochain mouvement d’un agent est souvent décidé à l’exécution, en fonction d’une invite, d’un document qu’il résume, d’une page web qu’il consulte, d’un fil de courriel auquel il rédige une réponse. Si ce contenu contient un langage que le modèle sous-jacent interprète comme une instruction, et que l’agent a accès à l’utilisation d’outils sur le système d’exploitation, le modèle peut agir en conséquence.

C’est une injection de prompt : du texte intégré dans un contenu apparemment ordinaire, traité comme une commande plutôt que comme des données. Exécutez l’agent avec un jeton utilisateur standard et le rayon d’action de l’instruction injectée reste limité à ce qu’un utilisateur standard pourrait déjà faire. Exécutez-le avec les droits d’administrateur local et l’instruction hérite des privilèges d’administrateur ; écrivez dans des clés de registre protégées, installez des tâches planifiées, accédez au réseau avec des identifiants mis en cache, désactivez l’agent antivirus. Chaque étape est maintenant élevée.

Il y a aussi un angle de visibilité, distinct du problème des permissions. Le marketing adopte un assistant d'écriture. L'ingénierie utilise un assistant de code. Les ventes installent un résumé de réunion. Chacun apparaît sur un endpoint différent, sous un compte différent, avec son propre rythme de mise à jour et sa propre posture de sécurité fournisseur, généralement sans aucune revue formelle de l'IT. Lire le code source de l'agent ne vous dirait pas grand-chose de toute façon, car ce qu'une instruction injectée peut faire dépend entièrement du compte sous lequel elle s'exécute, et non du code de l'agent lui-même.

Supprimer les droits d’administrateur local, aussi pour AI

Examiner chaque nouvel outil d’IA pour la posture de sécurité est une course que l’informatique ne peut pas gagner face à la rapidité d’adoption de ces outils. Couper l’héritage à la source fonctionne mieux : retirer les droits d’administrateur local permanents du compte, et il ne reste rien d’élevé qu’un agent ou toute autre chose s’exécutant sous ce compte puisse hériter.

Le problème est la friction dans le flux de travail. Certains de ces outils doivent vraiment écrire une fois dans un emplacement protégé, lors de l’installation. Retirer les droits d’administrateur sans possibilité d’élévation ciblée pour cette étape fait augmenter le volume des tickets de support au lieu de réduire le risque.

PolicyPak Least Privilege Manager gère cette séparation : le privilège par défaut du compte reste utilisateur standard, et des tâches spécifiques reçoivent des règles d’élévation. Définissez quel installateur, applet ou action peut s’exécuter avec élévation, pour quels utilisateurs et pendant combien de temps. Si un agent a besoin d’un admin pour une installation d’aide ponctuelle, limitez la règle à cet installateur. Tout le reste que ce compte fait ensuite, agent inclus, s’exécute en utilisateur standard. Une instruction injectée qui tente d’écrire dans HKLM ou d’installer un service rencontre le même obstacle qu’un utilisateur standard.

Least Privilege Manager couvre Windows et macOS. Il est important de noter cela compte tenu de l’adoption massive d’outils IA sur les flottes Mac, que la politique Windows seule manquerait complètement.