Ich habe einen KI-Agenten in meine Infrastruktur gelassen. Was es an Leitplanken braucht.
Auch auf Englisch verfügbar: I let an AI agent into my infrastructure. What it takes in guardrails.
TL;DR: Seit Monaten arbeitet ein KI-Agent in meiner Infrastruktur mit. Zwei echte Fehler sind passiert, beide hätten wehtun können, kaputt gegangen ist nichts. Das lag an der Reihenfolge: zuerst ein Gateway vor die Modelle, damit es einen einzigen Zugang gibt, dann Policies im Audit-Modus, bis sichtbar ist, was sie blockieren würden, dann scharf schalten, und erst danach den Agenten an die Arbeit lassen.
Angefangen hat es mit einer Frage, die mich nicht losgelassen hat: Wie weit komme ich eigentlich, wenn ich einen KI-Agenten in meine eigene Infrastruktur lasse? Nicht als Chat-Fenster nebenbei, sondern mitarbeitend, an Manifesten, an Konfiguration, an Dokumentation. Und wie führt man so etwas schrittweise ein, ohne eines Morgens vor einem Cluster zu stehen, der einem nicht mehr gehört?
Nebenbei liegt genau diese Frage in vielen Unternehmen ungeklärt herum: KI ist schneller als jede Freigabe, und niemand weiß genau, womit die Leute arbeiten. Mich hat aber zuerst die Neugier getrieben, ausprobieren, was möglich ist.
Mein Testlabor im Keller
In meinem Keller steht mein Testlabor: eine Handvoll Mini-PCs, ein NAS, eine USV, Solarstrom. Das ist mein Labor für eigene Experimente. Ich probiere Muster hier aus, bevor ich sie irgendwo anders vorschlage, und wenn etwas umfällt, dann fällt es bei mir um.
Zwei Fragen haben mich interessiert. Tragen die Prinzipien, die man in großen Projekten predigt, auch im Kleinen? Und kann ein KI-Agent in der Infrastruktur ernsthaft mitarbeiten, ohne dass ich nachts schlecht schlafe? Nach einigen Monaten würde ich bei beidem ja sagen. Allerdings nur, weil ich ihm von Anfang an Grenzen gesetzt habe.
Die Architektur
Die Basis ist ein Proxmox-Cluster mit sechs Knoten und einem hochverfügbaren k3s-Cluster darauf. Alles ist deklarativ in Git beschrieben und wird über ArgoCD angewendet. Niemand ändert den Cluster direkt, ich auch nicht. Speicher und Backups liefert das NAS, eine Kopie liegt zusätzlich offsite in der Cloud, aus demselben Grund, aus dem die Secrets extern liegen: Was ich zum Wiederaufbau brauche, darf nicht in dem Ding liegen, das gerade weg ist.
Die Modelle laufen lokal mit Ollama. Kleine Modelle bis etwa 8 Milliarden Parameter auf einem ganz normalen Mini-PC, größere auf einem eigenen GPU-Knoten mit NVIDIA RTX 5060 Ti (16 GB) und GTX 1660 Super (6 GB). Einen Teil des Stroms liefert die eigene Solaranlage, denn Rechenleistung im Keller soll möglichst wenig Umwelt kosten.
Governance: ein Gateway, klare Policies
Kein Dienst spricht direkt mit einem Modell. Alles läuft über LiteLLM als einziges Gateway, der direkte Zugriff auf Ollama ist per Kyverno-Policy gesperrt. Kyverno prüft jede Ressource, bevor sie in den Cluster kommt, und lehnt ab, was nicht passt.
Der Nutzen ist banal und genau deshalb groß: Ich entscheide an einer Stelle, welche Modelle es gibt und wer sie nutzen darf. Jeder Dienst hat einen eigenen Schlüssel. Der Chat-Bot fürs Funknetz bekommt ein kleines Chat-Modell, die Workflow-Automation nur Embeddings und Extraktion. Und ich sehe, wer wie viel verbraucht, ohne Logs aus fünf Diensten zusammenzusuchen.
Das Gateway kann beides: lokale Rechenleistung im Keller und, wenn eine Aufgabe es verlangt, die APIs der großen Frontier-Modelle. Gleiche Leitplanken, gleicher Zugang, nur ein anderer Weg dahinter. Beim Umstellen gilt eine Regel, die ich jedem empfehle: Es wechselt nur der Transportweg, nie gleichzeitig das Modell.
Die Policies laufen größtenteils noch im Audit-Modus und melden nur, was sie blockieren würden. Scharf geschaltet wird erst, wenn sie nichts Legitimes brechen. Ein Detail, das ich vorher nicht wusste: Generate-Regeln wirken auch im Audit-Modus, die Sperre für den direkten Modellzugriff greift also schon jetzt.
Secrets: bewusst extern
Secrets liegen im Bitwarden Secrets Manager, angebunden über den External Secrets Operator. In einem sonst lokalen Setup ist das Absicht. Ein Secrets Manager im Cluster hängt vom Cluster ab, und genau dann, wenn ich das Rechenzentrum neu aufbauen muss, brauche ich die Secrets zuerst. Die Abhängigkeit ist kleiner, als sie klingt: Die Werte landen als normale Kubernetes-Secrets im Cluster, laufende Dienste arbeiten also auch bei einem kurzen Ausfall weiter.
Ein KI-Agent im Infrastrukturbetrieb
Der Agent ist Claude Code. Er schreibt Manifeste, Ansible-Rollen und OpenTofu-Code, sucht Fehler und dokumentiert, immer in Phasen: ein Block, ein Bericht, ich lese, entscheide und gebe das Go für den nächsten Schritt. Das klingt umständlicher, als es sich anfühlt.
Schönes Beispiel ist NetBox, das ich als Source of Truth für Netzwerk und Hardware einführe. Das Inventar von Hand zu tippen hätte mich Abende gekostet. Der Agent hat Dokumentation, OpenTofu-State und laufende Systeme ausgewertet, ich habe geprüft und korrigiert.
Wo der Agent danebenlag
Zwei Fehler habe ich mir gemerkt, weil sie mehr über die Zusammenarbeit sagen als jede Erfolgsmeldung.
Der Schlüssel im Bericht. Nach der ersten Migrationsphase stand mitten in einem sauberen Bericht der Virtual Key von n8n im Klartext. Nur intern erreichbar, also kein Drama, aber er galt für alle Modelle. Ich habe ihn neu erzeugt und dem Agenten die Ausgabe von Secret-Werten verboten. Das reichte mir nicht: Eine Regel, die er einhalten muss, ist schwächer als eine, die er nicht brechen kann. Die Bitwarden-Migration ist deshalb so gebaut, dass er die Werte nie zu sehen bekommt.
Die DNS-Falle. Dem Agenten fiel auf, dass volle Service-Namen im Cluster beim Ingress statt beim Dienst landen. Er hat das sauber dokumentiert und kurze Namen als Workaround genutzt. Gut gefunden, aber falsch gewichtet: Genau die kritischen Stellen nutzten volle Namen, die Tunnel für alle öffentlichen Seiten und das Single Sign-on. Es lief nur, weil die Pods älter waren als die DNS-Änderung. Ein Stromausfall hätte alles auf einmal lahmgelegt.
Beim Finden ist der Agent stark, manchmal stärker als ich. Abzuschätzen, was im schlimmsten Fall daran hängt, bleibt meine Aufgabe.
Sicherheit: was trägt, und was ich offen lasse
Ein Agent liest, was ihm vor die Nase kommt: Dokumentation, Dateien im Repository, Webseiten, Ausgaben von Werkzeugen. In so einem Text kann ein Satz stehen, der aussieht wie eine Anweisung, aber nicht von mir stammt. Der Fachbegriff dafür ist Prompt Injection, und er steht bei OWASP auf Platz 1 der Risiken für LLM-Anwendungen. Ein Restrisiko bleibt. Bessere Prompts lösen das nicht, die Sicherheit muss aus der Architektur kommen.
Was deshalb bei mir im Einsatz ist: ein eigener Benutzer ohne Sonderrechte. Zugang zu Secrets Manager und Ansible nur über vorbereitete Wrapper-Scripts. Keine direkten Cluster-Änderungen, nur Git und ArgoCD, jeder Schritt versioniert und per Revert umkehrbar. Kyverno prüft unabhängig davon, wer ein Manifest geschrieben hat. Dazu das Phasenmodell: Ich gebe frei, ich lese die Berichte, Berechtigungen für Befehle erteile ich einzeln.
Eine Grenze gehört offen gesagt: Der Agent selbst ist ein Cloud-Dienst, sein Kontext aus gelesenen Dateien und Ausgaben verlässt das Haus. Datenhoheit gilt für die lokalen Modelle. Nicht für den Agenten, und nicht für Anfragen, die über das Gateway an Frontier-APIs gehen. Wer das vermischt, verkauft eine Sicherheit, die es nicht gibt.
Observability: so gehe ich es an. Nachvollziehbar soll das in drei Schichten werden. Erstens Git und ArgoCD: Jede Änderung des Agenten ist ein Commit mit Verweis auf die Sitzung, und ArgoCD zeigt, was davon wirklich im Cluster angekommen ist. Zweitens die Metriken des Gateways: LiteLLM sieht jede Modellanfrage mit Schlüssel, Modell und Tokens. Das will ich mit Prometheus und Grafana auswerten, das bei mir für Strom und USV schon läuft, und über Budgets und Limits pro Schlüssel Alarm geben lassen, wenn etwas auffällt. Drittens das Audit-Log des Clusters zusammen mit den Policy-Reports von Kyverno in einem zentralen Log-Ziel. Was dann noch fehlt, ist der Blick in den Agenten selbst. Als Nächstes habe ich deshalb einen Hook vor, der jeden Tool-Aufruf in ein Log schreibt, das der Agent nicht ändern darf.
Hier will ich noch genauer hinsehen:
- ein formales Bedrohungsmodell aufschreiben
- systematisch auf Prompt Injection testen, am besten von außen
- Wrapper-Scripts und Sudo-Rechte unabhängig prüfen lassen
- ausgehenden Netzverkehr des Agenten begrenzen
- diese drei Observability-Schichten einrichten und testen, Alarmregeln inklusive
- rechtliche Einordnung und Datenschutz, mit Fachleuten
Was ich daraus mitnehme
Die Reihenfolge war das Entscheidende. Zuerst ein Gateway, dann die Nachvollziehbarkeit über Git und die Logs des Gateways, dann die Policies scharf, und erst danach ein Agent, der mitarbeitet. Wer die Schritte tauscht, stellt später jeden Dienst einzeln um und ärgert sich. Das habe ich selbst erlebt.
Genauso wichtig ist, die Grenzen laut zu sagen. Lokal läuft lokal, alles was über das Gateway zu einer Cloud-API geht, verlässt das Haus. Wer eine Freigabe erteilt, muss diese Linie kennen, sonst ist Datenhoheit nur ein Wort auf einer Folie. Dass dasselbe Gateway Anwendungen von Modellen entkoppelt und mich aus dem Lock-in heraushält, nehme ich gern als Beigabe, war aber nie der Hauptgrund. Und dass protokollierte Zugriffe die Grundlage für Nachweise sind, nach denen auch der EU AI Act fragt, nenne ich und überlasse es dann Fachleuten. Rechtsberatung ist das hier nicht.
Einen Agenten behandle ich inzwischen wie einen neuen Kollegen von außen: eigener Zugang, nur die nötigen Rechte, alles nachvollziehbar. Er arbeitet schneller als ich und macht deshalb auch schneller Fehler.
Wenn Sie es schon hinter sich haben: Mich interessiert vor allem, wo es bei Ihnen geknirscht hat.
Quellen und weiterführende Links
- LiteLLM Proxy: OpenAI-kompatibles Gateway vor beliebigen Sprachmodellen
- Ollama: Laufzeitumgebung für lokale Sprachmodelle
- Kyverno: Policy-Engine für Kubernetes
- Argo CD: GitOps-Abgleich zwischen Git und Cluster
- External Secrets Operator: Bitwarden-Provider: Secrets Manager an Kubernetes anbinden
- Claude Code: der KI-Agent, mit dem ich gearbeitet habe
- Prompt Injection (OWASP): Risikobeschreibung und Gegenmaßnahmen
- Simon Willison: Prompt-Injection-Reihe: ausführliche Fachartikel zum Thema
Transparenz: Dieser Beitrag entstand mit KI-Unterstützung. Ich habe ihn geprüft und verantworte den Inhalt. Mehr dazu unter KI-Transparenz.