Wie Open-WebUI / Agenten am besten Testserver steuern lassen (Tool-Server vs. Terminal vs. SSH)?

[speefak]

Hallo zusammen,

ich habe mir eine eigene KI-Umgebung aufgebaut und die KI-Systeme in ein isoliertes Netz (IsoLAN_KI) verbannt, dessen Zugriffe über eine OPNsense-Firewall geregelt werden. Die KI-Dienste laufen auf einem Server im Keller, in dem aktuell noch keine leistungsfähige GPU steckt (nur eine Quadro P2000 mit 5 GB VRAM – ich bin noch unschlüssig, ob später eine RTX 2000 Ada oder ein NVIDIA DGX Spark rein soll).

Deshalb läuft der Ollama-Server aktuell auf einem Desktop-System, und in der IsoLAN_KI-Firewall ist nur der Ollama-Port ins private Netz freigegeben. Das funktioniert soweit gut: Der Desktop (i7-12700, 32 GB RAM, RTX 2060 8 GB VRAM) liefert mit dem Modell Qwen3-30B-A3B-Instruct-2507 trotz bescheidener Hardware noch brauchbare Ergebnisse bei Antwortzeit und -qualität.

Das eigentliche Problem

Die letzte Woche habe ich mich mit LLM-Tooling beschäftigt, um Open WebUI/LLMs Zugriff auf ein Linux-System zu geben (Code testen, Scripts ausführen etc.). Dabei bin ich auf viele, teils widersprüchliche Ansätze gestoßen und bin mir über die Zusammenhänge nicht im Klaren.

Grundfrage: Was brauche ich genau, damit ein LLM ein Linux-System vollständig wie ein User per Terminal steuern kann (inkl. sudo-Rechten)?

Zwei Ansätze, die mir begegnet sind:

1. Open Terminal auf einem Testserver, das man in Open WebUI unter "Services → Terminal" einträgt. Open WebUI hätte darüber vollen Zugriff auf den Testserver.
2. Tool-Server installieren, der dem LLM mehr und effizienter aufrufbare Tools bereitstellt, statt alles per exec über SSH laufen zu lassen.

Zu Ansatz 2 ergeben sich bei mir zwei Unterfragen:

2.1 Wo installiere ich den Tool-Server am besten?Wenn der Tool-Server keinen Zugriff auf seinen eigenen Host haben soll, könnte man ihn (um eine VM zu sparen) auch auf dem Ollama-Server selbst installieren. Er müsste dann aber trotzdem per SSH auf den Testserver zugreifen – womit man wieder bei "exec via SSH" landet. Hat der Tool-Server in diesem Szenario überhaupt noch einen Vorteil gegenüber einer einfachen SSH-Terminalverbindung?

2.2 Tool- und Testserver als ein SystemStatt eines reinen Terminals installiere ich den kompletten Tool-Server direkt auf dem Testserver. Problem: In Open WebUI kann ich nur einen Tool-Server angeben – bei mehreren Testservern mit jeweils eigenem Tool-Server ist das unpraktisch.

Mein Ziel ist es, in Open WebUI z. B. ein Script hochzuladen und im Chat zu sagen: "Verbinde dich auf Testserver 1 und teste das Script, zeige mir die Ausgabe hier im Chat."

Eine KI schlug mir vor, einen eigenen Tool-Server aufzusetzen, auf dem konfigurierbar ist, welche Tools zur Verfügung stehen – u. a. auch, auf dem Proxmox-Host anhand eines Templates einen neuen Testserver zu erstellen. Das wäre natürlich ideal, weil man dann nur noch das Testserver-Template braucht und der Rest (erstellen, testen, löschen) von der KI selbst erledigt wird.

Perspektivisch sollen außerdem vollständige Agenten (z. B. OpenClaw, Hermes, CodeHmr) im isolierten KI-Netz laufen und – analog zu Open WebUI, über einen Tool-Server oder direkt – eine Proxmox-VM erstellen, nutzen, Code darauf ausführen und anschließend wieder löschen können.

Zentrale Fragen:

• Was brauche ich wofür genau (Terminal-Service, Tool-Server, SSH-Gateway)?
• Wo sollte der Tool-Server am besten laufen – eigene VM oder zusammen mit dem Ollama-Server? Auf dem Ollama-Server hätte man den Vorteil, dass alles auf einem System liegt. Hat der Tool-Server aber Zugriff auf seinen eigenen Host, hat er damit auch Zugriff auf den Ollama-Server – das darf nicht sein.
• Kann man dem Tool-Server jeglichen Zugriff auf seinen eigenen Host verwehren und nur die Tools (inkl. "neuen Testserver anfordern") dort hinterlegen? Wie steuert der Tool-Server dann aber den Testserver – läuft das nicht am Ende doch wieder über SSH? Und welchen Vorteil hätte der Tool-Server dann noch gegenüber einem einfachen SSH-/Terminal-Server?

Ich wäre sehr dankbar, wenn mir jemand die Zusammenhänge erklären könnte und eine Empfehlung hat, wie ich das für mein Szenario am sinnvollsten aufsetze.


Danke schon mal!

 

[Tornhoof]

Dir muss bewusst sein, dass da verdammt viel "Übersetzung" passieren wird zwischen den Systemen, der Normalfall ist eigentlich dass deine Harness Applikation (sei es jetzt OpenCode, dein Open-WebUI, codex, claude, Github Client CLI) über die Tools direkten Zugriff auf deine abgeschottete VM hat, also praktisch da drin läuft und dein Ollama-Server ggf. irgendwo in einer anderen VM läuft oder halt einen kommerziellen Anbieter anbindet.

 

[aluis]

Du kannst zB OpenClaw vollständige root rechte geben und das kann dann alles machen was du willst.

 

[nutrix]

@aluis Das halte ich für keine gute Idee.

 

[aluis]

@nutrix Das war mir so klar, dass deswegen einer um die Ecke kommt^^

Das ist sogar eine sehr gute Idee, in einer extra VM, wo man kontrollieren kann was rein und raus geht.

Ich muss auf Arbeit viel mit Claude Code machen, dass hat auch root Zugriff und installiert/konfiguriert notwendige Pakete selbstständig nach und notiert das in den Requirements. Warum sollte ich das selber machen?

 

[Tornhoof]

Weil du dank Supply Chain attacken auf externe Abhängigkeiten, dir Schrott in deine VM holst, der Wurm aus der VM ausbricht und dein Netzwerk zerlegt. (etwas überspitzt ausgedrückt)

 

[nutrix]

Das ist sogar eine sehr gute Idee, in einer extra VM, wo man kontrollieren kann was rein und raus geht.

Nein, ist definitiv nicht, weil Dir offensichtlich nicht bewußt ist, daß Programme sehr wohl aus Sandboxen und VMs ausbrechen können. Dazu gibt es sogar mittlerweile Erfahrungswerte
https://www.golem.de/news/bei-sandboxing-tests-ki-agent-bricht-mehrfach-aus-vm-aus-2608-212442.html

Der Forscher warnt vor diesem Hintergrund, dass eine reguläre VM heute nicht mehr ausreiche, um KI-Agenten zu isolieren. Die Angriffsfläche sei "einfach zu groß" und werde durch scheinbar harmlose Funktionen zusätzlich vergrößert. "Wir müssen die Qualität von Sandboxing-Lösungen für leistungsfähige KI-Agenten neu bewerten – und ganz allgemein den Software-Stack, mit dem sie interagieren", so Dinaburg.

Dinaburg empfiehlt etwa, einer KI erteilte Berechtigungen immer auf das für die zu lösende Aufgabe zwingend erforderliche Minimum zu beschränken und eingesetzte Software möglichst zügig zu patchen. "Ich mag ältere, stabile Software, aber der Zyklus des Backportings von Patches ist einfach zu lang", erklärt der Forscher.

@nutrix Das war mir so klar, dass deswegen einer um die Ecke kommt^^

Ja, weil der einer genau zu denen gehört, der genau den Scheiß hinterher aufräumen darf, den einer mal so in seinem Leichtsinn mit der Mißachtung aller Sicherheitregeln verursachte.

Tipp: Mach bitte vorher bitte bitte unbedingt entsprechende Schulungen und Training bzgl. IT-Sicherheit. Man gibt KEIN UNBEGRENZTEN ROOT-Zugang. Never!

 

[aluis]

@Tornhoof Supply Chain attacken? Ob ich nun Schadcode selber installiere oder es KI machen lasse, spielt doch keine Rolle. Selbstverständlich kontrolliert man seine Abhängigkeiten.

@nutrix klar. Mein Agent will Paket XYZ installieren ich drücke y und dann bricht er aus der VM aus, startet Skynet und löscht die Menschheit aus.

Was schlägst du vor? Soll ich meinen Job kündigen, weil das Leute im Computerbase Forum zu gefährlich finden?

 

[nutrix]

Was schlägst du vor? Soll ich meinen Job kündigen, weil das Leute im Computerbase Forum zu gefährlich finden?

Wenn Du da tatsächlich so leichtsinnig und leichtgläubig rangehst, ja, definitiv. Wurdest Du sowas bei mir im Arbeitsumfeld bringen und ich bekäme das mit, würdest Du

1. Fristlose Kündigung bekommen
2. Schadensersatzforderungen für all den Schaden bekommen, den Du verursacht hast. Rechne mal mit ein paar Millionen

Dann arbeitest Du aktuell anscheinend nur in einer Krauterbude, wenn Du davon nichts weißt oder es ignorierst. Normalerweise ist im ernsthaften IT-Betrieb sowieso schon durch entsprechende Arbeitsverträge etc. geregelt, und man bekommt heute auch üblicherweise entsprechende (Sicherheitss-)Einweisungen, was man machen darf oder nicht. In den heutigen Arbeitsverträgen ist meistens ein Passus mit Haftung bei grob fahrlässiger Handlung drin. Einem System unbegrenzt Root geben ist grob fahrlässig.

Ergänzung (Mittwoch um 16:36)

@nutrix klar. Mein Agent will Paket XYZ installieren ich drücke y und dann bricht er aus der VM aus, startet Skynet und löscht die Menschheit aus.

Es gibt Leute, die genau so leichtsinnig dachten, was kann bitte per E-Mail schon passieren, als sie vermeidlich harmlose Bildchen und Videos per E-Mail an alle rumschickten rumschickten (die mit Schadcode versehen waren). 🤦‍♂️

Dir ist klar und bekannt, daß wenn Du ein "Paket" installierst, im Hintergrund, ohne daß Du es mitbekommst, eine Menge passiert und passieren kann, incl. Konfigurationen, Kernelanpassungen etc? Schadcode wird darüber auch verbreitet:
https://kofler.info/infos-zur-arch-linux-attacke/
https://www.prosec-networks.com/blog/gefahr-aus-dem-code-manipulierte-open-source-pakete/
https://tuxcare.com/de/blog/mastra-npm-attack/

 

[AAS]

https://www.librechat.ai/de/docs/features/agents

LibreChat hat aus meiner Sicht die bessere Agentenintegration.
Hab meine Idee kurz durch Astra gejagt:

```text
LibreChat
│
├── Dev-Agent
│   ├── Git-MCP
│   ├── Files-MCP
│   └── Testserver-MCP
│
├── Test-Agent
│   ├── VM erstellen
│   ├── Code deployen
│   ├── Befehle ausführen
│   ├── Logs lesen
│   └── VM löschen
│
├── Infra-Agent
│   └── Proxmox-MCP
│
└── Reviewer-Agent
    ├── Git read-only
    └── Testserver read-only

          │
          ▼

     MCP-Gateway-VM
     ├── Proxmox API
     └── SSH

          │
          ▼

   Proxmox / Testserver


Der grosse Vorteil von LibreChat ist für mich die Agenten-Implementierung:

- Jeder Agent kann eigene MCP-Server und Tools bekommen.
- Rechte lassen sich dadurch viel sauberer trennen.
- Der Dev-Agent braucht z.B. keinen direkten Proxmox-Zugriff.
- Ein Reviewer kann nur lesen, ohne Shell-/Löschrechte.
- Verschiedene Modelle können dieselben Tools verwenden.
- Die Tool-Logik liegt nicht auf dem Ollama-Host.
- SSH bleibt nur der Transport im Hintergrund, das LLM sieht definierte Funktionen statt einer offenen Root-Shell.

Damit lässt sich ein Workflow wie

VM erstellen -> Branch deployen -> testen -> Logs analysieren -> Code ändern -> erneut testen -> VM löschen

deutlich sauberer abbilden als mit einem einzelnen Agenten, der einfach Terminalzugriff bekommt.
```

 

[GrumpyCat]

@speefak Ollama wegwerfen, llama.cpp oder vLLM nehmen. Tool-Server (Du meinst "MCP-Server", oder?) weglassen, stattdessen Skills nehmen (soweit möglich, kommt halt drauf an, für was genau Du das brauchst). Open WebUI und Open Terminal wegwerfen, stattdessen Pi oder Oh-my-pi nehmen (inkl. deren Webfrontend ggf.). Den ganzen Netzwerk-Routing-Krams wegwerfen, stattdessen den LLM-Server per HTTPS verfügbar machen und Passwort konfigurieren. Fäddisch, mit letztendlich nur zwei Komponenten.

DGX Spark? Wozu? Welches für Dich spannende LLM soll darauf laufen, das auf einer wesentlich günstigeren 32GB-GPU nicht (sogar schneller) laufen würde?

 

[AAS]

@GrumpyCat Bei Ollama/vLLM bin ich bei dir, je nach Hardware ist das klar schlanker.

Nur "MCP durch Skills ersetzen" sehe ich anders: Skills beschreiben eher Verhalten/Workflows, MCP stellt externe Fähigkeiten bereit. Für Proxmox, SSH, Logs, VM-Lifecycle etc. ist MCP weiterhin sinnvoll.

Pi/oh-my-pi finde ich für einen reinen Coding-/DevOps-Agenten tatsächlich spannender als Open WebUI/LibreChat.

Und den LLM-Server würde ich trotzdem hinter Reverse Proxy + Auth + Firewall hängen, nicht nur "HTTPS + Passwort", bei der Sicherheit sollte man nicht sparen.

 

[GrumpyCat]

Nur "MCP durch Skills ersetzen" sehe ich anders: Skills beschreiben eher Verhalten/Workflows, MCP stellt externe Fähigkeiten bereit.

Skills bringen ggf. eigene Tools/Skripte mit und lassen sich dank z.B. Piping vom LLM viel flexibler einsetzen. MCPs braucht man eigentlich nur wie Du schon richtig sagst für externe Dienste.

Und den LLM-Server würde ich trotzdem hinter Reverse Proxy + Auth + Firewall hängen, nicht nur "HTTPS + Passwort", bei der Sicherheit sollte man nicht sparen.

HTTPS und Passwort reicht für Banken. Wer das nicht sicher bekommt, sollte besser nicht "Sicherheit" durch das Auftürmen von Komponenten schaffen wollen, die kaum verstanden werden und ggf. ihre eigenen Probleme mitbringen oder nur ein irreführendes Gefühl von Sicherheit schaffen (VPNs sind in der Hinsicht ganz groß).

 

[AAS]

@GrumpyCat Sehe ich anders. Gerade wenn mehrere Benutzer oder Agenten im Spiel sind, finde ich einen Tool-/MCP-Server sinnvoll. Der Agent sollte nicht einfach eigene Credentials haben oder pauschal mit den Rechten seines Prozesses arbeiten. Der MCP-Server kann zentral prüfen, welcher Benutzer was darf und welche Aktion überhaupt freigegeben ist. Ein Skill kann natürlich Scripts und Tools mitbringen, aber die Rechtefrage ist damit ja nicht automatisch gelöst.

Dazu kommen noch ganz normale Betriebs-Themen: zentrales Zertifikatsmanagement, Auth, Logging, Containerisierung und wenn nötig horizontale Skalierung.
Klar, mehr Komponenten machen ein System nicht automatisch sicherer. Aber saubere Trennung von Zuständigkeiten ist für mich etwas anderes als unnötig Zeug aufzutürmen.

 

[GrumpyCat]

Aber saubere Trennung von Zuständigkeiten ist für mich etwas anderes als unnötig Zeug aufzutürmen.

Vielleicht haben wir uns da missverstanden, mit "Zeugs auftürmen" bezog ich mich insbesondere auf die VPN-Sachen. Es passiert einfach recht häufig, dass z.B. Leute ein VPN aufsetzen und die Services dahinter dann ohne Auth laufen "weil ja nur per VPN erreichbar".

 

[speefak]

Dem Agenten selbst Zugriff auf sein eigenes System zu geben, endet meiner Erfahrung nach meist irgendwann im Chaos. Ich hatte vor etwa sechs Monaten einige Tests mit OpenClaw gemacht. Als Erstes habe ich die Telegram-Verbindung aktiviert und OpenClaw anschließend eine Sprachnachricht geschickt. OpenClaw – ich glaube, mit Kimi K3 als LLM-Backend – fragte mich, ob es Sprachunterstützung installieren solle. Ich habe zugestimmt. Danach funktionierte zwar alles, aber OpenClaw hatte ungefähr dreimal so viele Daten installiert und heruntergeladen, wie notwendig gewesen wären, wenn ich die Installation selbst manuell durchgeführt hätte.

Genau aus diesem Grund gebe ich auf Produktivsystemen nur sehr ungern Schreibrechte an KI-Agenten. Ich kenne es vom Testen und Einrichten neuer Software nur zu gut: Irgendetwas funktioniert nicht, passt nicht zusammen oder eine Konfiguration geht schief. Das ist auf einem Testsystem ärgerlich, aber kein Drama. Blöd wird es, wenn das auf dem Produktivsystem passiert und anschließend nichts mehr funktioniert. Genau deshalb mache ich mir überhaupt die Arbeit mit separaten Testsystemen.

Gestern habe ich noch einmal intensiver zum Thema Toolserver recherchiert. ChatGPT möchte den Toolserver unbedingt in einer separaten VM sehen. Claude sieht das etwas anders und meint, der Toolserver könne durchaus auf dem Ollama-Server laufen, sofern ihm konsequent sämtliche Schreibrechte auf sein eigenes System entzogen werden. Wenn ich es richtig verstanden habe, brauche ich keinen Toolserver, wenn ich lediglich ein Terminal auf dem Testserver installiere und dort direkt arbeite.

Aber: Sobald KI-Agenten Testserver oder VMs über Proxmox verwalten sollen, brauche ich einen Toolserver beziehungsweise MCP-Server. Dort müssen dann die entsprechenden, kontrollierten Befehle hinterlegt sein, beispielsweise zum Erstellen, Starten, Stoppen, Verwalten und Löschen von VMs.

---

Kein System ist sicher.

Und das gilt für alles: VMs, KI, Betriebssysteme und jeden anderen Code.

Entweder wir lassen solche Systeme komplett sein – wie teilweise schon vorgeschlagen wurde – oder wir sorgen dafür, dass ein Angriff theoretisch zwar möglich bleibt, praktisch aber extrem unwahrscheinlich wird. Ich persönlich nehme das Restrisiko eines möglichen Ausbruchs einer KI aus einer VM in Kauf. Die Alternative wäre letztlich, jede KI auf eigener Hardware laufen zu lassen. So reich bin ich dann leider doch nicht – und nach der ersten Stromrechnung könnte ich vermutlich direkt Privatinsolvenz anmelden.

Auch eine KI mit Root-Rechten sehe ich als kalkulierbares Risiko, wenn diese Rechte nur gezielt und temporär für spezielle Testfälle verwendet werden. Root-Rechte für eine KI sind meiner Meinung nach nicht notwendig, damit ein Agent dauerhaft 24/7 produktiv arbeiten kann.

Wenn wir allerdings über Sicherheit reden, möchte ich auch noch einmal an die XZ-Kompromittierung erinnern. Das war meiner Meinung nach deutlich gefährlicher als vieles, was bisher unter dem Stichwort „KI läuft Amok“ diskutiert wurde. Der XZ-Angriff war ein Geniestreich sondergleichen. Um ein Haar – nur wenige Tage – wäre die manipulierte Software in einer enormen Zahl von Linux-Distributionen und möglicherweise weiteren Systemen gelandet. Die Auswirkungen hätten potenziell einen riesigen Teil der Internet-Infrastruktur und eingebetteter Systeme betreffen können.

Das zeigt für mich vor allem eines: Die größten Sicherheitsrisiken kommen nicht ausschließlich von KI.

---

Den ganzen Netzwerkrouting-Kram wegwerfen?​

Ganz ehrlich: Wie sichert man dann das Netzwerk ab? Soll die KI einfach im CoreLAN beziehungsweise Heimnetz frei schalten und walten dürfen? Da gruselt es mich ehrlich gesagt deutlich mehr. Gerade bei KI-Agenten halte ich eine konzeptionelle Sicherheitsarchitektur mit Netzwerksegmentierung für extrem wichtig. Es reicht nicht aus, nur die einzelnen Systeme abzusichern. Netzwerkrouting und Firewalls ermöglichen es, sehr genau zu steuern:

• Wer darf mit wem kommunizieren?
• Welche Systeme dürfen überhaupt erreicht werden?
• Welche Ports und Dienste sind erlaubt?
• In welche Richtung darf Traffic fließen?
• Welche Verbindungen sollen grundsätzlich verboten sein?

Ich würde KI-Agenten jedenfalls nur sehr ungern direkt in meinem CoreLAN betreiben.

Meine isoLAN_KI ist beispielsweise bewusst vom restlichen CoreLAN getrennt. Die KI-Systeme dürfen nicht einfach auf andere Systeme im Heimnetz zugreifen. Das Thema ist für mich auch nicht nur Theorie. Vor einigen Wochen kam bei mir zusätzlich ein VPN hinzu. Die Firewall-Regeln im isoLAN_KI blockierten ursprünglich den Traffic in das CoreLAN, aber nicht automatisch den Traffic in das neue VPN-Netz. Ohne einen obligatorischen Netzwerkscan wäre mir diese Lücke vermutlich gar nicht aufgefallen. Daraufhin habe ich den gesperrten IP-Bereich entsprechend erweitert – von einem /24 auf einen /16-Bereich.

Genau deshalb halte ich es für wichtig, Änderungen immer im Kontext des gesamten Netzwerks zu betrachten. Eine neue Verbindung oder ein neues Netzwerksegment kann bestehende Sicherheitsannahmen plötzlich verändern.

Und genau hier sehe ich einen wichtigen Unterschied zwischen einem Administrator und dem typischen „Ich probiere so lange herum, bis es irgendwie funktioniert“-Ansatz. Viele Anwender wissen schlicht nicht genau, was sie konfigurieren. Es wird so lange auf irgendwelche Optionen geklickt und herumprobiert, bis der Dienst funktioniert. Über Sicherheit wird dann häufig erst nachgedacht, wenn bereits etwas passiert ist. Besonders kritisch finde ich Konstruktionen wie:

„Der Dienst braucht keine Authentifizierung, der ist ja nur über VPN erreichbar.“

Das halte ich ebenfalls für grob fahrlässig. Ein VPN sollte eine zusätzliche Schutzschicht sein und nicht der einzige Sicherheitsmechanismus eines Dienstes.

---

Hardware: ML110 oder DGX Spark?​

Eine DGX Spark wäre für mich unter Umständen sogar günstiger als ein umfangreiches Upgrade meines ML110. Im ML110 kann ich aufgrund der Stromversorgung nur bestimmte PCIe-Grafikkarten sinnvoll einsetzen. Dadurch bleibt bei mir beispielsweise die RTX 2000 Ada mit 16 GB VRAM als interessante Option. Ein neuer Server würde mich dagegen schnell 3.000 bis 4.000 Euro kosten – und dabei wäre noch nicht einmal eine passende GPU enthalten.

Eine DGX Spark liegt ebenfalls in dieser Größenordnung. Sie ist möglicherweise langsamer als eine starke dedizierte GPU, bietet dafür aber einen anderen Vorteil: viel Speicher für größere Modelle und einen vergleichsweise sparsamen Betrieb. Für jemanden, dem Modellqualität und große Modelle wichtiger sind als maximale Geschwindigkeit, könnte das durchaus die bessere Lösung sein.

---

vLLM vs. Ollama​

Beim Vergleich scheint vLLM performanter zu sein als Ollama. Ich habe allerdings gerade erst Ollama als zentrale LLM-Instanz eingerichtet – mit lokalen und Cloud-Modellen. Deshalb steht ein Wechsel von Ollama auf vLLM bei mir momentan erst einmal hinten an. Das läuft jetzt, und bevor ich wieder die nächste Baustelle aufmache, möchte ich erst die bestehende Infrastruktur weiter ausbauen.

---

Warum ich MCP sinnvoll finde​

„Der Agent sollte nicht einfach eigene Credentials haben oder pauschal mit den Rechten seines Prozesses arbeiten. Der MCP-Server kann zentral prüfen, welcher Benutzer was darf und welche Aktion überhaupt freigegeben ist.“

Genau das ist einer der Gründe, warum ich auf einen MCP-Server setzen möchte. Dort lassen sich die Berechtigungen der KI-Agenten zentral konfigurieren. Die Agenten selbst können diese Rechte dann nicht einfach ändern. Das ist für mich deutlich besser, als sämtliche Berechtigungen ausschließlich auf dem KI-System selbst zu definieren. Denn wenn der Agent auf seinem eigenen System bereits weitreichende Rechte besitzt, kann er unter Umständen auch genau die Sicherheitsmechanismen verändern, die ihn eigentlich einschränken sollen. Ein zentraler Toolserver kann hier eine zusätzliche Kontrollinstanz sein.

Ich denke, ich werde auf einen Toolserver setzen – und zwar aus zwei Gründen:

1. Verwaltung von Diensten und Infrastruktur
2. Eine zusätzliche Sicherheitsebene

Der Toolserver kann als kontrollierte Schnittstelle zwischen dem KI-Agenten und der tatsächlichen Infrastruktur dienen. Dadurch lässt sich wesentlich genauer festlegen, welche Aktionen ein Agent überhaupt ausführen darf. Aktuell tendiere ich dazu, den MCP-Toolserver direkt auf dem Ollama-Server zu installieren, um mir eine zusätzliche VM zu sparen. Der Toolserver soll dabei selbst möglichst wenig können. Seine Aufgabe wäre im Wesentlichen das kontrollierte „Übersetzen“ von Tool-Calls der KI in klar definierte Aktionen beziehungsweise SSH-Verbindungen zu den Testservern. Der entscheidende Punkt ist für mich dabei:

Der KI-Agent bekommt nicht einfach freien Zugriff auf die Systeme. Er darf nur über definierte Tools und mit vorher festgelegten Berechtigungen bestimmte Aktionen ausführen.

Damit bleibt das Risiko natürlich bestehen – absolute Sicherheit gibt es nicht. Aber die Angriffsfläche und insbesondere der mögliche Schaden lassen sich meiner Meinung nach erheblich reduzieren.


LibreChat & Co. – Die Flut an neuen Tools
Die Entwicklung ist derzeit so schnell, dass ich täglich neue KI-Suits, Agenten oder UIs testen könnte. Mit OpenWebUI arbeite ich schon ein paar Wochen und habe mich in die GUI eingearbeitet. Jetzt direkt wieder mit etwas Neuem anzufangen? Ich bleibe vorerst bei Ollama + OpenWebUI. LibreChat und vLLM kommen später als Upgrades dran – in dem Sinne: Danke für die Infos! 😊

LibreChat scheint einen integrierten MCP-/Tool-Server zu haben. Für ein LibreChat-Single-Config-Setup mag das praktisch sein. Der Nachteil ist aber, dass der MCP-Server auf dem LibreChat-System läuft und keine eigenständige Instanz ist, mit der sich auch andere KI-Systeme verbinden können. Ein modularerer Aufbau hätte den Vorteil, dass sich einzelne Komponenten später einfacher austauschen lassen – z. B. Ollama durch vLLM ersetzen oder Open WebUI gegen LibreChat tauschen.