Ein Monitoring-System kann völlig korrekt arbeiten und trotzdem schlechte Nachrichten produzieren. Ein Storage-Problem wird zu mehreren Volume-Alerts, daraus werden Pod-Probleme, und am Ende meldet sich noch ein Dienst, dessen Abhängigkeit gerade fehlt. Jede einzelne Meldung stimmt. Zusammen beantworten sie aber noch nicht die wichtigste Frage: Was ist passiert, und was muss ich jetzt entscheiden?
An dieser Stelle sitzt ZeroClaw in meinem Lab. Nicht als zusätzlicher Controller, der Deployments repariert, sondern als Alert-Gate und lesender Triage-Assistent: Zustand abfragen, zusammengehörige Symptome einordnen, bekannte Meldungen zurückhalten und bei neuen relevanten Vorfällen eine verständliche Zusammenfassung liefern.
Das klingt einfach. Die interessanten Fragen beginnen bei den Grenzen: Wer darf die Daten lesen? Wer darf etwas verändern? Und was passiert, wenn ausgerechnet der Assistent schweigt?
Was sich gegenüber den früheren Beiträgen geändert hat#
In der ersten Vorstellung ging es vor allem um die Integration eines Agenten in das GitOps-Lab. Der Migrationsbeitrag beschrieb anschließend Runtime- und Parserprobleme. Dieser Artikel ist kein weiteres Versionsprotokoll, sondern der aktuelle Betriebsschnitt Anfang Oktober 2026.
Drei Dinge stehen heute stärker im Mittelpunkt:
- Die Diagnose bekommt eine eigene Kubernetes-Identität mit lesenden Rechten. Sie hat keine vorgesehenen Schreibrechte auf Workloads und keine Leserechte auf Core-Secrets.
- Benachrichtigungen werden gezielt gefiltert. Ein regelmäßig laufender Agent fragt Alerts ab, statt jede Meldung direkt nach Matrix durchzureichen.
- Der Agent bekommt keinen SOPS-Schlüssel für die Repository-Secrets. Die Entschlüsselung beim Deployment bleibt Aufgabe von Flux.
Ältere Diagramme mit anderen Zugangspfaden oder einem eingebundenen SOPS-Key beschreiben deshalb nicht mehr diesen Stand. Ebenso wenig sollte man frühere Ideen zu automatisierten Wartungsjobs mit dem heutigen, enger beschriebenen Auftrag gleichsetzen.
Ein Alert-Gate ist kein weiterer Messwertlieferant#
Prometheus und die übrigen Monitoring-Komponenten entscheiden weiterhin, ob eine Regel feuert. ZeroClaw soll diese Messung nicht durch ein Sprachmodell ersetzen.
Die Arbeitsteilung lautet:
| Ebene | Aufgabe |
|---|---|
| Exporter, Probes und Logs | Beobachtungen erzeugen |
| Prometheus beziehungsweise Loki-Regeln | Aus Beobachtungen Alerts ableiten |
| Alertmanager | Aktive Alerts sowie Silence-/Inhibition-Zustand bereitstellen |
| ZeroClaw | Relevanz einordnen, Symptome bündeln, lesend nachsehen |
| Mensch | Entscheidung treffen, vorgeschlagene Änderung prüfen |
| Git und Flux | Freigegebenen gewünschten Zustand ausrollen |
Das Modell soll nicht aus einer alten Logzeile einen aktuellen Ausfall erfinden. Für den Sweep zählt die gegenwärtig aktive Alertliste, ohne stummgeschaltete oder inhibierte Einträge. Schon behobene Meldungen sind kein Anlass für einen verspäteten dramatischen Bericht.
Der Unterschied ist wichtig: Ein LLM kann bei der Interpretation helfen. Es darf nicht still die Quelle der Wahrheit darüber werden, ob ein Alert überhaupt noch existiert.
Der aktuelle Datenpfad ist Pull, nicht Push#
Im Lab fragt ZeroClaw den Alertmanager selbst ab. Der Zugang läuft über den Kubernetes-API-Proxy und die lesende Monitoring-Identität. Damit muss die Alertmanager-Oberfläche für diesen Zweck nicht zusätzlich öffentlich erreichbar sein.
Die aktive Alertmanager-Konfiguration routet Benachrichtigungen nach null. Der frühere direkte Matrix-Receiver ist nicht aktiv. Das betrifft auch Critical-Alerts; es gibt derzeit keinen separaten Critical-Bypass, der den Agenten überspringt.
Und der Sweep läuft nicht alle fünf Minuten, sondern stündlich zur Minute 15:
1[cron.alert_sweep.schedule]
2expr = "15 * * * *"
3kind = "cron"
4tz = "Europe/Berlin"
Das ist der konfigurierte Zeitplan, keine garantierte maximale Reaktionszeit. Scheduler-Verzögerung, Modellaufrufe, API-Zugriff und Zustellung kommen dazu. Ein Alert direkt nach einem Sweep wartet zunächst auf den nächsten Lauf; ein kurzlebiger Alert kann zwischen zwei Abfragen bereits wieder verschwunden sein.
Diese Einschränkung gehört für mich zur Beschreibung der Architektur, nicht in eine Fußnote hinter einem großen „AI Operations“-Versprechen.
Was der Sweep entscheiden soll#
Der konfigurierte Auftrag ordnet die Severity-Labels fest zu:
| Alert-Label | Triage-Stufe | Erwartetes Verhalten |
|---|---|---|
critical | P1 | Einen neuen aktiven Vorfall melden |
warning | P2 | Neue oder sich ausbreitende Vorfälle melden; Bekanntes bündeln |
info | P3 | Dokumentieren und später zusammenfassen, keine unmittelbare Meldung |
Eine spektakuläre Zahl soll diese Einordnung nicht eigenmächtig verändern. Wenn eine Regel beispielsweise einen Informationshinweis liefert, soll daraus nicht allein wegen einer großen Prozentzahl ein P1 werden. Ist die Regel fachlich falsch eingestuft, gehört ihre Severity überprüft, statt die Alarmierungslogik bei jeder Antwort neu zu erfinden.
Dazu kommen drei Verhaltensregeln:
- zusammengehörige Alerts zu einem Vorfall gruppieren;
- anhand von Cluster und Alertname gegen bereits bekannte Meldungen abgleichen;
- jeden triagierten Vorfall in einem monatlichen Incidentlog notieren.
Wenn keine neue handlungsrelevante Meldung entsteht, lautet die Antwort NO_REPLY. Kein „Sweep erfolgreich“, kein „alles ruhig“, kein Statusbericht nur deshalb, weil ein Cron gelaufen ist.
Das Ziel ist nicht maximale Aktivität im Chat. Das Ziel ist, dass eine neue Nachricht Aufmerksamkeit verdient.
Wichtig: Das ist ein Auftrag, kein bewiesener Algorithmus#
Die Gruppierung und Deduplikation sind im derzeitigen Aufbau Modellanweisungen. Der öffentliche Lab-Stand definiert dafür keinen separaten deterministischen Incident-Controller mit atomaren Zustandsübergängen, festem Dedupe-Fenster und quittierter Exactly-once-Zustellung.
Auch der Dateiname eines Incidentlogs macht daraus noch keine transaktionale Queue. Die Matrix-Auslieferung steht ausdrücklich auf best_effort.
Ich beschreibe daher, was der Agent tun soll, nicht eine mathematische Garantie, dass derselbe Vorfall nie zweimal erscheint oder keine Meldung verloren geht. Für belastbare Zustellsemantik wäre eine zusätzliche deterministische Schicht nötig.
Ein brauchbarer Triage-Bericht trennt Befund und Hypothese#
Nehmen wir ein bewusst erfundenes Beispiel: Eine Anwendung ist nicht verfügbar, mehrere Pods warten auf Volumes, und gleichzeitig gibt es einen Storage-Alert.
Eine schlechte Zusammenfassung wäre:
Storage kaputt. Ich starte die Pods neu.
Eine hilfreiche Triage würde dagegen so aussehen:
1Befund:
2Mehrere Workloads warten auf ihre Volumes; ein Storage-Alert ist aktiv.
3
4Zusammenhang:
5Die Anwendungsfehler könnten eine Folge der Storage-Störung sein.
6Einzelne Pod-Neustarts beheben deren Ursache nicht.
7
8Nächste Prüfung:
9Volume-/CSI-Events und den Zustand der betroffenen Storage-Komponenten prüfen.
10
11Entscheidung:
12Keine automatische Reparatur. Befunde bestätigen, dann gezielt eingreifen.
Das ist ein Qualitätsmaßstab für die Ausgabe, kein mitgeschnittener Vorfall und keine gemessene Modellleistung. Entscheidend ist die Trennung: Was wurde wirklich abgefragt? Was ist daraus abgeleitet? Welche konkurrierende Erklärung bleibt möglich?
Ein Tool-Aufruf ohne hilfreiches Ergebnis darf nicht durch eine selbstsichere Behauptung ersetzt werden. Genau an dieser Stelle hatte der frühere Betrieb bereits gezeigt, dass Modellwahl und korrektes Tool-Parsing praktische Betriebsfragen sind, keine austauschbaren Details.
Die harte Grenze liegt an der Identität#
Der Diagnosezugang verwendet ein eigenes kubeconfig mit ServiceAccount-Token statt eines administrativen Clientzertifikats. Die vorgesehene Rolle kombiniert Kubernetes view mit gezielten Erweiterungen, etwa für Nodes, PersistentVolumes, Plattform-CRDs und lesende Service-Proxy-Abfragen.
Damit kann der Agent die Fragen beantworten, die bei Triage tatsächlich auftauchen:
- Welcher Workload ist nicht bereit?
- Was melden Events und zugängliche Logs?
- Welcher Flux-Reconcile hängt?
- Was sagen Datenbank-, Storage- oder Netzwerk-Conditions?
- Welche Alerts sind gerade aktiv?
Die Monitoring-Rolle enthält keine Mutationsverben und keine Core-Secret-Freigabe. Ein geplanter Deployment-Patch oder ein gewöhnliches kubectl exec gehört nicht zu diesem Diagnosezugang.
Eine schematische Zusatzregel sieht beispielsweise so aus:
1# Ausschnitt, nicht die vollständige Rolle
2rules:
3 - apiGroups: [""]
4 resources: [nodes, persistentvolumes]
5 verbs: [get, list, watch]
6 - apiGroups: [""]
7 resources: [services/proxy]
8 verbs: [get]
Das ist wesentlich belastbarer als die Anweisung „Bitte keine Veränderungen vornehmen“. Der API-Server entscheidet anhand der verwendeten Identität, nicht anhand der Absicht des Modells.
Trotzdem ist das keine perfekt minimale Monitoring-Rolle. Der Service-Proxy-Zugriff ist nicht nur auf Prometheus und Alertmanager begrenzt; mehrere Nicht-Core-API-Gruppen sind breit lesbar. Außerdem ist view aggregierbar. Nach Änderungen an Rollen und CRDs muss deshalb erneut geprüft werden, welche effektiven Rechte entstehen.
„Keine Secret-Leserechte“ braucht einen präzisen Geltungsbereich#
Die Aussage gilt für die dedizierte Monitoring-Identität. Sie bedeutet nicht, dass der gesamte ZeroClaw-Pod keine Zugangsdaten besitzt oder keinerlei Kubernetes-Schreibrechte haben kann.
Die Runtime braucht eigene Credentials: für Matrix, die Modellanbieter und ihre weiteren Integrationen. Daneben hat der Tailscale-Sidecar eine separate Pod-Identität, um seinen Zustand zu speichern. Deren aktuelle Role darf Secrets im eigenen Namespace anlegen, lesen und aktualisieren; sie ist breiter als der eine benötigte Zustandsspeicher.
Die öffentlichen Manifeste belegen damit gerade keine vollständige Secret-Isolation der gesamten Agentenlaufzeit. Ob und wie konkrete Agententools diese zweite Identität erreichen können, ist damit noch nicht als Laufzeitverhalten getestet. Eine technische Trennung, die das Token ausschließlich dem Sidecar vorbehält, sollte man aus der bloßen Containeraufteilung aber nicht ableiten.
Das ist eine verbleibende Härtungsaufgabe, kein Grund, die lesende Monitoring-Rolle wertlos zu nennen. Es ist der Unterschied zwischen zwei korrekten Aussagen:
- „Für Diagnose ist eine Identität ohne Secret-Leserechte vorgesehen.“
- „Die gesamte Runtime ist gegenüber sämtlichen Secrets technisch abgeschottet.“
Die erste ist belegt. Die zweite wäre zu stark.
Ebenso können Logs, ConfigMaps oder Custom Resources versehentlich vertrauliche Werte enthalten. Keine Secret-API lesen zu dürfen macht den restlichen Clusterzustand nicht automatisch öffentlich. Gerade ein Assistent, der Text an einen Modellanbieter sendet, braucht deshalb eine bewusst begrenzte Datenweitergabe.
Shell-Autonomie ist nicht Cluster-Autonomie#
ZeroClaw bekommt eine weitgehend freie Shell für Analyse und Git-Arbeit. Pipes, Subshells und Werkzeuge gehören zum vorgesehenen Ablauf. Eine bloße Liste „harmloser Befehle“ wäre ohnehin keine robuste Autorisierungsgrenze.
Die gewünschte Sicherheitskonstruktion ist deshalb: Werkzeuge dürfen analysieren; die Diagnose-Credentials begrenzen den API-Zugriff. Promptregeln legen zusätzlich fest, dass der Bot keine Reparatur ausführt. Sie ersetzen jedoch weder RBAC noch die Prüfung anderer erreichbarer Credentials.
Auch „schreibgeschützt“ muss man sauber formulieren. Der Agent darf selbstverständlich Incident-Notizen schreiben, seinen Workspace bearbeiten, Matrix-Nachrichten senden und Änderungen als Radicle-Patch vorschlagen. Verboten beziehungsweise nicht vorgesehen ist die unmittelbare Reparatur des Clusterzustands über seine Monitoring-Identität.
Für den regulären Änderungsweg bleibt es bei:
1Diagnose → Änderungsvorschlag → menschliches Review → Merge → Flux
Der Agent soll nicht auf main durchregieren. Ein brauchbarer Patch kann Arbeit sparen; seine fachliche Prüfung spart er nicht ein.
Netzwerkzugang und API-Recht sind zwei verschiedene Prüfungen#
Der vorgesehene Kubernetes-Pfad führt über einen Userspace-Tailscale-Sidecar und den nativen tailnet-operator-Ingress . Das kubeconfig nutzt einen verifizierten TLS-Namen, die Cluster-CA und den vorgesehenen SOCKS5-Pfad.
Damit sind mehrere Fragen unabhängig voneinander beantwortet:
- Darf die Bot-Identität den API-Eingang im Tailnet erreichen?
- Ist der TLS-Endpunkt tatsächlich der erwartete?
- Welche Kubernetes-Aktionen erlaubt das Token?
Ein vorhandenes Credential reicht ohne Netzwerkfreigabe nicht aus. Das zeigt auch Talos: Ein älterer lesender Zugang ist noch eingebunden, der aktuelle Tailnet-Ingress erlaubt dem Bot aber keinen Talos-Zugriff.
Umgekehrt machen Tailnet-Regeln nicht automatisch alle direkten Pod-Netzwerkpfade sicher. Im ZeroClaw-Namespace ist derzeit keine eigene NetworkPolicy deklariert. „Er erreicht die API über das Tailnet“ ist deshalb nicht gleichbedeutend mit „sämtlicher anderer Egress ist technisch unmöglich“.
Diese Unterscheidung ist für die Sicherheitsbewertung nützlicher als ein pauschales Etikett wie „sandboxed“.
Wer bemerkt, dass die Triage blind ist?#
Der Sweep erwartet in jedem erreichbaren Cluster den dauerhaft feuernden Watchdog. Scheitert die Alertmanager-Abfrage oder fehlt dieser Eintrag, soll ZeroClaw einen P1 über verlorene Monitoring-Sicht melden. Eine leere Liste darf nicht einfach als „gesund“ gelten.
Das hat jedoch eine wichtige Grenze: Bereits als unerreichbar ausgesonderte Cluster soll der aktuelle Prompt still überspringen. Außerdem kann der Bot einen eigenen vollständigen Ausfall nicht zuverlässig über genau denselben ausgefallenen Bot-Pfad melden.
Deshalb gibt es zusätzlich einen externen Monitoring-Deadman. Ein separater CronJob prüft Prometheus, den Watchdog und Alertmanager-Readiness und sendet nur bei Erfolg ein Lebenszeichen an Healthchecks.io außerhalb des Clusters.
Der externe Check hilft bei Cluster- oder Monitoring-Ausfällen. Er prüft aber nicht, ob ZeroClaw den letzten Sweep korrekt ausgeführt, ein Modell geantwortet oder Matrix die Nachricht zugestellt hat. Ein grüner Deadman ist somit kein Beweis für einen funktionierenden vollständigen Alert-Gate-Pfad.
Der interne ZeroClaw-Heartbeat ist wiederum eine zusätzliche Selbstbeobachtung, kein unabhängiger Ersatzkanal. Unabhängigkeit entsteht nicht dadurch, dass zwei Jobs verschieden heißen, wenn beide denselben Agenten und dieselbe Zustellung benötigen.
Modelle und Kosten: begrenzen statt auf Vernunft hoffen#
Der aktuelle Standard- und Monitoringpfad verwendet Ollama Cloud mit kimi-k2.6:cloud. Als terminaler Fallback ist ein Codex-Pfad konfiguriert. Das erhöht die Chance, dass ein einzelnes Providerproblem nicht jede Analyse beendet; es löst keine Ausfälle von Kubernetes-Zugang, Scheduler oder Matrix.
Die Runtime hat Grenzen für Kontext, Ausgabe, Tool-Iterationen und Aktionen pro Stunde. Hinzu kommen virtuelle Kostenbudgets mit Blockierung, wenn die lokale Rechnung ihr Limit erreicht.
„Virtuell“ ist dabei wichtig: Die Zähler verwenden hinterlegte Preise als Begrenzungsmechanismus. Sie sind weder eine Live-Abrechnung der Provider noch ein Nachweis dafür, welche Subscription-Kontingente tatsächlich noch frei sind.
Für mich ist der Nutzen dieser Limits vor allem operativ. Ein Assistent soll sich nicht in einer Wiederholung aus Abfrage, Neuformulierung und nächster Abfrage verlieren, nur weil er noch keine sichere Diagnose gefunden hat. Irgendwann muss das korrekte Ergebnis lauten: Die vorhandenen Befunde reichen nicht; ein Mensch muss entscheiden.
Was sich ohne Live-Zugriff überprüfen lässt#
Das Lab enthält Regressionstests für die Zusatzrolle und den kubeconfig-Generator. Sie prüfen unter anderem unzulässige Verben, Secret-Freigaben, unerwünschte Wildcards sowie falsche Endpunkte, Proxys und deaktivierte TLS-Prüfung.
Das ist wertvoll, weil ein vermeintlich kleiner RBAC- oder Zugangsumbau damit sichtbar scheitern kann. Es ist aber kein vollständiges Sicherheitszertifikat: Die Tests dieser Diagnose-Identität beweisen weder sämtliche aggregierten Clusterrechte noch die Isolation der separaten Pod-Identität.
Ebenso müsste ein echter Zustelltest einen definierten Vorfall durch den gesamten Pfad verfolgen: Alert aktiv, Sweep ausgeführt, Analyse abgeschlossen, Nachricht angekommen. Ein sauber gerendertes TOML beweist nur, dass die gewünschte Konfiguration existiert.
Fazit: weniger Entscheidungen automatisieren, mehr Entscheidungen vorbereiten#
Der sinnvolle Platz für ZeroClaw ist für mich zwischen Rohsignal und menschlicher Entscheidung. Dort kann ein Agent Zusammenhänge herausarbeiten, redundante Meldungen bündeln und den nächsten Untersuchungsschritt vorbereiten, ohne selbst die Plattform zu reparieren.
Die lesende Monitoring-Identität und der Verzicht auf einen SOPS-Key sind dafür wichtige Grenzen. Sie machen aber weder die gesamte Runtime secretfrei noch den promptgesteuerten Alert-Pfad zu einem zuverlässigen Pager. Die breitere Sidecar-Berechtigung, die stündliche Abfrage und der fehlende unabhängige Critical-Bypass bleiben Teil des aktuellen Bildes.
Gerade deshalb halte ich den Ansatz für interessant: nicht als Vorführung eines allmächtigen Cluster-Bots, sondern als Versuch, Urteilsarbeit gezielt zu unterstützen und operative Autorität bewusst getrennt zu halten. Ein guter Assistent nimmt mir nicht die letzte Entscheidung ab. Er sorgt dafür, dass ich sie mit besseren Befunden treffe.
Quellenstand: öffentliche Lab-Konfiguration Anfang Oktober 2026. Maßgeblich sind docs/ZEROCLAW.md, zeroclaw.toml, die Alertmanager-Konfiguration, Monitoring-RBAC und Pod-Rollen im Lab-Repository
. Die Aussagen beschreiben Konfiguration und ihre Grenzen, keine während des Schreibens durchgeführte Live-Sicherheitsprüfung.