Donner à un assistant IA l'accès à Proxmox : où la frontière doit se situer

Il y a ici une asymétrie réelle et un peu agaçante. Lire deux mille lignes de journal et trouver la ligne où quelque chose a cassé est exactement ce qu'un modèle de langage sait bien faire. C'est aussi exactement le travail que la plupart des gens ne peuvent pas lui confier, à cause de la manière dont l'accès est accordé.

La question n'est pas de savoir si un modèle doit toucher un serveur. C'est où se situe la frontière, et aujourd'hui elle se situe le plus souvent au mauvais endroit.

Pourquoi le montage habituel met mal à l'aise

Il y a deux façons courantes de relier un assistant à Proxmox : lui donner une session SSH, ou un jeton d'API pleinement privilégié. Les deux reviennent au même. À partir de cet instant, plus rien ne se tient entre le modèle et le matériel, et toutes les protections vivent dans la formulation d'une consigne.

Une consigne n'est pas une frontière. C'est une demande adressée à un système conçu pour être serviable, dans une langue dépourvue de force exécutoire.

Le risque est le contexte manquant, pas la mauvaise intention

C'est la partie que l'on diagnostique mal. Le mode de défaillance est rarement un modèle qui décide de nuire. C'est un modèle qui agit correctement sur une image incomplète.

Un disque qui a l'air vide. Le modèle lit un périphérique sans système de fichiers monté et le considère comme libre. Le périphérique appartient à une machine simplement éteinte.

Un pool dégradé. Le modèle lit l'état dégradé et propose de reconstruire la grappe. La bonne étape était de remplacer un disque, et la reconstruction est la façon dont les données restantes se perdent.

Un service « qui ne tourne pas ». Il ne tourne pas parce qu'il tourne sur planning et qu'il a fini. Le redémarrer est inoffensif ; le désactiver parce qu'il « s'arrête tout le temps » ne l'est pas.

Dans les trois cas la commande est correctement écrite. C'est la prémisse qui est fausse, et une commande correcte sur une prémisse fausse est indiscernable d'un sabotage une fois le mal fait.

La lecture seule aide, et n'est pas toute la réponse

La réponse évidente est d'accorder un accès en lecture seule, et cela supprime réellement les pires issues. Deux choses subsistent.

Lire n'est pas gratuit. Configuration, journaux et enregistrements d'audit contiennent des noms d'hôtes, des adresses, des noms d'utilisateurs et parfois des jetons collés là où ils n'auraient pas dû l'être. Un assistant en lecture seule avec une portée de lecture complète est un export de votre infrastructure.

Un diagnostic sans action s'arrête à mi-chemin. Si la réponse utile est « redémarre ce service précis », un montage en lecture seule renvoie le constat à un humain pour qu'il le retape. C'est acceptable, et c'est aussi pourquoi les permissions s'élargissent discrètement plus tard.

La lecture seule est donc un bon point de départ et une mauvaise destination. La destination, c'est un accès en écriture étroit, passant par les mêmes portes qu'un humain.

Où la frontière a réellement sa place

Ni dans la consigne, ni dans le modèle. Dans la couche qui exécute, car c'est le seul endroit capable de refuser.

Trois propriétés rendent une telle couche digne de confiance, et les trois sont vérifiables plutôt que promises.

Les permissions viennent du système qui les détient déjà. Si l'assistant se connecte avec un compte existant, ce que ce compte peut toucher est exactement ce que l'assistant peut toucher. Aucun second modèle de permissions n'est inventé, donc rien à garder synchronisé et aucun moyen que les deux se contredisent.

Les opérations destructrices passent la même porte qu'un humain. Si supprimer un disque demande confirmation à une personne, cela doit aussi le faire quand un modèle le demande. Un chemin sûr pour les humains et ouvert pour l'automatisation n'est pas une frontière, c'est un raccourci avec un joli nom.

Chaque étape atterrit dans le journal d'audit. Qui, quoi, quand, sur quoi et avec quel résultat. Sans cela, la vraie question après un incident, « est-ce l'assistant qui a fait ça », n'a pas de réponse, et l'absence de réponse est en soi une raison de ne pas accorder l'accès.

La question à poser sur un tel outil

Non pas « est-ce sûr » mais « qu'est-ce qui refuse, et où cela vit-il ? »

Si la réponse est « on a dit au modèle de ne pas le faire », il n'y a pas de frontière. Si la réponse est « la couche d'exécution vérifie les permissions du compte et fait passer les étapes destructrices par une porte », il y en a une, et vous pouvez la tester : connectez-vous avec un compte restreint et vérifiez que le refus est réel.

Ce que fait Atlas

⚠️ Cette couche est prévue, pas livrée. Ce qui suit est la conception vers laquelle elle est construite, écrit ici parce que la question ci-dessus mérite une réponse honnête et non commerciale.

L'intention est que l'assistant se branche sur Atlas et non sur Proxmox. Proxmox se trouve dessous et le modèle ne l'atteint jamais directement ; il ne peut utiliser que ce qu'Atlas sait faire, ce qui laisse chaque porte existante sur le chemin.

La frontière est tracée par les permissions Proxmox, c'est-à-dire la première propriété ci-dessus : ce que le compte connecté peut toucher est tout ce que l'assistant touche, et aucun nouveau concept de permission n'apparaît. Les opérations destructrices gardent la confirmation qu'elles ont déjà, et le journal d'audit enregistre déjà qui, quoi, quand, sur quoi et avec quel résultat pour chaque action privilégiée, refus compris.

Elle est également pensée comme un composant séparé plutôt que comme une partie de l'installation : sur une machine qui n'en veut pas, elle n'est jamais présente. Cela compte pour la même raison que tout le reste de cet article. La frontière la plus sûre pour une capacité que vous n'avez pas choisie, c'est son absence.