Der unsichtbare Agent: Warum Sie nicht regulieren können, was Sie nicht sehen

Anthropic lieferte eine Funktion namens Cowork in Claude Desktop aus. Die Funktion erstellte ein 10-GB-Virtual-Machine-Bundle auf jeder macOS-Installation. Benutzer, die Cowork nie aktiviert hatten, erhielten trotzdem die VM. Benutzer, die sie löschten, sahen zu, wie sie sich regenerierte. Ein Benutzer berichtete, dass das Bundle 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.

TL;DR

Agent-Tools allokieren nun Rechenressourcen (Festplatte, Arbeitsspeicher, CPU, Netzwerk) ohne Transparenz für den Betreiber. Die Cowork-VM von Anthropic ist das sichtbare Beispiel; jeder MCP-Tool-Call, jeder gestartete Sub-Agent und jeder Web-Fetch ist ein unsichtbares. Die Regulierung von Agents erfordert drei Ebenen der Observability: Ressourcenmessung (was wurde verbraucht?), Richtliniendurchsetzung (was durfte er tun?) und Laufzeit-Auditing (was hat er tatsächlich getan?). Zwei Open-Source-Projekte adressieren die Richtlinien- und Audit-Ebene (mcp-firewall und Logira), aber kein Produktionstool deckt alle drei ab. Im Folgenden: das Sichtbarkeitsproblem, der Drei-Ebenen-Stack, was jede Ebene erfasst, und minimale Monitoring-Hooks, die Sie heute implementieren können.

Das Sichtbarkeitsproblem

Traditionelle Software operiert unterhalb einer Observability-Linie, die Betreiber bewusst setzen. Ein Webserver schreibt Zugriffsprotokolle, weil Ingenieure das Logging konfiguriert haben. Eine Datenbank verfolgt langsame Abfragen, weil jemand log_min_duration_statement gesetzt hat. Der Betreiber bestimmt die Granularität.

Agent-Systeme kehren dieses Verhältnis um. Der Agent entscheidet zur Laufzeit, was er ausführt. Ein Coding-Agent, der „behebe den Login-Endpoint” erhält, liest möglicherweise 47 Dateien, schreibt in 12, startet drei Sub-Agents, ruft zwei Webseiten ab und führt 15 Bash-Befehle aus. Jede Aktion verbraucht Ressourcen. Nichts davon erscheint im traditionellen Monitoring.

Der Cowork-Vorfall legte die Umkehrung auf Infrastrukturebene offen. Claude Desktop allokierte 10 GB Speicherplatz, verbrauchte 24–55 % CPU im Leerlauf und trieb die Swap-Nutzung von 20K auf über 24K Swapins auf 8-GB-Maschinen.¹ Benutzer entdeckten den Ressourcenverbrauch durch macOS-Speicherwarnungen, nicht durch die Telemetrie von Anthropic. Die Anwendung bot kein Dashboard, keinen Zähler und keine Opt-in-Offenlegung für die VM-Allokation.

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. Keine Bestätigungsaufforderung erschien. Kein Hook fing den Befehl ab. Der Entwickler entdeckte die Zerstörung, als die Anwendung offline ging. Der Vorfall sammelte 142 Punkte und 158 Kommentare auf Hacker News.¹² Tage später berichtete ein anderer Entwickler, dass Claude Code ein gesamtes Produktions-Setup löschte, einschließlich Datenbank-Snapshots, die 2,5 Jahre an Datensätzen repräsentierten.¹³ Beide Vorfälle teilen dieselbe Ursache: null Sichtbarkeit darüber, was der Agent tat, bevor der Schaden irreversibel war.

Skalieren Sie das Muster auf Agent-Sessions. Mein Hook-Orchestrierungssystem fängt 15 Ereignistypen über jeden Tool-Call ab.¹¹ Über 60 Sessions protokollierte das System 84 Hooks, die bei jeder Aktion feuerten, und erzeugte Telemetrie, die keine Standard-Agent-Installation bietet.² Ohne diese Instrumentierung hätte ich die 12 Drift-Vorfälle, die Phantom-Verifikationsfehler oder die rekursiven Spawning-Schleifen nicht entdeckt, die in meinem öffentlichen NIST-Kommentar dokumentiert sind.³

Der DORA 2024 Accelerate State of DevOps Report stellte fest, dass Teams mit starken Observability-Praktiken häufiger deployen und sich schneller von Ausfällen erholen. Die Ausgabe 2025 erweitert das Framework auf KI-gestützte Entwicklung und verbindet Observability damit, „wie KI-gestütztes Coding oder Testen Qualität, Durchlaufzeit und Gesamtzuverlässigkeit beeinflusst.”⁴ Agent-Observability ist kein Nice-to-have. Die Messung des Agent-Verhaltens ist eine Voraussetzung für dessen Regulierung.

Drei Ebenen der Agent-Sichtbarkeit

Agent-Observability erfordert drei unabhängige Ebenen. Jede Ebene beantwortet eine andere Frage. Ein Ausfall in einer Ebene kompromittiert die anderen nicht.

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

Ebene 1: Ressourcenmessung

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

Der Cowork-Vorfall ist ein Versagen der Ressourcenmessung. Das VM-Bundle verbrauchte 10 GB Speicherplatz. Der Renderer-Prozess verbrauchte 24 % CPU im Leerlauf. Die Swap-Aktivität stieg während der Sessions stetig an. All diese Metriken existierten im macOS Activity Monitor. Keine erschien in der Oberfläche von Claude Desktop.¹

Für Agent-Coding-Sessions verfolgt die Ressourcenmessung vier Dimensionen:

Festplatte. Jeder Dateischreibvorgang, jeder Cache-Eintrag, jede Log-Datei. Meine Sessions erzeugen 200–400 KB an State-Dateien pro Session (jiro.state.json, jiro.progress.json, Hook-Logs). Über 60 Sessions akkumuliert sich das auf 12–24 MB an State-Daten, die über Sessions hinweg bestehen bleiben, sofern sie nicht explizit bereinigt werden.²

Arbeitsspeicher. Kontextfenster-Verbrauch pro Turn. Ein 200.000-Token-Kontextfenster kostet bei aktueller Opus-Preisgestaltung etwa 3 $ pro vollständiger Füllung. Mein Kosten-Tracker protokolliert den kumulativen Token-Verbrauch pro Session mit Budgetschwellen bei 80 %, 90 % und 95 % eines konfigurierbaren Limits.⁵

CPU. Hook-Ausführungszeit. Mein Neun-Hook-Prompt-Dispatcher fügt 200 ms pro Prompt hinzu. Dieser Overhead ist für Benutzer unsichtbar (menschliches Tippen ist der Engpass), akkumuliert sich aber über automatisierte Pipelines. Die ralph-Autonomie-Schleife feuert den Dispatcher 50–100 Mal pro Story und fügt 10–20 Sekunden Hook-Overhead pro Story hinzu.²

Netzwerk. Web-Fetches, API-Calls, MCP-Tool-Aufrufe. Jede ausgehende Anfrage ist ein potenzieller Datenkanal. Meine Web-Extract-Bibliothek protokolliert Fetch-URLs und Antwortgrößen. Ohne Netzwerkmessung ist ein Web-Fetch, der eine 50-MB-Antwort zurückgibt, nicht von einem zu unterscheiden, der 5 KB zurückgibt.⁶

Kein kommerzielles Agent-Tool bietet ein Ressourcen-Dashboard pro Session. Cloud-Anbieter messen Compute für die Abrechnung, nicht für die Transparenz des Betreibers. Die Kluft zwischen dem, was Agents verbrauchen, und dem, was Betreiber sehen können, ist das Ressourcenmessungsdefizit.

Die Abwesenheit fühlt sich unsichtbar an, bis sich die Zahlen akkumulieren. Eine Session, die 400 KB State-Dateien schreibt, ist nichts. Sechzig Sessions, die jeweils 400 KB schreiben, ohne Bereinigung, hinterlassen 24 MB verwaiste State-Daten. Ein Web-Fetch, der 847 KB zurückgibt, ist vernachlässigbar. Eine Scanning-Pipeline, die 80 URLs pro Durchlauf abruft, generiert 67 MB gecachten Inhalt, den die Tool-Abstraktion des Agents vor dem Betreiber verbirgt. Ressourcenmessung macht das Kumulative sichtbar, bevor es zur Krise wird, die jemanden dazu bringt, GitHub-Issue #22543 einzureichen.¹

Ebene 2: Richtliniendurchsetzung

Richtliniendurchsetzung beantwortet: Welche Regeln beschränken den Agent, und werden diese Regeln konsistent angewendet?

mcp-firewall adressiert die Richtlinienebene für CLI-Agents.⁷ Das Tool sitzt zwischen dem Agent und allen Tool-Use-Anfragen und evaluiert jede Anfrage gegen eine regex-basierte Richtlinie vor der Ausführung. Richtlinien verwenden JSONNet-Konfigurationsdateien, die nach Ordner, Git-Repository oder Benutzer eingegrenzt sind. Die Firewall unterstützt Claude Code und GitHub Copilot CLI durch PreToolUse-Hook-Integration.

Die Architektur spiegelt eine zentrale Erkenntnis wider: Jeder Agent implementiert seine eigene halbfertige Lösung für Allow/Deny-Logik. Claude Code verwendet Glob-Muster. Codex CLI verwendet nur Präfix-Matching. Jeder Ansatz deckt eine Teilmenge des Richtlinienraums ab. mcp-firewall konsolidiert die Regeln in eine Engine, die über Agents hinweg funktioniert.

Betrachten Sie die Richtlinienlücke ohne zentrale Durchsetzung. Mein Hook-System umfasst 12 PreToolUse:Bash-Handler, die auf Credential-Muster, gefährliche Git-Operationen, Zugriff auf sensible Pfade und Deployment-Befehle prüfen.² Jeder Handler ist ein separates Shell-Skript mit eigenen Regex-Mustern. Wenn ich eine neue Deny-Regel hinzufügen muss, schreibe ich ein neues Skript. Wenn ich prüfen muss, welche Regeln existieren, grepe ich über 12 Dateien. mcp-firewall konsolidiert das in eine einzige Konfigurationsdatei mit expliziten Allow-Arrays.

Die OWASP Top 10 für Agentic Applications (2025) identifiziert Agent Goal Hijacking (ASI01) und Excessive Agency (LLM06:2025) als Top-Risiken.⁸ Beide Risiken erfordern Richtliniendurchsetzung auf Tool-Call-Ebene. Ein Agent, der ein Ziel kapert, führt weiterhin Tool-Calls aus. Ein Agent mit übermäßiger Handlungsbefugnis fordert weiterhin Berechtigungen an. Richtliniendurchsetzung fängt beides an der Grenze ab, wo die Absicht des Agents auf die Tools des Systems trifft.

Richtliniendurchsetzung unterscheidet sich von Zugriffskontrolle. Traditionelle Zugriffskontrolle fragt „hat dieser Benutzer die Berechtigung?” Richtliniendurchsetzung für Agents fragt „fällt diese Aktion, in diesem Kontext, für diese Aufgabe, innerhalb des genehmigten Umfangs?” Die Kontextsensitivität ist die Herausforderung. Ein git push auf einen Feature-Branch und ein git push --force auf main sind dasselbe Tool (Bash) mit unterschiedlichem Schadenspotenzial. Die Regex-Muster von mcp-firewall können zwischen ihnen unterscheiden. Standard-Agent-Berechtigungen können das nicht.

Richtliniendurchsetzung auf Anwendungsebene ist zudem dem Risiko der Umgehung ausgesetzt. Eine Analyse vom März 2026 dokumentierte drei eskalierende Sandbox-Escape-Techniken gegen die eingebaute Denylist von Claude Code: pfadbasierte Umgehung (/proc/self/root/usr/bin/npx löst zum selben Binary auf wie das blockierte /usr/bin/npx), selbstgesteuerte Sandbox-Deaktivierung (der Agent kam eigenständig zu dem Schluss, die Sandbox zu entfernen, als sie die Aufgabenerfüllung blockierte) und Aufruf des dynamischen Linkers (ld-linux-x86-64.so.2 lädt Binaries über Memory-Mapping, wodurch Kernel-Enforcement-Hooks vollständig umgangen werden).¹⁴ Die dritte Technik ist eine Exploit-Klasse: Jedes Code-Loading, das execve vermeidet, umgeht prozessbasierte Durchsetzung. Die Erkenntnis für die Richtliniendurchsetzung ist, dass String-Matching-Denylists eine notwendige erste Ebene sind, aber keine hinreichende. Content-adressierbare Durchsetzung (Identifizierung von Binaries anhand von SHA-256-Hash statt Dateiname) schließt die Pfad-Umgehungslücke, aber die Umgehung über den dynamischen Linker erfordert Kernel-Level-Kontrollen, die unterhalb der Richtlinienebene liegen.

Ebene 3: Laufzeit-Auditing

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

Logira adressiert die Audit-Ebene mittels eBPF-Probes, die Systemaufrufe auf Kernel-Ebene abfangen.⁹ Das Tool zeichnet drei Ereigniskategorien auf: Prozessausführung (Exec-Events), Dateioperationen (einschließlich Zugriff auf Credential-Dateien) und Netzwerkverbindungen (mit Ziel-Tracking). Jeder auditierte Durchlauf generiert drei Dateien: events.jsonl für die zeitliche Nachverfolgung, index.sqlite für abfragbare Filterung und meta.json für Lauf-Metadaten.

Die Design-Philosophie ist „nur beobachten”: Logira zeichnet auf und erkennt, setzt aber nicht durch und blockiert nicht.⁹ Die Trennung von der Durchsetzungsebene ist bewusst gewählt. Richtliniendurchsetzung verhindert bekannte schlechte Aktionen. Laufzeit-Auditing entdeckt unbekannte schlechte Aktionen im Nachhinein. Die beiden Ebenen dienen unterschiedlichen zeitlichen Funktionen: Prävention (vorher) und Forensik (nachher).

Logiras eBPF-Probes operieren unterhalb der Anwendungsschicht. Ein Agent, der einen neuartigen Befehl zur Datenexfiltration konstruiert, führt dennoch Syscalls aus. Der Agent kann Dateilesevorgänge, Netzwerkverbindungen oder Prozess-Spawns nicht vor Kernel-Level-Tracing verbergen. Der Ansatz erfasst, was Hooks auf Anwendungsebene übersehen: Seiteneffekte, die die Tool-Call-Abstraktion umgehen.

Eingebaute Erkennungsregeln zielen speziell auf KI-Agent-Risiken ab: Zugriff auf Credential-Dateien, Änderungen an Persistenzmechanismen (/etc, systemd, cron), verdächtige Befehlsketten (curl-pipe-sh-Muster), destruktive Operationen (rm -rf) und anomalen Netzwerk-Egress.⁹ Die Regeln sind meinungsbehaftete Standards für das Agent-Bedrohungsmodell, kein generisches System-Auditing.

Die Plattformbeschränkung ist relevant. Logira erfordert Linux 5.8+ mit cgroup v2. macOS-Agents (Claude Desktop, Claude Code auf Darwin) können kein eBPF-basiertes Auditing nutzen. Meine OS-Sandbox verwendet macOS-Seatbelt-Profile als nächstliegendes Äquivalent: vom Kernel durchgesetzte Deny-Regeln, die Schreibvorgänge auf sensible Pfade blockieren.³ Seatbelt ist Durchsetzung, nicht Auditing. macOS fehlt ein produktionsreifes Äquivalent zu Logiras reinem Beobachtungs-Audit-Trail.

Agent Safehouse, ein macOS-natives Sandboxing-Tool, das im März 2026 802 Punkte und 181 Kommentare auf Hacker News sammelte, adressiert die Plattformlücke von der Durchsetzungsseite.¹⁵ Das Tool bietet Sandbox-Profile, die speziell für lokale KI-Agents auf macOS konzipiert sind. Die Community-Resonanz (802 Punkte sind außergewöhnlich für ein Sandboxing-Tool) spiegelt die Dringlichkeit wider: Praktiker, die Agents auf macOS betreiben, haben begrenzte Optionen zwischen „keine Sandbox” und „schreiben Sie Ihr eigenes Seatbelt-Profil”. Agent Safehouse füllt diese Lücke für die Durchsetzung. Die Audit-Lücke auf macOS bleibt offen.

Die Unterscheidung zwischen Durchsetzung und Auditing entspricht einer zeitlichen Aufteilung in der Incident Response. Durchsetzung verhindert den Vorfall. Auditing ermöglicht die Rekonstruktion nach dem Vorfall. Beides ist notwendig. Eine Durchsetzungsebene, die jeden Credential-Zugriff blockiert, verhindert Exfiltration, aber auch legitime SSH-Operationen. Eine Audit-Ebene, die jeden Credential-Zugriff ohne Blockierung protokolliert, ermöglicht dem Betreiber die Überprüfung von Zugriffsmustern und die Anpassung von Durchsetzungsregeln auf Basis von Evidenz. Die Rückkopplungsschleife zwischen Audit-Daten und Richtlinienverfeinerung ist der Weg, wie sich der Sichtbarkeits-Stack im Laufe der Zeit verbessert: Auditing offenbart Muster, Muster informieren Richtlinien, Richtlinien reduzieren die Oberfläche, die das Auditing abdecken muss.

Logiras cgroup-v2-Isolation bietet eine Funktion, die Auditing auf Anwendungsebene nicht replizieren kann: laufbezogene Zuordnung. Das System ordnet jedes Ereignis einem bestimmten auditierten Lauf zu, nicht dem System global. Wenn zwei Agent-Sessions gleichzeitig auf derselben Maschine laufen, stellt die cgroup-Isolation sicher, dass Dateizugriff in Session A nicht im Audit-Trail von Session B erscheint. Hooks auf Anwendungsebene können dieselbe Garantie nicht bieten, da die Hooks innerhalb des Agent-Prozesses feuern, der keine Kernel-Level-Grenze zwischen gleichzeitigen Sessions hat.⁹

Was ich tatsächlich betreibe

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

Ressourcenmessung. Der Cost-Gate-Hook verfolgt den Token-Verbrauch pro Session gegen konfigurierbare Budgetschwellen.⁵ Der System-Performance-Monitor prüft CPU, Arbeitsspeicher, Festplatte und Swap in konfigurierbaren Intervallen und injiziert Warnungen, wenn der Ressourcendruck Schwellenwerte überschreitet.¹⁰ Der Session-Drift-Detektor feuert alle 25 Tool-Calls und berechnet die Kosinus-Ähnlichkeit zwischen dem ursprünglichen Prompt-Embedding und einem gleitenden Fenster der letzten Aktionen.²

Richtliniendurchsetzung. Acht PreToolUse-Dispatcher-Hooks leiten nach Tool-Typ an Handler-Hooks weiter. PreToolUse:Bash allein führt 12 Handler aus, die Credential-Muster, destruktive Git-Operationen, Zugriff auf sensible Pfade und Deployment-Befehle abdecken. Der Rekursions-Guard erzwingt eine maximale Tiefe von zwei und maximal fünf Kinder pro Eltern-Agent.²

Laufzeit-Auditing. PostToolUse-Hooks protokollieren jedes Tool-Call-Ergebnis. Die Security-Scanning-Hooks prüfen Bash-Output nach der Ausführung auf Credential-Leaks. Session-State-Dateien (jiro.state.json) zeichnen jede Story-Vervollständigung, jedes Reviewer-Urteil und jedes Evidence-Gate-Ergebnis auf.² Das System verwendet kein eBPF (macOS-Beschränkung), erfasst aber Telemetrie auf Tool-Ebene durch die Hook-Pipeline.

Das System funktioniert, weil jede Aktion die Hook-Pipeline durchläuft. Die Einschränkung liegt in der Tiefe: Monitoring auf Hook-Ebene erfasst, was der Agent zu tun bat, nicht was das Betriebssystem tatsächlich ausgeführt hat. Ein Agent, der einen Bash-Befehl mit eingebetteten Subshells konstruiert, führt Code aus, den der Hook als einzelne Zeichenkette sieht. Kernel-Level-Auditing würde jeden Unterprozess sehen.

Konkrete Ergebnisse aus Produktionsvorfällen, bei denen der Drei-Ebenen-Stack Fehler erfasste, die Standard-Monitoring übersehen hätte:

Der sich verstärkende blinde Fleck

Agents, die Agents starten, multiplizieren die Intransparenz. Jeder Delegationsschritt führt zu Informationsverlust.

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

Bei Tiefe eins (Eltern startet Kind) sieht der Eltern-Agent die endgültige Ausgabe des Kindes. Bei Tiefe zwei (Kind startet Enkel) sieht der Eltern-Agent den Bericht des Kindes über die Ausgabe des Enkels. Bei jedem Schritt wird Information komprimiert. Die Analyse der Delegationskette in meinem NIST-Kommentar identifizierte drei sich verstärkende Risiken: semantische Kompression (Kontext kollabiert zu einem Prompt-String), Autoritätsverstärkung (Kinder erben Berechtigungen, ohne die Sensitivität zu verstehen) und Verantwortungsdiffusion (der Root-Agent trägt die Verantwortung für Ergebnisse, die er nie überprüft hat).³

Observability degradiert mit derselben Rate. Ein Drei-Ebenen-Sichtbarkeits-Stack auf dem Root-Agent bietet null Sichtbarkeit in den Enkel-Agent, es sei denn, jedes Kind betreibt unabhängig sein eigenes Monitoring. Mein Rekursions-Guard erzwingt das Tiefenlimit, aber der Guard ist eine Richtlinienkontrolle, keine Observability-Kontrolle. Zu wissen, dass die Delegation bei Tiefe zwei gestoppt hat, sagt Ihnen nicht, was bei Tiefe zwei passiert ist.

Ein konkretes Beispiel aus meinem Produktionssystem: Die ralph-Schleife startete einen Kind-Agent, um eine Datenbankmigrations-Story zu implementieren. Der Kind-Agent entschied, dass die Migration einen „Verifikationsschritt” benötigte, und startete seinen eigenen Sub-Agent, um Integrationstests auszuführen. Der Enkel-Agent schlug stillschweigend fehl (die Testdatenbank war nicht konfiguriert). Der Kind-Agent erhielt eine leere Antwort, interpretierte Stille als Erfolg und meldete die Story als abgeschlossen. Der Eltern-Agent protokollierte „Story 4: abgeschlossen.” Ich entdeckte die fehlerhafte Migration drei Stunden später, als die Anwendung wegen der fehlenden Spalte abstürzte. Die Telemetrie des Root-Agents zeigte einen sauberen Lauf. Der Fehler lebte zwei Schritte tief, unsichtbar für jede Monitoring-Ebene, die ich auf dem Root deployed hatte.²

Das OWASP Agentic Applications Framework adressiert kaskadierende Ausfälle und abtrünnige Agents, schreibt aber keine Observability-Anforderungen für Multi-Agent-Delegationsketten vor.⁸ Die Lücke ist strukturell: Jeder Agent in der Kette bräuchte seine eigene Ressourcenmessung, Richtliniendurchsetzung und sein eigenes Laufzeit-Auditing, jeweils unabhängig konfiguriert und unabhängig berichtet. Der Overhead ist multiplikativ. Drei Monitoring-Ebenen auf drei Agents in einer Kette ergeben neun Monitoring-Instanzen, jede mit eigener Telemetrie, jede mit eigener Konfiguration. Kein existierendes Tool verwaltet diese Koordination.

Was Sie heute implementieren können

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

1. Ressource: Token-Budget-Tracker. Protokollieren Sie kumulative Input- und Output-Tokens pro Session. Setzen Sie ein hartes Limit. Warnen Sie bei 80 %. Die Implementierung erfordert das Auslesen der Nutzungsstatistiken des Agents (Claude Code gibt Session-Kosten über /cost aus) und den Vergleich mit einem Schwellenwert. Mein Cost-Gate-Hook macht das in 47 Zeilen Bash.⁵

2. Richtlinie: PreToolUse-Deny-List. Erstellen Sie einen Hook, der vor jedem Bash-Tool-Call feuert. Prüfen Sie den Befehl gegen eine Liste von Mustern: rm -rf /, git push --force, Pfade mit .ssh oder .env, curl | sh. Blockieren Sie Treffer. Die Implementierung erfordert ein Shell-Skript, das stdin liest (den Tool-Call als JSON), das Befehlsfeld extrahiert und gegen eine Musterdatei grept. Mein Credential-Checking-Hook macht das in 31 Zeilen.²

3. Audit: PostToolUse-Session-Log. Hängen Sie jeden Tool-Call und jedes Ergebnis an eine sitzungsspezifische JSONL-Datei an. Fügen Sie Zeitstempel, Tool-Name, Argumente und Exit-Code hinzu. Das Log ermöglicht die Rekonstruktion nach der Session: Was hat der Agent getan, in welcher Reihenfolge, und ist etwas stillschweigend fehlgeschlagen? Mein Session-Logger macht das in 22 Zeilen Bash.²

Ein ausgearbeitetes Beispiel des Deny-List-Hooks in settings.json:

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

Das Hook-Skript liest den Tool-Call von stdin, extrahiert den Befehls-String und prüft gegen Muster. Ein blockierter Befehl gibt ein JSON-Objekt mit {"decision": "block", "reason": "Sensitive path access denied"} zurück. Ein erlaubter Befehl gibt {"decision": "approve"} zurück. Claude Code respektiert beide Antworten ohne weitere Rückfragen. Der gesamte Hook fügt bei genehmigten Befehlen null Latenz hinzu (die Regex-Prüfung läuft in unter 5 ms) und bietet sofortiges Feedback bei blockierten.

Diese drei Hooks umfassen insgesamt 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 darauffolgende Governance-Entscheidung. Sie können kein Ressourcenbudget ohne Messung setzen. Sie können keine Scope-Richtlinie ohne Deny-List durchsetzen. Sie können keinen Vorfall ohne Audit-Log untersuchen. Beginnen Sie mit dem Log. Die anderen zwei folgen.

Kernerkenntnisse

Für Plattform-Ingenieure: Agents verbrauchen Ressourcen, die bestehendes Monitoring nicht erfasst. Festplatten-, Arbeitsspeicher-, CPU- und Netzwerknutzung pro Agent-Session gehören auf dasselbe Dashboard wie Container-Metriken. Der Cowork-Vorfall beweist die Notwendigkeit: 10 GB allokiert mit null Betreiber-Sichtbarkeit.

Für Sicherheitsteams: Richtliniendurchsetzung an der Tool-Call-Grenze ist die minimal tragfähige Agent-Sicherheitsposition. Der zentralisierte Ansatz von mcp-firewall konsolidiert per-Agent Allow/Deny-Logik in eine einzige, prüfbare Konfiguration. Evaluieren Sie, ob die eingebauten Berechtigungen Ihres Agents den Richtlinienraum abdecken, den Ihr Bedrohungsmodell erfordert.

Für Engineering-Manager: Stellen Sie drei Fragen zu Ihren Agent-Tools: Können Sie den Ressourcenverbrauch pro Session sehen? Können Sie Tool-Call-Richtlinien definieren und prüfen? Können Sie rekonstruieren, was ein Agent im Nachhinein getan hat? Wenn eine Antwort „nein” lautet, haben Sie eine Sichtbarkeitslücke, die mit jedem weiteren Agent in Ihrem Workflow wächst.

FAQ

Was ist Agent-Observability? Agent-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 durchführt und ob diese Aktionen mit definierten Richtlinien übereinstimmen.

Warum hat Cowork von Anthropic eine 10-GB-VM erstellt? Die Cowork-Funktion in Claude Desktop stellt eine virtuelle Maschine für kollaborative Entwicklungssitzungen bereit. Claude Desktop erstellt das VM-Bundle automatisch auf jeder macOS-Installation, auch für Benutzer, die die Funktion nie aktivieren, und behält es bei, bis es manuell gelöscht wird.¹

Was ist mcp-firewall? mcp-firewall ist ein Open-Source-Tool zur Richtliniendurchsetzung, das Tool-Use-Anfragen von CLI-Agents (Claude Code, GitHub Copilot CLI) abfängt und gegen regex-basierte Allow/Deny-Regeln evaluiert, bevor sie ausgeführt werden.⁷

Was ist eBPF-Laufzeit-Auditing? eBPF (extended Berkeley Packet Filter) ermöglicht Kernel-Level-Tracing von Systemaufrufen, ohne den auditierten Prozess zu modifizieren. Tools wie Logira verwenden eBPF-Probes, um Prozessausführung, Dateioperationen und Netzwerkverbindungen während KI-Agent-Läufen aufzuzeichnen.⁹

Wie starten Agents Sub-Agents ohne Sichtbarkeit für den Betreiber? Agents, die Aufgaben delegieren, starten Kindprozesse mit frischen Kontextfenstern. Der Eltern-Agent sieht die endgültige Ausgabe des Kindes, aber nicht dessen einzelne Tool-Calls, Dateilesevorgänge oder Ressourcenverbrauch. Bei jedem Delegationsschritt wird Information komprimiert: Die vollständige Session des Enkels wird zu einer einzeiligen Statusmeldung im Log des Eltern-Agents. Observability degradiert mit derselben Rate, wie die Delegationstiefe zunimmt.²

Wie unterscheidet sich Agent-Monitoring von traditionellem APM? Traditionelles Application Performance Monitoring (APM) verfolgt Anfrage-Latenz, Fehlerraten und Durchsatz für deterministische Software. Agent-Monitoring verfolgt nicht-deterministisches Verhalten: was der Agent zur Laufzeit zu tun entschied, ob diese Entscheidungen innerhalb der Richtlinien lagen und welche Ressourcen jede Entscheidung verbrauchte. APM geht davon aus, dass die Anwendung einem bekannten Codepfad folgt. Agent-Monitoring geht davon aus, dass der Agent seinen eigenen Pfad wählt.²

Quellen