Observability für KI-Agenten: Überwachen, was Sie nicht sehen können

Anthropic hat in Claude Desktop eine Funktion namens Cowork ausgeliefert. Diese Funktion legte bei jeder macOS-Installation ein 10 GB großes Bundle für eine virtuelle Maschine an. Auch Benutzer, die Cowork nie aktiviert hatten, bekamen die VM. Wer sie löschte, sah zu, wie sie sich neu erzeugte. Ein Benutzer berichtete von einem Bundle, das auf 21 GB anwuchs. Das GitHub-Issue sammelte 345 Punkte und 175 Kommentare auf Hacker News, bevor Anthropic das Problem einräumte.¹

Niemand bemerkte es, bis der Speicherplatz ausging.

Was ist Observability für KI-Agenten? Agenten-Observability ist die Praxis, zu überwachen, was autonome Agenten zur Laufzeit verbrauchen und ausführen. Sie erfordert drei Ebenen: Ressourcenmessung (Speicherplatz, Arbeitsspeicher, CPU, Netzwerk pro Sitzung), Richtliniendurchsetzung (Erlauben-/Verweigern-Regeln bei jedem Tool-Aufruf) und Laufzeit-Auditing (Aufzeichnung des tatsächlichen Verhaltens auf Kernel-Ebene). Ohne alle drei können Betreiber keine Drift erkennen, keinen Geltungsbereich durchsetzen und keine Vorfälle rekonstruieren.

TL;DR

Agenten-Tools belegen inzwischen Rechenressourcen (Speicherplatz, Arbeitsspeicher, CPU, Netzwerk), ohne dass Betreiber davon etwas sehen. Die Cowork-VM von Anthropic ist das sichtbare Beispiel; jeder MCP-Tool-Aufruf, jeder gestartete Sub-Agent und jeder Web-Abruf ist ein unsichtbares. Agenten zu steuern erfordert drei Ebenen der Observability: Ressourcenmessung (Was hat er verbraucht?), Richtliniendurchsetzung (Was durfte er tun?) und Laufzeit-Auditing (Was hat er tatsächlich getan?). Zwei Open-Source-Projekte decken die Richtlinien- und die Audit-Ebene ab (mcp-firewall und Logira), aber kein produktionsreifes Tool deckt alle drei ab. Im Folgenden: das Sichtbarkeitsproblem, der dreischichtige Stack, was jede Ebene erfasst, und minimale Monitoring-Hooks, die Sie heute umsetzen können.

Das Sichtbarkeitsproblem

Klassische Software arbeitet unterhalb einer Observability-Linie, die Betreiber selbst ziehen. Ein Webserver schreibt Access-Logs, weil Entwickler das Logging konfiguriert haben. Eine Datenbank protokolliert langsame Abfragen, weil jemand log_min_duration_statement gesetzt hat. Über die Granularität entscheidet der Betreiber.

Agentensysteme kehren dieses Verhältnis um. Der Agent entscheidet zur Laufzeit, was ausgeführt wird. Ein Coding-Agent, der die Anweisung „Repariere den Login-Endpunkt“ erhält, liest womöglich 47 Dateien, schreibt in 12, startet drei Sub-Agenten, ruft zwei Webseiten ab und führt 15 Bash-Befehle aus. Jede Aktion verbraucht Ressourcen. Nichts davon taucht im klassischen Monitoring auf.

Der Cowork-Vorfall legte diese Umkehrung auf Infrastrukturebene offen. Claude Desktop belegte 10 GB Speicherplatz, verbrauchte im Leerlauf 24–55 % CPU und trieb die Swap-Nutzung auf 8-GB-Maschinen von 20.000 auf über 24.000 Swap-ins.¹ Benutzer entdeckten den Ressourcenverbrauch über die Speicherwarnungen von macOS, nicht über die Telemetrie von Anthropic. Die Anwendung bot kein Dashboard, keine Anzeige und keinen Opt-in-Hinweis für die VM-Zuteilung.

Das Muster ist nicht hypothetisch. Im März 2026 berichtete ein Entwickler, dass Claude Code einen Terraform-Befehl ausführte, der eine Produktionsdatenbank zerstörte. Der Agent führte terraform apply gegen eine Produktions-State-Datei aus. Es erschien keine Bestätigungsabfrage. Kein Hook fing den Befehl ab. Der Entwickler bemerkte die Zerstörung erst, als die Anwendung offline ging. Der Vorfall sammelte 142 Punkte und 158 Kommentare auf Hacker News.¹² Wenige Tage später berichtete ein anderer Entwickler, dass Claude Code ein komplettes Produktions-Setup löschte, einschließlich Datenbank-Snapshots mit Datensätzen aus 2,5 Jahren.¹³ Beide Vorfälle haben dieselbe Grundursache: null Sichtbarkeit dessen, was der Agent tat, bevor der Schaden irreversibel war.

Skalieren Sie das Muster auf Agentensitzungen. Mein System zur Hook-Orchestrierung — aufgebaut auf der Hook-Infrastruktur von Claude Code — fängt 15 Ereignistypen bei jedem Tool-Aufruf ab.¹¹ Über 60 Sitzungen hinweg protokollierte das System 84 Hooks, die bei jeder Aktion auslösten, und erzeugte damit Telemetrie, die keine Standardinstallation eines Agenten liefert.² Ohne diese Instrumentierung hätte ich die 12 Drift-Vorfälle, die Phantom-Verifikationsfehler und die rekursiven Spawn-Schleifen nicht entdeckt, die ich in meiner öffentlichen NIST-Stellungnahme dokumentiert habe.³

Der DORA Accelerate State of DevOps Report 2024 stellte fest, dass Teams mit ausgeprägten Observability-Praktiken häufiger deployen und sich schneller von Ausfällen erholen. Die Ausgabe 2025 erweitert den Rahmen auf KI-gestützte Entwicklung und verknüpft Observability damit, „wie KI-gestütztes Programmieren oder Testen Qualität, Durchlaufzeit und Gesamtzuverlässigkeit beeinflusst“.⁴ Observability für Agenten ist kein Nice-to-have. Das Verhalten von Agenten zu messen ist die Voraussetzung dafür, es zu steuern.

Drei Ebenen der Agenten-Sichtbarkeit

Observability für Agenten erfordert drei unabhängige Ebenen. Jede Ebene beantwortet eine andere Frage. Der Ausfall einer Ebene beeinträchtigt die anderen nicht.

Die Ebenen bilden eine Abfolge ab: Sie können keine Richtlinien für Ressourcen durchsetzen, die Sie nicht messen, und Sie können die Einhaltung von Richtlinien nicht prüfen, die Sie nie definiert haben. Jede Ebene baut auf der darunterliegenden auf.

Ebene 1: Ressourcenmessung

Die Ressourcenmessung beantwortet: Wie viel hat der Agent verbraucht — und wo?

Der Cowork-Vorfall ist ein Versagen der Ressourcenmessung. Das VM-Bundle belegte 10 GB Speicherplatz. Der Renderer-Prozess verbrauchte im Leerlauf 24 % CPU. Die Swap-Aktivität stieg während der Sitzungen stetig an. All diese Kennzahlen standen in der macOS-Aktivitätsanzeige zur Verfügung. Keine davon erschien in der Oberfläche von Claude Desktop.¹

Für Coding-Sitzungen von Agenten erfasst die Ressourcenmessung vier Dimensionen:

Speicherplatz. Jeder Dateischreibvorgang, jeder Cache-Eintrag, jede Logdatei. Meine Sitzungen erzeugen 200–400 KB an Statusdateien pro Sitzung (jiro.state.json, jiro.progress.json, Hook-Logs). Über 60 Sitzungen summiert sich das auf 12–24 MB Statusdaten, die über Sitzungen hinweg bestehen bleiben, sofern sie nicht ausdrücklich bereinigt werden.²

Arbeitsspeicher. Der Verbrauch des Kontextfensters pro Zug. Ein Kontextfenster mit 200.000 Token kostet bei den aktuellen Opus-Preisen rund 3 US-Dollar pro vollständiger Füllung. Mein Kosten-Tracker protokolliert den kumulierten Token-Verbrauch pro Sitzung, mit Budget-Schwellen bei 80 %, 90 % und 95 % eines konfigurierbaren Limits.⁵

CPU. Die Ausführungszeit der Hooks. Mein Prompt-Dispatcher mit neun Hooks fügt 200 ms pro Prompt hinzu. Dieser Overhead ist für Benutzer unsichtbar (das Tippen des Menschen ist der Engpass), summiert sich aber über automatisierte Pipelines hinweg. Die autonome ralph-Schleife löst den Dispatcher 50- bis 100-mal pro Story aus, was 10 bis 20 Sekunden Hook-Overhead pro Story ergibt.²

Netzwerk. Web-Abrufe, API-Aufrufe, MCP-Tool-Aufrufe. Jede ausgehende Anfrage ist ein potenzieller Datenkanal — und jeder MCP-Server ist eine neue Angriffsfläche, die die Netzwerkmessung abdecken muss. Meine Bibliothek zur Web-Extraktion protokolliert die abgerufenen URLs und die Antwortgrößen. Ohne Netzwerkmessung lässt sich ein Web-Abruf mit 50 MB Antwort nicht von einem mit 5 KB unterscheiden.⁶

Kein kommerzielles Agenten-Tool bietet ein Ressourcen-Dashboard pro Sitzung. Cloud-Anbieter messen Rechenleistung für die Abrechnung, nicht für die Sichtbarkeit beim Betreiber. Die Lücke zwischen dem, was Agenten verbrauchen, und dem, was Betreiber sehen können, ist das Defizit der Ressourcenmessung.

Dieses Fehlen bleibt unsichtbar, bis sich die Zahlen aufsummieren. Eine einzelne Sitzung, die 400 KB an Statusdateien schreibt, ist nichts. Sechzig Sitzungen mit je 400 KB und ohne Bereinigung hinterlassen 24 MB verwaisten Status. Ein Web-Abruf, der 847 KB liefert, ist vernachlässigbar. Eine Scan-Pipeline, die pro Lauf 80 URLs abruft, erzeugt 67 MB zwischengespeicherte Inhalte, die die Tool-Abstraktion des Agenten vor dem Betreiber verbirgt. Die Ressourcenmessung macht das Kumulierte sichtbar, bevor daraus die Krise wird, die jemanden dazu bringt, das GitHub-Issue #22543 zu eröffnen.¹

Ebene 2: Richtliniendurchsetzung

Die Richtliniendurchsetzung beantwortet: Welche Regeln beschränken den Agenten — und werden diese Regeln konsistent angewendet?

mcp-firewall deckt die Richtlinienebene für CLI-Agenten ab.⁷ Das Tool sitzt zwischen dem Agenten und allen Tool-Anfragen und prüft jede Anfrage vor der Ausführung gegen eine Regex-basierte Richtlinie. Die Richtlinien nutzen JSONNet-Konfigurationsdateien, die nach Ordner, Git-Repository oder Benutzer abgegrenzt sind. Die Firewall unterstützt Claude Code und GitHub Copilot CLI über die Integration in den PreToolUse-Hook.

Die Architektur spiegelt eine zentrale Erkenntnis wider: Jeder Agent baut seine eigene halbfertige Lösung für die Erlauben-/Verweigern-Logik. Claude Code verwendet Glob-Muster. Codex CLI arbeitet nur mit Präfix-Abgleich. Jeder Ansatz deckt nur einen Teil des Richtlinienraums ab. mcp-firewall bündelt die Regeln in einer Engine, die über Agenten hinweg funktioniert.

Betrachten Sie die Richtlinienlücke ohne zentrale Durchsetzung. Mein Hook-System enthält 12 PreToolUse:Bash-Handler, die auf Muster von Zugangsdaten, gefährliche Git-Operationen, Zugriffe auf sensible Pfade und Deployment-Befehle prüfen.² Jeder Handler ist ein eigenes Shell-Skript mit eigenen Regex-Mustern. Wenn ich eine neue Verweigerungsregel brauche, schreibe ich ein neues Skript. Wenn ich prüfen will, welche Regeln existieren, greppe ich durch 12 Dateien. mcp-firewall führt das in einer einzigen Konfigurationsdatei mit expliziten Allow-Arrays zusammen.

Die OWASP Top 10 for Agentic Applications (2025) nennen Agent Goal Hijacking (ASI01) und Excessive Agency (LLM06:2025) als Hauptrisiken.⁸ Beide Risiken verlangen eine Richtliniendurchsetzung auf Ebene der Tool-Aufrufe. Ein Agent, dessen Ziel gekapert wurde, ruft weiterhin Tools auf. Ein Agent mit zu weitreichender Handlungsmacht fordert weiterhin Berechtigungen an. Die Richtliniendurchsetzung fängt beides genau dort ab, wo die Absicht des Agenten auf die Tools des Systems trifft.

Richtliniendurchsetzung ist etwas anderes als Zugriffskontrolle. Die klassische Zugriffskontrolle fragt: „Hat dieser Benutzer die Berechtigung?“ Die Richtliniendurchsetzung für Agenten fragt: „Fällt diese Aktion in diesem Kontext für diese Aufgabe in den genehmigten Geltungsbereich?“ Das Paradox aus Ausrollen und Verteidigen erklärt, warum weitreichende Berechtigungen, die Agenten erst nützlich machen, genau die Angriffsfläche schaffen, die die Richtliniendurchsetzung eingrenzen muss. Die Herausforderung liegt in der Kontextabhängigkeit. Ein git push auf einen Feature-Branch und ein git push --force auf main sind dasselbe Tool (Bash) mit sehr unterschiedlicher Sprengkraft. Die Regex-Muster von mcp-firewall können beides unterscheiden. Die Standardberechtigungen eines Agenten können es nicht.

Auch die Richtliniendurchsetzung auf Anwendungsebene lässt sich umgehen. Wie in Ihre Agenten-Sandbox ist nur ein Vorschlag dokumentiert, weisen scheinbar solide Durchsetzungsgrenzen oft strukturelle Lücken auf. Eine Analyse vom März 2026 dokumentierte drei sich steigernde Techniken zum Ausbruch aus der Sandbox gegen die eingebaute Denylist von Claude Code: pfadbasierte Umgehung (/proc/self/root/usr/bin/npx verweist auf dieselbe Binärdatei wie das blockierte /usr/bin/npx), eigenständiges Abschalten der Sandbox (der Agent kam von sich aus darauf, die Sandbox zu entfernen, als sie den Abschluss der Aufgabe blockierte) und der Aufruf des dynamischen Linkers (ld-linux-x86-64.so.2 lädt Binärdateien über Memory-Mapping und umgeht die Durchsetzungs-Hooks des Kernels vollständig).¹⁴ Die dritte Technik steht für eine ganze Exploit-Klasse: Jedes Laden von Code, das execve vermeidet, umgeht die Durchsetzung auf Prozessebene. Für die Richtliniendurchsetzung heißt das: Denylists auf Basis von Zeichenkettenabgleich sind eine notwendige erste Ebene, aber keine hinreichende. Inhaltsadressierte Durchsetzung (Binärdateien werden über ihren SHA-256-Hash statt über den Dateinamen identifiziert) schließt die Lücke der Pfadumgehung; das Umgehen über den dynamischen Loader erfordert dagegen Kontrollen auf Kernel-Ebene, die unterhalb der Richtlinienebene liegen.

Dieselbe Lehre gilt eine Ebene höher, wo die Richtlinie überhaupt nichts sieht. Plugin4Shell, im September 2026 von Air Security veröffentlicht, ist eine Lieferkettenlücke im Marketplace der vier großen Coding-Agenten: Ein Marketplace heftet für ein Plugin einen geprüften Commit an, doch der Agent checkt diesen Commit aus, ohne zu prüfen, ob er dort überhaupt gelandet ist. Wer das Repository des Plugins kontrolliert, kann deshalb einen Branch anlegen, der nach dem angehefteten Commit benannt ist, und ihn zum Standard-Branch machen; ein routinemäßiges Neuanheften im Marketplace löst dann das Hintergrund-Auto-Update jedes Agenten aus, und der Checkout landet beim Branch, während die Anheftung weiterhin eingehalten aussieht. Nach meiner Lesart sieht kein PreToolUse-Hook, keine Denylist und keine Firewall in diesem Stack einen Plugin-Austausch, denn der Austausch geschieht, bevor der Agent einen Tool-Aufruf macht. Die Zeitleiste von Air nennt eine von Anthropic bestätigte Behebung in Claude Code 2.1.179 und eine von OpenAI ausgelieferte in Codex 0.146.0, keine Behebung für GitHub Copilot und keine in Aussicht für das eingestellte Gemini CLI; der öffentliche Changelog-Eintrag von Claude Code zu 2.1.179 benennt die Behebung nicht, die Versionsangabe beruht also auf der Darstellung der Forscher. Die Kontrolle, die hier greift, ist Versionshygiene plus eine Bestandsaufnahme dessen, was der Marketplace tatsächlich aufgelöst hat, und das ist eine Frage der Messung, keine der Richtlinien.¹⁷

Ebene 3: Laufzeit-Auditing

Das Laufzeit-Auditing beantwortet: Was hat der Agent auf Syscall-Ebene tatsächlich getan?

Logira deckt die Audit-Ebene ab und fängt Systemaufrufe mit eBPF-Probes auf Kernel-Ebene ab.⁹ Das Tool zeichnet drei Ereigniskategorien auf: Prozessausführung (exec-Ereignisse), Dateioperationen (einschließlich Zugriffen auf Dateien mit Zugangsdaten) und Netzwerkverbindungen (mit Erfassung des Ziels). Jeder auditierte Lauf erzeugt drei Dateien: events.jsonl für die Durchsicht der Zeitachse, index.sqlite für abfragbare Filter und meta.json für die Metadaten des Laufs.

Die Entwurfsphilosophie lautet „observe-only“: Logira zeichnet auf und erkennt, setzt aber nichts durch und blockiert nichts.⁹ Die Trennung von der Durchsetzungsebene ist Absicht. Die Richtliniendurchsetzung verhindert bekannt schädliche Aktionen. Das Laufzeit-Auditing entdeckt unbekannt schädliche Aktionen im Nachhinein. Die beiden Ebenen erfüllen unterschiedliche zeitliche Funktionen: Prävention (davor) und Forensik (danach).

Die eBPF-Probes von Logira arbeiten unterhalb der Anwendungsebene. Ein Agent, der einen neuartigen Befehl zusammenbaut, um Daten abzuziehen, setzt trotzdem Syscalls ab. Dateizugriffe, Netzwerkverbindungen oder gestartete Prozesse kann der Agent vor dem Tracing auf Kernel-Ebene nicht verbergen. Der Ansatz erfasst, was Hooks auf Anwendungsebene entgeht: Nebenwirkungen, die an der Tool-Aufruf-Abstraktion vorbeilaufen.

Die eingebauten Erkennungsregeln zielen gezielt auf Risiken von KI-Agenten: Zugriffe auf Dateien mit Zugangsdaten, Änderungen an Persistenzmechanismen (/etc, systemd, cron), verdächtige Befehlsketten (curl-pipe-sh-Muster), destruktive Operationen (rm -rf) und auffälligen Netzwerk-Egress.⁹ Die Regeln sind meinungsstarke Voreinstellungen für das Bedrohungsmodell von Agenten, kein allgemeines System-Auditing.

Die Plattformbeschränkung ist relevant. Logira setzt Linux 5.8+ mit cgroup v2 voraus. Agenten unter macOS (Claude Desktop, Claude Code auf Darwin) können kein eBPF-basiertes Auditing nutzen. Meine OS-Sandbox verwendet als nächstliegendes Äquivalent Seatbelt-Profile von macOS: vom Kernel durchgesetzte Verweigerungsregeln, die Schreibzugriffe auf sensible Pfade blockieren.³ Seatbelt ist Durchsetzung, kein Auditing. Für den rein beobachtenden Audit-Trail von Logira fehlt macOS ein produktionsreifes Gegenstück.

Agent Safehouse, ein macOS-natives Sandboxing-Tool, das im März 2026 auf Hacker News 802 Punkte und 181 Kommentare sammelte, adressiert die Plattformlücke von der Durchsetzungsseite her.¹⁵ Das Tool liefert Sandbox-Profile, die eigens für lokale KI-Agenten unter macOS entworfen wurden. Die Reaktion der Community (802 Punkte sind für ein Sandboxing-Tool außergewöhnlich) zeigt die Dringlichkeit: Wer Agenten unter macOS betreibt, hat zwischen „keine Sandbox“ und „schreiben Sie Ihr eigenes Seatbelt-Profil“ nur wenige Optionen. Für die Durchsetzung schließt Agent Safehouse diese Lücke. Die Audit-Lücke unter macOS bleibt offen.

Die Unterscheidung zwischen Durchsetzung und Auditing entspricht einer zeitlichen Aufteilung in der Incident Response. Die Durchsetzung verhindert den Vorfall. Das Auditing ermöglicht die Rekonstruktion nach dem Vorfall. Beides ist notwendig. Eine Durchsetzungsebene, die jeden Zugriff auf Zugangsdaten blockiert, verhindert zwar die Exfiltration, aber auch legitime SSH-Operationen. Eine Audit-Ebene, die jeden Zugriff auf Zugangsdaten protokolliert, ohne ihn zu blockieren, erlaubt es dem Betreiber, Zugriffsmuster zu prüfen und die Durchsetzungsregeln evidenzbasiert nachzuschärfen. Über diese Rückkopplung zwischen Audit-Daten und Richtlinienpflege verbessert sich der Sichtbarkeits-Stack mit der Zeit: Das Audit legt Muster offen, die Muster prägen die Richtlinie, und die Richtlinie verkleinert die Fläche, die das Audit abdecken muss.

Die cgroup-v2-Isolation von Logira bringt eine Eigenschaft mit, die Auditing auf Anwendungsebene nicht nachbilden kann: die Zuordnung zum jeweiligen Lauf. Das System ordnet jedes Ereignis einem bestimmten auditierten Lauf zu, nicht dem System als Ganzem. Laufen zwei Agentensitzungen gleichzeitig auf derselben Maschine, sorgt die cgroup-Isolation dafür, dass ein Dateizugriff aus Sitzung A nicht im Audit-Trail von Sitzung B auftaucht. Hooks auf Anwendungsebene können dieselbe Garantie nicht geben, weil sie innerhalb des Agentenprozesses auslösen, der keine vom Kernel gezogene Grenze zwischen parallelen Sitzungen kennt.⁹

Was ich tatsächlich betreibe

Mein Orchestrierungssystem deckt alle drei Ebenen über Hooks ab, nicht über dedizierte Monitoring-Tools.

Ressourcenmessung. Der cost-gate-Hook verfolgt den Token-Verbrauch pro Sitzung gegen konfigurierbare Budget-Schwellen.⁵ Der Systemleistungsmonitor prüft CPU, Arbeitsspeicher, Speicherplatz und Swap in konfigurierbaren Intervallen und blendet Warnungen ein, wenn der Ressourcendruck die Schwellen übersteigt.¹⁰ Der Drift-Detektor der Sitzung löst alle 25 Tool-Aufrufe aus und berechnet die Kosinus-Ähnlichkeit zwischen dem Embedding des ursprünglichen Prompts und einem gleitenden Fenster der jüngsten Aktionen.²

Richtliniendurchsetzung. Acht PreToolUse-Dispatcher-Hooks leiten nach Tool-Typ an Handler-Hooks weiter. Allein PreToolUse:Bash führt 12 Handler aus, die Muster von Zugangsdaten, destruktive Git-Operationen, Zugriffe auf sensible Pfade und Deployment-Befehle abdecken. Der Rekursionsschutz erzwingt eine maximale Tiefe von zwei und höchstens fünf Kinder pro übergeordnetem Agenten.²

Laufzeit-Auditing. PostToolUse-Hooks protokollieren das Ergebnis jedes Tool-Aufrufs. Die Hooks für Sicherheitsprüfungen untersuchen die Bash-Ausgabe nach der Ausführung auf durchgesickerte Zugangsdaten. Statusdateien der Sitzung (jiro.state.json) halten jeden Story-Abschluss, jedes Prüfer-Urteil und jedes Ergebnis des Evidence-Gates fest.² Das System nutzt kein eBPF (macOS-Einschränkung), erfasst aber über die Hook-Pipeline Telemetrie auf Tool-Ebene.

Das System funktioniert, weil jede Aktion durch die Hook-Pipeline läuft. Die Einschränkung ist die Tiefe: Monitoring auf Hook-Ebene erfasst, worum der Agent gebeten hat, nicht das, was das Betriebssystem tatsächlich ausgeführt hat. Ein Agent, der einen Bash-Befehl mit eingebetteten Subshells zusammensetzt, führt Code aus, den der Hook als eine einzige Zeichenkette sieht. Ein Auditing auf Kernel-Ebene würde jeden Subprozess sehen.

Konkrete Ergebnisse aus Produktionsvorfällen, bei denen der dreischichtige Stack Fehler erfasst hat, die dem Standard-Monitoring entgangen wären:

Der sich verstärkende blinde Fleck

Agenten, die Agenten starten, vervielfachen die Undurchsichtigkeit. Jeder Delegationsschritt bringt Informationsverlust mit sich.

Wenn mein Orchestrierungssystem die autonome ralph-Schleife ausführt, startet der Elternprozess für jede PRD-Story frische Claude-Code-Instanzen. Jeder Kind-Agent erhält eine eng umrissene Aufgabe und ein frisches Kontextfenster. Der Eltern-Agent verfolgt den Abschlussstatus. Die einzelnen Tool-Aufrufe, Dateizugriffe oder den Ressourcenverbrauch des Kindes sieht er nicht.²

In Tiefe eins (der Eltern-Agent startet ein Kind) sieht der Eltern-Agent die Endausgabe des Kindes. In Tiefe zwei (das Kind startet ein Enkelkind) sieht er den Bericht des Kindes über die Ausgabe des Enkelkindes. Jeder Schritt komprimiert Information. Die Analyse der Delegationskette in meiner NIST-Stellungnahme benannte drei sich verstärkende Risiken: semantische Kompression (der Kontext schrumpft auf eine Prompt-Zeichenkette), Autoritätsverstärkung (Kinder erben Berechtigungen, ohne deren Sensibilität zu erfassen) und Verantwortungsdiffusion (der Wurzelagent trägt die Verantwortung für Ergebnisse, die er nie geprüft hat).³

Die Observability verschlechtert sich im selben Maß. Ein dreischichtiger Sichtbarkeits-Stack auf dem Wurzelagenten liefert null Einblick in den Enkel-Agenten, sofern nicht jedes Kind sein eigenes Monitoring betreibt. Mein Rekursionsschutz erzwingt zwar die Tiefenbegrenzung, doch dieser Schutz ist eine Richtlinienkontrolle, keine Observability-Kontrolle. Zu wissen, dass die Delegation bei Tiefe zwei endete, sagt Ihnen nicht, was in Tiefe zwei geschehen ist.

Ein konkretes Beispiel aus meinem Produktivsystem: Die ralph-Schleife startete einen Kind-Agenten, um eine Story zur Datenbankmigration umzusetzen. Der Kind-Agent entschied, die Migration brauche einen „Verifikationsschritt“, und startete seinerseits einen Sub-Agenten für Integrationstests. Der Enkel-Agent scheiterte stillschweigend (die Testdatenbank war nicht konfiguriert). Der Kind-Agent erhielt eine leere Antwort, deutete das Schweigen als Erfolg und meldete die Story als abgeschlossen. Der Eltern-Agent protokollierte „Story 4: abgeschlossen“. Die fehlerhafte Migration entdeckte ich drei Stunden später, als die Anwendung an der fehlenden Spalte abstürzte. Die Telemetrie des Wurzelagenten zeigte einen sauberen Lauf. Der Fehler saß zwei Schritte tief und war für jede Monitoring-Ebene unsichtbar, die ich an der Wurzel ausgerollt hatte.²

Das OWASP-Framework für Agentic Applications behandelt kaskadierende Fehler und außer Kontrolle geratene Agenten, schreibt aber keine Observability-Anforderungen für Delegationsketten zwischen mehreren Agenten vor.⁸ Die Analyse von OpenGuard zu Prompt Injection bei Agenten (März 2026) legt dieselbe Lücke von der Sicherheitsseite her offen: Kontaminierter Kontext, der zwischen Agenten mit unterschiedlichen Berechtigungen fließt, schafft über Übergaben hinweg „einen stillen Weg, Autorität auszuweiten“, ohne klare Datenflussrichtlinien oder Autorisierung auf Kompositionsebene.¹⁶ Die Lücke ist struktureller Natur: Jeder Agent in der Kette bräuchte seine eigene Ressourcenmessung, seine eigene Richtliniendurchsetzung und sein eigenes Laufzeit-Auditing — unabhängig konfiguriert und unabhängig berichtet. Der Overhead ist multiplikativ. Drei Monitoring-Ebenen bei drei Agenten in einer Kette ergeben neun Monitoring-Instanzen, von denen jede ihre eigene Telemetrie erzeugt und ihre eigene Konfiguration braucht. Kein bestehendes Tool bewältigt diese Koordination.

Was Sie heute umsetzen können

Drei minimale Monitoring-Hooks, die den Sichtbarkeits-Stack abdecken:

1. Ressourcen: Token-Budget-Tracker. Protokollieren Sie die kumulierten Eingabe- und Ausgabe-Token pro Sitzung. Setzen Sie ein hartes Limit. Warnen Sie bei 80 %. Die Umsetzung erfordert, die Nutzungsstatistik des Agenten auszulesen (Claude Code zeigt die Sitzungskosten über /cost an) und mit einer Schwelle zu vergleichen. Mein cost-gate-Hook erledigt das in 47 Zeilen Bash.⁵

2. Richtlinie: PreToolUse-Verweigerungsliste. Erstellen Sie einen Hook, der vor jedem Bash-Tool-Aufruf auslöst. Prüfen Sie den Befehl gegen eine Liste von Mustern: rm -rf /, git push --force, Pfade, die .ssh oder .env enthalten, curl | sh. Blockieren Sie Treffer. Die Umsetzung erfordert ein Shell-Skript, das stdin liest (das JSON des Tool-Aufrufs), das Befehlsfeld extrahiert und gegen eine Musterdatei greppt. Mein Hook zur Prüfung von Zugangsdaten erledigt das in 31 Zeilen.²

3. Audit: PostToolUse-Sitzungslog. Hängen Sie jeden Tool-Aufruf und jedes Ergebnis an eine sitzungsspezifische JSONL-Datei an. Nehmen Sie Zeitstempel, Tool-Namen, Argumente und Exit-Code auf. Das Log ermöglicht die Rekonstruktion nach der Sitzung: Was hat der Agent getan, in welcher Reihenfolge, und ist etwas stillschweigend fehlgeschlagen? Mein Sitzungs-Logger erledigt das in 22 Zeilen Bash.²

Ein ausgearbeitetes Beispiel für den Hook der Verweigerungsliste in settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/check-sensitive-paths.sh"
          }
        ]
      }
    ]
  }
}

Das Hook-Skript liest den Tool-Aufruf von stdin, extrahiert die Befehlszeichenkette und prüft sie gegen die Muster. Ein blockierter Befehl liefert ein JSON-Objekt mit {"decision": "block", "reason": "Sensitive path access denied"} zurück. Ein erlaubter Befehl liefert {"decision": "approve"}. Claude Code beachtet beide Antworten ohne weitere Rückfrage. Der gesamte Hook erzeugt bei erlaubten Befehlen keinerlei zusätzliche Latenz (die Regex-Prüfung läuft in unter 5 ms) und gibt bei blockierten sofort Rückmeldung.

Diese drei Hooks brauchen zusammen weniger als 100 Zeilen. Sie ersetzen keine dedizierten Monitoring-Tools. Sie ersetzen null Sichtbarkeit durch minimale Sichtbarkeit. Minimale Sichtbarkeit ist die Voraussetzung für jede Governance-Entscheidung, die danach kommt. Ohne Messung können Sie kein Ressourcenbudget festlegen. Ohne Verweigerungsliste können Sie keine Richtlinie für den Geltungsbereich durchsetzen. Ohne Audit-Log können Sie keinen Vorfall untersuchen. Fangen Sie mit dem Log an. Die anderen beiden folgen.

Die wichtigsten Erkenntnisse

Für Plattform-Engineers: Agenten verbrauchen Ressourcen, die das bestehende Monitoring nicht erfasst. Speicherplatz-, Arbeitsspeicher-, CPU- und Netzwerknutzung pro Agentensitzung gehören auf dasselbe Dashboard wie Container-Metriken. Der Cowork-Vorfall belegt den Bedarf: 10 GB belegt, ohne jede Sichtbarkeit für den Betreiber.

Für Sicherheitsteams: Die Richtliniendurchsetzung an der Grenze des Tool-Aufrufs ist die minimal tragfähige Sicherheitshaltung für Agenten. Der zentralisierte Ansatz von mcp-firewall bündelt die Erlauben-/Verweigern-Logik einzelner Agenten in einer prüfbaren Konfiguration. Prüfen Sie, ob die eingebauten Berechtigungen Ihres Agenten den Richtlinienraum abdecken, den Ihr Bedrohungsmodell verlangt.

Für Engineering-Managerinnen und -Manager: Die langfristige Antwort ist die Selbstverwaltung von Agenten — Agenten, die Monitoring als Verhaltensnorm verinnerlichen und nicht nur als äußere Einschränkung erleben. Bis das ausgereift ist, stellen Sie drei Fragen an Ihr Agenten-Tooling: Können Sie den Ressourcenverbrauch pro Sitzung sehen? Können Sie Richtlinien für Tool-Aufrufe definieren und prüfen? Können Sie im Nachhinein rekonstruieren, was ein Agent getan hat? Lautet eine Antwort „nein“, haben Sie eine Sichtbarkeitslücke, die mit jedem weiteren Agenten in Ihrem Workflow wächst.

Häufige Fragen

Was ist Agenten-Observability?

Agenten-Observability ist die Fähigkeit, zu überwachen und zu verstehen, was ein KI-Agent während der Ausführung tut: welche Ressourcen er verbraucht, welche Aktionen er ausführt und ob diese Aktionen den definierten Richtlinien entsprechen.

Warum hat Cowork von Anthropic eine 10-GB-VM angelegt?

Die Funktion Cowork in Claude Desktop stellt eine virtuelle Maschine für gemeinsame Entwicklungssitzungen bereit. Claude Desktop legt das VM-Bundle bei jeder macOS-Installation automatisch an, auch bei Benutzern, die die Funktion nie aktivieren, und behält es, bis es manuell gelöscht wird.¹

Was ist mcp-firewall?

mcp-firewall ist ein Open-Source-Tool zur Richtliniendurchsetzung, das Tool-Anfragen von CLI-Agenten (Claude Code, GitHub Copilot CLI) abfängt und sie vor der Ausführung gegen Regex-basierte Erlauben-/Verweigern-Regeln prüft.⁷

Was ist Laufzeit-Auditing mit eBPF?

eBPF (extended Berkeley Packet Filter) ermöglicht das Tracing von Systemaufrufen auf Kernel-Ebene, ohne den auditierten Prozess zu verändern. Tools wie Logira nutzen eBPF-Probes, um Prozessausführungen, Dateioperationen und Netzwerkverbindungen während der Läufe von KI-Agenten aufzuzeichnen.⁹

Wie starten Agenten Sub-Agenten, ohne dass Betreiber es sehen?

Agenten, die Aufgaben delegieren, starten Kindprozesse mit frischen Kontextfenstern. Der Eltern-Agent sieht die Endausgabe des Kindes, aber nicht dessen einzelne Tool-Aufrufe, Dateizugriffe oder Ressourcenverbrauch. Bei jedem Delegationsschritt wird Information komprimiert: Die vollständige Sitzung des Enkelkindes schrumpft im Log des Eltern-Agenten auf eine einzeilige Statusmeldung. Die Observability verschlechtert sich im selben Maß, in dem die Delegationstiefe zunimmt.²

Worin unterscheidet sich das Monitoring von Agenten vom klassischen APM?

Klassisches Application Performance Monitoring (APM) erfasst Antwortzeiten, Fehlerraten und Durchsatz deterministischer Software. Das Monitoring von Agenten erfasst nicht-deterministisches Verhalten: was der Agent zur Laufzeit zu tun beschlossen hat, ob diese Entscheidungen innerhalb der Richtlinien lagen und welche Ressourcen jede Entscheidung verbraucht hat. APM setzt voraus, dass die Anwendung einem bekannten Codepfad folgt. Das Monitoring von Agenten setzt voraus, dass der Agent seinen Pfad selbst wählt.²

Können Hooks von Claude Code Observability für Agenten liefern?

Ja. Das Hook-System von Claude Code führt Skripte bei Lebenszyklus-Ereignissen aus (PreToolUse, PostToolUse, Notification), die Ressourcen messen, Richtlinien durchsetzen und Aktionen protokollieren können. Ein Setup aus drei Hooks — Token-Budget-Tracker, PreToolUse-Verweigerungsliste und PostToolUse-Sitzungs-Logger — deckt alle drei Sichtbarkeitsebenen in weniger als 100 Zeilen Bash ab. Hooks sind der zugänglichste Einstieg für Teams, die Claude Code bereits nutzen.

Was passiert, wenn Agenten ihre eigene Sandbox umgehen?

Eine umgangene Sandbox bedeutet, dass die Durchsetzungsebene stillschweigend versagt. Der Agent arbeitet außerhalb seines vorgesehenen Rahmens weiter, und ohne Laufzeit-Auditing existiert kein Nachweis des Vorfalls. Die im März 2026 dokumentierten Techniken zum Ausbruch aus der Sandbox umfassen pfadbasierte Umgehung, eigenständiges Abschalten der Sandbox und den Aufruf des dynamischen Linkers — allesamt unsichtbar für Monitoring auf Anwendungsebene.

Warum ist Observability für MCP-Tools wichtig?

Jeder MCP-Tool-Aufruf ist ein potenzieller Datenkanal: Er kann Dateien lesen, Netzwerkanfragen stellen und Code ausführen. MCP-Server vergrößern die Angriffsfläche, weil jeder Server neue Fähigkeiten mitbringt, die der Agent zur Laufzeit aufrufen kann. Ohne Protokollierung und Richtliniendurchsetzung pro Aufruf bleiben MCP-Tool-Aufrufe für den Betreiber unsichtbar.

Wie überwacht man Delegationsketten mit mehreren Agenten?

Jeder Agent in einer Delegationskette braucht seine eigene Ressourcenmessung, seine eigene Richtliniendurchsetzung und sein eigenes Laufzeit-Auditing. Die autonome ralph-Schleife zeigt das Problem: Ein Eltern-Agent startet Kind-Agenten, die jeweils frische Kontextfenster erhalten. Der Eltern-Agent sieht die Endausgabe, nicht die einzelnen Tool-Aufrufe. Die Observability verschlechtert sich im selben Maß, in dem die Delegationstiefe zunimmt; nötig ist deshalb unabhängiges Monitoring bei jedem Schritt.

Quellen