Infrastruktur mit KI-Agenten über MCP betreiben

Wie KI-Agenten über den MCP-Server mit Opfield arbeiten: OAuth mit begrenzten Rechten, das Audit-Log, Schutz vor Versehen, Docker-Werkzeuge und ein Beispiel für eine alltägliche Reparatur.

Autor: Opfield-Team4 Min. Lesezeit

Opfield hat neben seiner REST-API einen MCP-Server. Jeder MCP-Client, etwa ein Coding-Agent im Editor oder eine Chat-App, kann sich damit verbinden und mit denselben Ressourcen arbeiten, die ein Mensch in der Oberfläche sieht: Routen, Container, verwaltete Datenbanken, Pages, Alarme und Knoten. Dieser Beitrag erklärt, wie dieser Zugriff sicher bleibt und wie eine typische Sitzung aussieht.

Dieselben Regeln wie für Menschen

Für Agenten gibt es kein eigenes Rechtemodell. Ein MCP-Client verbindet sich mit https://<your-opfield>/api/mcp und meldet sich per OAuth im Namen eines Nutzers an. Auf dem Zustimmungsbildschirm wählt der Nutzer die Scopes, die der Client erhält, und diese gehen nie über die Rechte des Nutzers hinaus. Zugriff, der auf Ordner, Knoten oder einzelne Ressourcen beschränkt ist, funktioniert genauso: Ein Agent mit Zugriff auf den Ordner einer App sieht diesen Ordner und sonst nichts. Mit get_my_access kann der Agent abfragen, was ihm gewährt wurde und wo er Ressourcen anlegen darf.

Agenten können mit Ressourcen fast alles tun, was ein Mensch kann. Einiges bleibt bewusst dem Browser vorbehalten: Impersonation, die OAuth-Zustimmung, das Erstellen von API-Tokens oder Autorisierungen sowie die eigene Anmeldung und Sitzungen des Nutzers. Ein Agent kann sich keine zusätzlichen Rechte geben.

Der MCP-Endpunkt akzeptiert nur OAuth-Tokens, die für ihn ausgestellt wurden; REST-API-Tokens funktionieren dort nicht. Der Nutzer braucht außerdem die MCP-Berechtigung, sodass ein Admin entscheidet, wer überhaupt Agenten anbinden darf.

Alles landet im Audit-Log

Jede Aktion eines Agenten durchläuft dieselben Prüfungen wie ein Klick in der Oberfläche und wird im selben Audit-Log festgehalten, mit dem Nutzer und dem Token, von dem sie kam. Was ein Agent über Nacht geändert hat, sehen Sie im Audit-Log.

Schutz vor Versehen

Rechte legen fest, was ein Agent darf. Manche Fehler passieren aber innerhalb dieser Rechte, deshalb hat Opfield zusätzliche Schutzmechanismen:

  • Konsolenschutz. Agenten können Befehle in der Konsole eines Knotens als root ausführen und ihn so reparieren. Docker, containerd und Podman sind dort ausgeblendet, und ein Docker-Befehl wird mit dem Hinweis auf das passende Opfield-Werkzeug abgelehnt. Das ist ein Schutz vor Versehen, keine Sicherheitsgrenze: Er verhindert, dass ein Agent einen verwalteten Container an Opfield vorbei ändert.
  • Kein SSH auf Knoten. Agenten können keine Befehle per SSH auf Hosts ausführen, die Opfield-Knoten sind. Dafür gibt es die Knotenkonsole mit ihrem Schutz.
  • Änderungen an Opfield vorbei werden sichtbar. Wird ein verwalteter Container trotzdem von Hand gestoppt, geändert oder entfernt, löst der eingebaute Alarm „Container changed outside Opfield“ aus.
  • Sichere Wiederholungen. Anlege-Operationen akzeptieren einen Idempotenzschlüssel, sodass ein Agent, der nach einem Timeout erneut anfragt, kein Duplikat erzeugt.

Docker-Werkzeuge statt Shell

Der Großteil der Arbeit eines Agenten an Workloads läuft über eigene Werkzeuge statt über Shell-Befehle: Container auf allen Docker-Knoten auflisten, Logs und Metriken lesen, neu starten, ein Image aktualisieren, die Konfiguration ändern, Deployments mit Slots und Rollback, Compose-Projekte, Volumes, Netzwerke sowie Git-Quellen mit ihren Builds. Weil das Opfield-Operationen sind, bleiben Routen, Secure Links und Verfügbarkeit nach einer Änderung stimmig, und jeder Schritt wird protokolliert.

Agenten können außerdem die Dokumentation und Skills von Opfield über MCP lesen, bevor sie etwas ändern.

Beispiel: ein ausgefallener Dienst

Ein Nutzer schreibt einem Agenten: „Die Billing-API liefert seit heute Morgen 502. Finde die Ursache und behebe sie.“ Eine typische Sitzung:

  1. find_resource findet die Route und den Container dahinter; get_route zeigt den Upstream.
  2. get_docker_container zeigt, dass der Container ständig neu startet und seine Git-Quelle um 07:40 einen neuen Build ausgerollt hat.
  3. get_docker_container_logs zeigt, dass der Prozess beim Start beendet wird, weil eine neue Pflicht-Umgebungsvariable fehlt.
  4. Der Agent meldet das und bietet zwei Wege an: zurück zum vorherigen Build oder die Variable ergänzen.
  5. Der Nutzer entscheidet sich für das Rollback. Der Agent ruft manage_docker_source mit rollback auf und prüft danach Logs und Route erneut: Der Container läuft, die Route antwortet mit 200. Das Rollback steht im Audit-Log unter dem Namen des Nutzers.

Niemand brauchte Shell-Zugriff auf den Server, und der Agent hat nichts außerhalb der Rechte des Nutzers getan.

Erste Schritte

Fügen Sie den MCP-Server mit der Adresse Ihres Opfield in Ihrem Client hinzu, melden Sie sich an und wählen Sie die Scopes. Beginnen Sie mit reinen Lese-Scopes, beobachten Sie im Audit-Log, was der Agent tut, und erweitern Sie den Zugriff, wenn Sie Vertrauen gewonnen haben. Wenn Sie keinen Client einrichten möchten: Der in Opfield eingebaute Assistent nutzt dieselben Werkzeuge und dieselben Regeln.