Heißt das, den Server einer KI zu überlassen?

Nein. Getan wird nur so viel, wie die Berechtigung dieses Benutzers in Proxmox zulässt; die KI besitzt keine eigene Berechtigung. Wer einen engen Umfang möchte, gibt der KI ein eng gefasstes Proxmox-Konto. Jeder Vorgang verlangt einen Wirkungsbericht und eine Freigabe.

Warum kommt das in ein Produkt, das offline läuft?

Die Komponente gehört nicht zur Standardinstallation, nur wer sie will, fügt sie hinzu. Das Hinzufügen selbst braucht in diesem Moment eine Verbindung; der Rest des Produkts bleibt davon unberührt. Ist sie installiert, bleibt das Produkt mit einem lokal auf dem Server laufenden Modell offline.

Welche Modelle werden unterstützt?

Es gibt zwei Wege: den Assistenten, den Atlas bereitstellt, oder ein eigenes Modell. Das Protokoll ist modellunabhängig, daher kann sich jeder Client verbinden, der Model Context Protocol spricht, auch lokal laufende. Welcher Weg auch gewählt wird, die Grenzen ändern sich nicht, denn sie liegen im Server und nicht im Modell.

Was passiert, wenn das Modell etwas Falsches sagt?

Eine falsche Antwort bleibt auf der Ebene eines Vorschlags, weil die Ausführung ein eigener Schritt ist. Jede Antwort zeigt zudem den Eintrag, auf den sie sich stützt, sodass ein Mensch sie prüfen kann.

Wie hält das einer harten Unternehmensprüfung stand?

Das Prüfprotokoll trägt alles, was das Modell gelesen hat, und jeden Vorgang, den es angefordert hat. Wer freigegeben hat, steht im selben Eintrag, die Entscheidungskette ist also rückwirkend lesbar.

Wann wird es verfügbar sein?

Der Entwurf steht, die Umsetzung liegt in der Produkt-Roadmap. Ist sie fertig, fügen interessierte Nutzer sie im Panel mit einer Schaltfläche hinzu; eine Installation, die sie nicht will, bleibt unverändert.

Die KI soll den Server führen, nicht beschädigen

Atlas kann für alle, die das wollen, seinen eigenen Model-Context-Protocol-Server öffnen und bietet im Panel ein Befehlsfeld. Es ist eine eigene Komponente: sie kommt nicht mit der Installation, wer sie will, fügt sie im Panel mit einer Schaltfläche hinzu, und auf einer Maschine, die sie nicht will, ist sie gar nicht vorhanden. Ist sie hinzugefügt, wird der Zustand des Servers gelesen, eine Störung durchgearbeitet und Arbeit erledigt, indem man schreibt, was man möchte. Die Grenze zieht Proxmox: woran ein Benutzer rühren darf, daran rührt auch die KI, mehr nicht. Ein neues Berechtigungskonzept entsteht nicht. Die KI wird an Atlas angeschlossen, nicht an Proxmox. Proxmox liegt darunter, doch das Modell greift nie direkt darauf zu; es nutzt nur, was Atlas kann.

Was es heute kostet, einem Modell Serverzugriff zu geben

Heute gibt es nur einen Weg, damit ein KI-Assistent mit Proxmox arbeiten kann: eine SSH-Sitzung oder ein voll berechtigtes API-Token. Das heißt Root übergeben, und ab da steht nichts mehr zwischen Modell und Hardware.

Das Risiko entsteht aus fehlendem Kontext, nicht aus böser Absicht. Ein Modell kann eine Platte für leer halten und als entfernbar behandeln, obwohl sie zu einer nur ausgeschalteten Maschine gehört. Es kann einen degradierten Pool lesen und einen Neuaufbau vorschlagen, obwohl der richtige Schritt der Tausch einer Platte wäre. Der Befehl ist korrekt geschrieben, das Ergebnis ist Datenverlust.

Deshalb bleibt das Modell in ernsthaften Umgebungen außerhalb des Servers. Der Verlust zeigt sich bei der Diagnose: lange Protokolle lesen und finden, was kaputt ist, kann ein Modell wirklich gut, und genau diese Arbeit bleibt liegen.

Was gefragt werden kann

Im Befehlsfeld des Panels wird sowohl gefragt als auch beauftragt, als ein einziges Gespräch. Die folgenden Beispiele sind die Frageseite: das Modell liest den Zustand des Servers und antwortet mit dem Eintrag, auf den es sich stützt, dabei ändert sich nichts.

Warum ist die Sicherung heute Nacht fehlgeschlagen, bei welchem Schritt blieb sie stehen, war auf dem Zielspeicher Platz?

Warum ist diese virtuelle Maschine seit gestern Abend langsam, liegt der Engpass beim Prozessor oder bei der Platte?

Warum ist der Pool degradiert, welche Platte ist ausgefallen, sind die Daten gerade gefährdet?

Welches der ausstehenden Updates verlangt einen Neustart und welche Dienste hält es an?

Was bedeutet dieser Fehler im Protokoll, gab es ihn schon einmal, wiederholt er sich?

Wann ist die Kapazität in diesem Tempo voll, welche Maschine wächst am schnellsten?

Was erledigt werden kann

Das nennt man VibeOps: einen Server im Gespräch führen. Vibe Coding heißt schreiben, ohne den Code zu lesen, und bei Proxmox geht das nicht, deshalb bleibt hier jeder Schritt sichtbar. Im selben Feld wird auch gearbeitet. Man schreibt, was man möchte. Atlas meldet zuerst, was getan wird und wo es eingreift: die Schritte, die betroffenen Maschinen und Speicher und der Rückweg. Nach der Freigabe wird die Arbeit erledigt. Ein neues Berechtigungskonzept entsteht nicht: das Befehlsfeld arbeitet mit den Rechten des Proxmox-Kontos, als das es sich verbindet. Wer eine engere KI möchte, gibt ihr ein eng gefasstes Proxmox-Konto, und der Umfang steht in den Rechten dieses Kontos. Wer mag, schaltet das Schreiben für die eigene Sitzung ab und bleibt beim Lesen. Jeder Schritt landet im Prüfprotokoll.

Gib dieser Maschine zwei weitere Kerne und erhöhe den Speicher auf acht Gigabyte.

Richte für alle Maschinen in diesem Pool eine Sicherung um drei Uhr nachts ein.

Installiere die ausstehenden Sicherheitspatches, die mit Neustart bleiben im Wartungsfenster.

Setze die Neustartregel dieses Containers auf immer.

Gib diesem Benutzer nur Sicherungsrechte, sonst nichts.

Verschiebe diese Platte in den neuen Pool, mache vorher eine Momentaufnahme.

Das Modell geht durch dasselbe Tor wie ein Mensch

Der MCP-Server öffnet keinen Nebenweg. Dieselben Schutzmechanismen, die Atlas für den menschlichen Benutzer bereits ausführt, gelten in derselben Reihenfolge auch für das Modell.

Berechtigungen kommen aus Proxmox

Das Modell arbeitet mit den Rechten des Benutzers, als der es sich verbindet, nicht mit einem eigenen Konto. Was Proxmox diesem Benutzer verschließt, bleibt auch dem Modell verschlossen. Atlas legt kein eigenes Rechtesystem an.

Das Proxmox-Konto setzt den Umfang

Das Befehlsfeld arbeitet mit den Rechten des Proxmox-Kontos, als das es sich verbindet; Atlas führt kein eigenes Berechtigungskonzept ein. Wer einen engen Umfang möchte, gibt ihm ein enges Konto, und dieser Umfang steht in den Rechten des Kontos und wird bei einer Prüfung dort abgelesen. Das Schreiben für die eigene Sitzung abzuschalten, ist ein Griff.

Die Auswirkung wird zuerst gezeigt

Wird eine Änderung vorgeschlagen, sieht ein Mensch die auszuführenden Schritte, die betroffenen Ressourcen und den Rückweg. Die Freigabe erfolgt auf dem Bildschirm, nicht im Gespräch.

Harte Bestätigung bei unumkehrbarer Arbeit

Besitzt das Konto, als das es sich verbindet, keine Berechtigung, sind Löschen, Formatieren und das Auflösen eines Pools überhaupt nicht möglich. Wo die Berechtigung besteht, gilt weiterhin die harte Bestätigung, die das Produkt auch anderswo nutzt: den Namen eintippen, ein Klick genügt nicht. Wer einen weiteren Schritt möchte, schaltet ihn ein: Schreibvorgänge verlangen einen Einmalcode, dieselbe Zwei-Faktor-Bestätigung, die das Konto ohnehin nutzt.

Jeder Schritt wird protokolliert

Alles, was das Modell liest, und jeder Vorgang, den es anfordert, geht ins Prüfprotokoll: welcher Benutzer, welches Modell, wann, mit welchem Ergebnis. Der Eintrag lässt sich später nicht ändern.

Antworten zeigen ihre Quelle

Das Modell nennt, woraus es geschlossen hat: welche Protokollzeile, welche Messung, welche Konfiguration. Eine nicht prüfbare Antwort gilt nicht als Antwort.

Was das Modell nicht kann

Die Grenzen liegen im Produkt, nicht im Gespräch. Wie das Modell gefragt oder wie sehr es überredet wird, spielt keine Rolle. Auch in einer Organisation, die ihr eigenes Modell anbindet, gelten dieselben Grenzen, denn die Regel wird im Server durchgesetzt und nicht im Modell.

Es kann seine eigenen Rechte nicht erweitern und keinen neuen Benutzer oder Zugriffsschlüssel anlegen.

Es kann ohne Freigabe keinen Schreibvorgang ausführen.

Besitzt das Konto, als das es sich verbindet, kein Schreibrecht, ändert es nichts und liest nur.

Es kann auf dem Server keine Shell öffnen und nicht auf die Kommandozeile wechseln. Das wird selten gebraucht, denn auch Arbeit mit Tiefgang ist abgedeckt: vom ZFS-Pool bis Ceph, von der Bridge bis OVS, vom Festsetzen des Kernels bis zur Rechtevergabe, und der Umfang wächst mit jeder Version. Für den seltenen Fall außerhalb schreibt es den Befehl und erklärt das Risiko, ausgeführt wird er von einem Menschen.

Es kann den Prüfeintrag weder löschen noch ändern.

Wohin die Daten gehen

Der MCP-Server ist eine eigene Komponente und gehört nicht zur Standardinstallation. Er wird im Panel mit einer Schaltfläche hinzugefügt; auf einer Maschine, die ihn nicht will, liegt nicht einmal eine Datei davon. Nach der Installation bleibt es beim Kunden, welche Ressourcen er sehen darf und wie lange er offen steht.

Auch die Wahl des Modells liegt beim Kunden. Mit einem lokal auf dem Server laufenden Modell verlässt kein Datum die Maschine, das Produkt bleibt offline. Wird ein externer Dienst gewählt, ist der zu sendende Inhalt vor dem Senden sichtbar.

Für streng regulierte Organisationen

Es wird keine Zertifizierung behauptet. Das Produkt ist so ausgelegt, dass es die Anforderungen von Rahmenwerken mit harten Prüfbedingungen erfüllt; die eigene Prüfung einer Organisation kann diese Eigenschaften als Nachweis verwenden.

KI-Managementsystem (ISO/IEC 42001): was das Modell darf, ist schriftlich festgelegt, die Grenzen werden im Produkt erzwungen, jede Nutzung wird aufgezeichnet.

Informationssicherheit (ISO/IEC 27001): der Zugriff kommt aus dem vorhandenen Identitätssystem, Rechte folgen dem Prinzip der geringsten Berechtigung, Einträge sind unveränderlich.

KI-Risikomanagement (ISO/IEC 23894 und NIST AI RMF): keine autonome Handlung, die menschliche Freigabe ist ein Pflichtschritt im Ablauf.

Personenbezogene Daten (DSGVO und Entsprechungen): die Daten bleiben auf der Maschine des Kunden; sollen sie hinaus, ist das vorher sichtbar und die Entscheidung liegt beim Kunden.

Kritische Infrastruktur (NIS2 und Transparenzvorgaben zur KI): nach einem Vorfall lässt sich rückwirkend lesen, wer was getan, was das Modell vorgeschlagen und wer es freigegeben hat.

Häufige Fragen

Heißt das, den Server einer KI zu überlassen?: Nein. Getan wird nur so viel, wie die Berechtigung dieses Benutzers in Proxmox zulässt; die KI besitzt keine eigene Berechtigung. Wer einen engen Umfang möchte, gibt der KI ein eng gefasstes Proxmox-Konto. Jeder Vorgang verlangt einen Wirkungsbericht und eine Freigabe.
Warum kommt das in ein Produkt, das offline läuft?: Die Komponente gehört nicht zur Standardinstallation, nur wer sie will, fügt sie hinzu. Das Hinzufügen selbst braucht in diesem Moment eine Verbindung; der Rest des Produkts bleibt davon unberührt. Ist sie installiert, bleibt das Produkt mit einem lokal auf dem Server laufenden Modell offline.
Welche Modelle werden unterstützt?: Es gibt zwei Wege: den Assistenten, den Atlas bereitstellt, oder ein eigenes Modell. Das Protokoll ist modellunabhängig, daher kann sich jeder Client verbinden, der Model Context Protocol spricht, auch lokal laufende. Welcher Weg auch gewählt wird, die Grenzen ändern sich nicht, denn sie liegen im Server und nicht im Modell.
Was passiert, wenn das Modell etwas Falsches sagt?: Eine falsche Antwort bleibt auf der Ebene eines Vorschlags, weil die Ausführung ein eigener Schritt ist. Jede Antwort zeigt zudem den Eintrag, auf den sie sich stützt, sodass ein Mensch sie prüfen kann.
Wie hält das einer harten Unternehmensprüfung stand?: Das Prüfprotokoll trägt alles, was das Modell gelesen hat, und jeden Vorgang, den es angefordert hat. Wer freigegeben hat, steht im selben Eintrag, die Entscheidungskette ist also rückwirkend lesbar.
Wann wird es verfügbar sein?: Der Entwurf steht, die Umsetzung liegt in der Produkt-Roadmap. Ist sie fertig, fügen interessierte Nutzer sie im Panel mit einer Schaltfläche hinzu; eine Installation, die sie nicht will, bleibt unverändert.