Einem KI-Assistenten Proxmox-Zugriff geben: wo die Grenze sitzen muss

Hier gibt es eine echte und etwas ärgerliche Schieflage. Zweitausend Protokollzeilen zu lesen und die Zeile zu finden, an der etwas kaputtging, ist genau das, was ein Sprachmodell gut kann. Es ist zugleich genau die Arbeit, die die meisten es nicht tun lassen können, und zwar wegen der Art, wie Zugriff vergeben wird.

Die Frage ist nicht, ob ein Modell einen Server anfassen soll. Die Frage ist, wo die Grenze sitzt, und heute sitzt sie meist an der falschen Stelle.

Warum das übliche Vorgehen unangenehm ist

Es gibt zwei gängige Wege, einen Assistenten mit Proxmox zu verbinden: eine SSH-Sitzung geben oder ein voll berechtigtes API-Token. Beides läuft auf dasselbe hinaus. Ab diesem Moment steht nichts mehr zwischen Modell und Hardware, und sämtliche Schutzmaßnahmen leben in der Formulierung einer Anweisung.

Eine Anweisung ist keine Grenze. Sie ist eine Bitte an ein System, das darauf ausgelegt ist, hilfsbereit zu sein, in einer Sprache ohne Durchsetzungskraft.

Das Risiko ist fehlender Kontext, nicht böse Absicht

Genau das wird falsch diagnostiziert. Die Fehlerform ist selten ein Modell, das Schaden anrichten will. Es ist ein Modell, das auf einem unvollständigen Bild korrekt handelt.

Eine Platte, die leer aussieht. Das Modell liest ein Gerät ohne eingehängtes Dateisystem und hält es für frei. Das Gerät gehört zu einer Maschine, die schlicht ausgeschaltet ist.

Ein degradierter Pool. Das Modell liest den degradierten Zustand und schlägt vor, den Verbund neu aufzubauen. Der richtige Schritt war, eine Platte zu tauschen, und der Neuaufbau ist der Weg, auf dem die restlichen Daten verloren gehen.

Ein Dienst, der "nicht läuft". Er läuft nicht, weil er nach Zeitplan läuft und fertig ist. Ihn neu zu starten ist harmlos; ihn zu deaktivieren, weil er "ständig stehenbleibt", nicht.

In allen dreien ist der Befehl korrekt geschrieben. Falsch ist die Prämisse, und ein korrekter Befehl auf falscher Prämisse ist im Nachhinein nicht von Sabotage zu unterscheiden.

Nur-Lesen hilft, und ist nicht die ganze Antwort

Die naheliegende Antwort ist Nur-Lese-Zugriff, und sie beseitigt die schlimmsten Ausgänge tatsächlich. Zwei Dinge bleiben.

Lesen ist nicht umsonst. Konfiguration, Protokolle und Prüfaufzeichnungen enthalten Hostnamen, Adressen, Benutzernamen und manchmal Token, die dort eingefügt wurden, wo sie nicht hingehören. Ein Nur-Lese-Assistent mit vollem Leseumfang ist ein Export Ihrer Infrastruktur.

Diagnose ohne Handlung bleibt auf halbem Weg stehen. Wenn die nützliche Antwort lautet "starte diesen einen Dienst neu", gibt eine Nur-Lese-Einrichtung den Befund an einen Menschen zum Abtippen zurück. Das ist in Ordnung, und es ist auch der Grund, warum Berechtigungen später leise erweitert werden.

Nur-Lesen ist also ein guter Anfang und ein schlechtes Ziel. Das Ziel ist enger Schreibzugriff durch dieselben Tore, die ein Mensch passiert.

Wo die Grenze tatsächlich hingehört

Nicht in die Anweisung und nicht ins Modell. In die ausführende Schicht, denn nur sie kann ablehnen.

Drei Eigenschaften machen eine solche Schicht vertrauenswürdig, und alle drei sind prüfbar statt versprochen.

Berechtigungen kommen aus dem System, das sie schon hat. Verbindet sich der Assistent über ein bestehendes Konto, ist genau das, was dieses Konto anfassen darf, auch das, was der Assistent anfassen darf. Es wird kein zweites Berechtigungsmodell erfunden, also gibt es nichts synchron zu halten und keine Möglichkeit, dass beide sich widersprechen.

Zerstörende Operationen passieren dasselbe Tor wie beim Menschen. Fragt das Löschen einer Platte einen Menschen um Bestätigung, muss es das auch tun, wenn ein Modell es verlangt. Ein Pfad, der für Menschen sicher und für Automatisierung offen ist, ist keine Grenze, sondern eine Abkürzung mit gutem Namen.

Jeder Schritt landet im Prüfprotokoll. Wer, was, wann, woran und mit welchem Ergebnis. Ohne das hat die eigentliche Frage nach einem Vorfall, "hat das der Assistent gemacht", keine Antwort, und das Fehlen dieser Antwort ist für sich genommen ein Grund, keinen Zugriff zu geben.

Die Frage, die man zu jedem solchen Werkzeug stellen sollte

Nicht "ist es sicher", sondern "was lehnt ab, und wo wohnt das?"

Lautet die Antwort "dem Modell wurde gesagt, es soll nicht", gibt es keine Grenze. Lautet sie "die ausführende Schicht prüft die Berechtigungen des Kontos und schleust zerstörende Schritte durch ein Tor", gibt es eine, und Sie können sie testen: mit einem eingeschränkten Konto verbinden und bestätigen, dass die Ablehnung echt ist.

Was Atlas macht

⚠️ Diese Schicht ist geplant, nicht ausgeliefert. Was folgt, ist der Entwurf, auf den hin sie gebaut wird, hier aufgeschrieben, weil die obige Frage eine ehrliche Antwort verdient und keine werbliche.

Die Absicht ist, dass sich der Assistent an Atlas anschließt, nicht an Proxmox. Proxmox liegt darunter, und das Modell erreicht es nie direkt; es kann nur nutzen, was Atlas selbst kann, wodurch jedes bestehende Tor im Pfad bleibt.

Die Grenze zieht Proxmox über die Berechtigungen, also die erste Eigenschaft oben: was das verbindende Konto anfassen darf, fasst der Assistent auch nur an, und es entsteht kein neues Berechtigungskonzept. Zerstörende Operationen behalten ihre bestehende Bestätigung, und das Prüfprotokoll hält für jede privilegierte Aktion bereits wer, was, wann, woran und mit welchem Ergebnis fest, abgelehnte eingeschlossen.

Zudem soll es eine eigenständige Komponente sein und nicht Teil der Installation: auf einer Maschine, die sie nicht will, ist sie nie vorhanden. Das ist aus demselben Grund wichtig wie der Rest dieses Artikels. Die sicherste Grenze für eine Fähigkeit, die Sie nicht gewählt haben, ist ihre Abwesenheit.