Red Hats Developer Preview für geschützte Kommandoausführung im RHEL MCP Server geht über Diagnose hinaus. Ein Assistent schlägt einen Befehl vor, ein Gatekeeper bewertet ihn, ein Mensch bleibt im Freigabepfad und systemd-run isoliert die Ausführung. Entscheidend ist nicht, dass ein Modell Shell-Kommandos schreiben kann, sondern das Kontrollmodell darum herum.
Bedeutung für den Betrieb
Ein zweites Modell ist allein keine unabhängige Sicherheitsgrenze. Es kann denselben Kontext missverstehen, einen syntaktisch harmlosen Befehl mit schwerwiegender fachlicher Wirkung freigeben oder die Kombination mehrerer Schritte übersehen. Deshalb braucht es deterministische Vorgaben für erlaubte Werkzeuge, Pfade, Benutzer, Ressourcen, Laufzeiten, Netzreichweite und grundsätzlich ausgeschlossene Kommandos.
Auch menschliche Zustimmung muss aussagekräftig sein. Unter Störungsdruck kann niemand eine lange generierte Pipeline prüfen und jede Nebenwirkung erkennen. Angezeigt werden müssen exakter Befehl, Ziel, erforderliches Privileg, erwartete Änderung und Rückweg. Freigabemüdigkeit ist ein Designfehler und kein Schulungsproblem.
Die dritte Schicht ist Laufzeitisolation. systemd-run kann CPU, Speicher, Dauer, Identität und Prozesslebenszeit begrenzen, doch die tatsächlichen Grenzen müssen getestet werden. Der Einstieg erfolgt mit Diagnosen auf nicht produktiven Systemen, vollständiger Ein- und Ausgabeprotokollierung und Vergleich zu einem bekannten Runbook. Remediation bleibt deterministische Automation, bis ein engerer delegierter Umfang belegt ist.
Praktische Konsequenz
Die praktische Konsequenz: Sichere AI-Ops brauchen drei getrennte Kontrollen – deterministische Regeln, informierte menschliche Zustimmung und technisch erzwungene Isolation. Fehlt eine davon, hängt das Design zu stark am Modellurteil. Das Ziel ist kein autonomer Root-Zugriff, sondern ein begrenzter, auch nach einem Vorfall erklärbarer Weg von Evidenz zu Aktion.