Cela revient-il à confier le serveur à une IA ?

Non. Ce qui est fait se limite aux droits que cet utilisateur possède dans Proxmox ; l’IA ne possède aucun droit propre. Qui veut une portée étroite donne à l’IA un compte Proxmox étroitement défini. Chaque opération demande un rapport d’impact et une validation.

Pourquoi ajouter cela à un produit qui fonctionne hors ligne ?

Le composant ne fait pas partie de l’installation par défaut, seul celui qui le veut l’ajoute. L’ajout lui-même demande une connexion à ce moment ; le reste du produit n’en dépend pas. Une fois installé, avec un modèle local tournant sur le serveur, le produit reste hors ligne.

Quels modèles seront pris en charge ?

Il y a deux voies : l’assistant fourni par Atlas, ou un modèle à soi. Le protocole étant indépendant du modèle, tout client qui parle Model Context Protocol peut se connecter, y compris ceux qui tournent en local. Quelle que soit la voie choisie, les limites ne changent pas, car elles résident dans le serveur et non dans le modèle.

Que se passe-t-il si le modèle dit quelque chose de faux ?

Une réponse fausse reste au niveau de la proposition, puisque l’application est une étape distincte. Chaque réponse montre aussi l’enregistrement sur lequel elle s’appuie, une personne peut donc la vérifier.

Comment cela tient-il lors d’un audit interne exigeant ?

Le journal d’audit porte tout ce que le modèle a lu et chaque opération qu’il a demandée. Qui a validé figure au même endroit, la chaîne de décision se relit donc entièrement.

Quand sera-ce disponible ?

La conception est faite, la réalisation figure dans la feuille de route produit. Une fois prête, les utilisateurs qui le souhaitent l’ajouteront depuis le panneau en un bouton ; une installation qui n’en veut pas reste telle quelle.

Que l’IA pilote le serveur, sans le casser

Atlas peut ouvrir son propre serveur Model Context Protocol, pour qui le souhaite, et propose un champ de commande dans le panneau. C’est un composant distinct : il n’arrive pas avec l’installation, qui le veut l’ajoute depuis le panneau en un bouton, et sur une machine qui n’en veut pas il n’est pas présent du tout. Une fois ajouté, l’état du serveur est lu, une panne est déroulée et le travail se fait en écrivant ce que l’on veut. La limite est tracée par Proxmox : ce à quoi un utilisateur peut toucher, l’IA y touche autant, pas plus. Aucune nouvelle notion de droits n’apparaît. L’IA est branchée sur Atlas, pas sur Proxmox. Proxmox est en dessous, mais le modèle ne l’atteint jamais directement ; il n’utilise que ce qu’Atlas sait faire.

Ce que coûte aujourd’hui un accès serveur donné à un modèle

Il n’existe aujourd’hui qu’une façon de faire travailler un assistant IA avec Proxmox : lui remettre une session SSH ou un jeton API pleinement privilégié. Cela revient à céder le compte root, et à partir de là plus rien ne sépare le modèle du matériel.

Le risque vient du manque de contexte, pas de la mauvaise intention. Un modèle peut voir un disque vide et le traiter comme retirable alors qu’il appartient à une machine simplement éteinte. Il peut lire un pool dégradé et proposer de le reconstruire alors que le bon geste est de remplacer un disque. La commande est correctement écrite et le résultat est une perte de données.

C’est pourquoi, dans les environnements sérieux, le modèle reste en dehors du serveur. La perte se voit au diagnostic : lire de longs journaux et trouver ce qui a cassé est précisément ce qu’un modèle fait bien, et c’est précisément ce travail qui n’a pas lieu.

Ce qui peut être demandé

Le champ de commande du panneau sert à la fois à demander et à faire faire, comme une seule conversation. Les exemples ci-dessous sont le côté question : le modèle lit l’état du serveur et répond avec l’enregistrement sur lequel il s’appuie, et rien n’y change.

Pourquoi la sauvegarde de cette nuit a-t-elle échoué, à quelle étape s’est-elle arrêtée, restait-il de la place sur le stockage cible ?

Pourquoi cette machine virtuelle est-elle lente depuis hier soir, le goulot est-il le processeur ou le disque ?

Pourquoi le pool est-il dégradé, quel disque est tombé, les données sont-elles en danger maintenant ?

Laquelle des mises à jour en attente demande un redémarrage et quels services arrêtera-t-elle ?

Que signifie cette erreur dans le journal, est-elle déjà survenue, se répète-t-elle ?

À ce rythme, quand la capacité sera-t-elle pleine, quelle machine grossit le plus vite ?

Ce qui peut être fait

On appelle cela VibeOps : piloter un serveur en lui parlant. Le vibe coding, c’est écrire sans lire le code, et sur Proxmox ce n’est pas envisageable, donc ici chaque étape reste visible. Le travail se fait dans le même champ. On écrit ce que l’on veut. Atlas rapporte d’abord ce qu’il va faire et où cela touche : les étapes, les machines et les stockages concernés, et le chemin de retour. Le travail est réalisé après validation. Aucune nouvelle notion de droits n’apparaît : le champ de commande fonctionne avec les droits du compte Proxmox sous lequel il se connecte. Qui veut une IA plus étroite lui donne un compte Proxmox étroitement défini, et la portée est écrite dans les droits de ce compte. L’écriture peut aussi être coupée pour la session en cours, en restant en lecture seule. Chaque étape entre au journal d’audit.

Donne deux cœurs de plus à cette machine et porte sa mémoire à huit gigaoctets.

Programme une sauvegarde à trois heures du matin pour toutes les machines de ce pool.

Installe les correctifs de sécurité en attente, laisse ceux qui exigent un redémarrage pour la fenêtre de maintenance.

Règle la politique de redémarrage de ce conteneur sur toujours.

Donne à cet utilisateur uniquement le droit de sauvegarde, rien d’autre.

Déplace ce disque vers le nouveau pool, prends un instantané avant de le déplacer.

Le modèle passe par la même porte qu’une personne

Le serveur MCP n’ouvre aucune voie parallèle. Les protections qu’Atlas applique déjà à l’utilisateur humain s’appliquent au modèle, dans le même ordre.

Les autorisations viennent de Proxmox

Le modèle travaille avec les droits de l’utilisateur sous lequel il se connecte, pas avec un compte à lui. Ce que Proxmox ferme à cet utilisateur reste fermé au modèle. Atlas ne crée pas son propre système de droits.

Le compte Proxmox fixe la portée

Le champ de commande fonctionne avec les droits du compte Proxmox sous lequel il se connecte ; Atlas n’introduit aucune notion de droits qui lui soit propre. Qui veut une portée étroite lui donne un compte étroit, et cette portée est écrite dans les droits du compte et se relit là lors d’un audit. Couper l’écriture pour sa propre session tient en un geste.

L’impact est montré d’abord

Quand un changement est proposé, les étapes à appliquer, les ressources touchées et le chemin de retour sont montrés à une personne. La validation se fait à l’écran, pas dans la conversation.

Confirmation ferme pour ce qui est sans retour

Si le compte sous lequel il se connecte n’a pas le droit, supprimer, formater et défaire un pool sont tout simplement impossibles. Là où le droit existe, la confirmation ferme utilisée ailleurs dans le produit s’applique toujours : taper le nom pour confirmer, un clic ne suffit pas. Qui veut une étape de plus l’active : les écritures demandent un code à usage unique, la même validation en deux étapes que le compte utilise déjà.

Chaque étape est consignée

Tout ce que le modèle lit et chaque opération qu’il demande entrent au journal d’audit : quel utilisateur, quel modèle, quand, avec quel résultat. L’enregistrement ne peut plus être modifié.

Les réponses montrent leur source

Le modèle dit d’où vient sa conclusion : quelle ligne de journal, quelle mesure, quelle configuration. Une réponse invérifiable ne compte pas comme réponse.

Ce que le modèle ne peut pas faire

Les limites vivent dans le produit, pas dans la conversation. La façon dont le modèle est interrogé, ou l’insistance mise à le convaincre, ne change rien. Dans une organisation qui branche son propre modèle, les mêmes limites s’appliquent, car la règle est imposée dans le serveur et non dans le modèle.

Il ne peut pas élargir ses propres droits ni créer un utilisateur ou une clé d’accès.

Il ne peut appliquer aucune écriture sans validation.

Si le compte sous lequel il se connecte n’a pas de droit d’écriture, il ne change rien et se contente de lire.

Il ne peut pas ouvrir de shell sur le serveur ni basculer en ligne de commande. Cela sert rarement, car le travail exigeant de la profondeur est couvert lui aussi : du pool ZFS à Ceph, du pont à OVS, du verrouillage du noyau à l’attribution des droits, et la couverture s’élargit à chaque version. Pour la rare tâche qui sort du cadre, il écrit la commande et en explique le risque, et l’exécution reste à une personne.

Il ne peut ni supprimer ni modifier l’enregistrement d’audit.

Où vont les données

Le serveur MCP est un composant distinct et ne fait pas partie de l’installation par défaut. Il s’ajoute depuis le panneau en un bouton ; sur une machine qui n’en veut pas, pas même ses fichiers ne sont là. Une fois installé, les ressources qu’il peut consulter et la durée pendant laquelle il reste ouvert relèvent toujours du client.

Le choix du modèle appartient aussi au client. Avec un modèle local tournant sur le serveur, aucune donnée ne quitte la machine et le produit reste hors ligne. Si un service externe est choisi, le contenu à envoyer est visible avant l’envoi.

Pour les organisations sous réglementation stricte

Aucune certification n’est revendiquée. Le produit est conçu pour répondre aux exigences de cadres aux conditions d’audit dures, et l’audit interne d’une organisation peut retenir ces comportements comme preuve.

Système de management de l’IA (ISO/IEC 42001) : ce que le modèle peut faire est écrit, les limites sont imposées dans le produit, chaque usage est enregistré.

Sécurité de l’information (ISO/IEC 27001) : l’accès vient du système d’identité déjà en place, les privilèges suivent le moindre privilège, les enregistrements sont inaltérables.

Gestion du risque IA (ISO/IEC 23894 et NIST AI RMF) : aucune action autonome, la validation humaine est une étape obligatoire du flux.

Données personnelles (RGPD et équivalents) : les données restent sur la machine du client ; si elles doivent sortir, cela est visible avant et la décision revient au client.

Infrastructure critique (NIS2 et dispositions de transparence sur l’IA) : après un incident, qui a fait quoi, ce que le modèle a proposé et qui a validé se relisent.

Questions fréquentes

Cela revient-il à confier le serveur à une IA ?: Non. Ce qui est fait se limite aux droits que cet utilisateur possède dans Proxmox ; l’IA ne possède aucun droit propre. Qui veut une portée étroite donne à l’IA un compte Proxmox étroitement défini. Chaque opération demande un rapport d’impact et une validation.
Pourquoi ajouter cela à un produit qui fonctionne hors ligne ?: Le composant ne fait pas partie de l’installation par défaut, seul celui qui le veut l’ajoute. L’ajout lui-même demande une connexion à ce moment ; le reste du produit n’en dépend pas. Une fois installé, avec un modèle local tournant sur le serveur, le produit reste hors ligne.
Quels modèles seront pris en charge ?: Il y a deux voies : l’assistant fourni par Atlas, ou un modèle à soi. Le protocole étant indépendant du modèle, tout client qui parle Model Context Protocol peut se connecter, y compris ceux qui tournent en local. Quelle que soit la voie choisie, les limites ne changent pas, car elles résident dans le serveur et non dans le modèle.
Que se passe-t-il si le modèle dit quelque chose de faux ?: Une réponse fausse reste au niveau de la proposition, puisque l’application est une étape distincte. Chaque réponse montre aussi l’enregistrement sur lequel elle s’appuie, une personne peut donc la vérifier.
Comment cela tient-il lors d’un audit interne exigeant ?: Le journal d’audit porte tout ce que le modèle a lu et chaque opération qu’il a demandée. Qui a validé figure au même endroit, la chaîne de décision se relit donc entièrement.
Quand sera-ce disponible ?: La conception est faite, la réalisation figure dans la feuille de route produit. Une fois prête, les utilisateurs qui le souhaitent l’ajouteront depuis le panneau en un bouton ; une installation qui n’en veut pas reste telle quelle.

Fiches liées

Donner à un assistant IA l'accès à Proxmox : où la frontière doit se situer Le travail qu'un modèle fait vraiment bien, lire de longs journaux et trouver ce qui a cassé, est précisément celui qu'on ne l'autorise pas à faire. La raison : les seules voies actuelles lui donnent root, et le risque n'est pas la mauvaise intention mais le contexte manquant.