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

Anthropic lieferte eine Funktion namens Cowork in Claude Desktop aus. Die Funktion erzeugte ein 10 GB großes Virtual-Machine-Bundle auf jeder macOS-Installation. Benutzer, die Cowork nie aktiviert hatten, erhielten die VM trotzdem. Benutzer, die sie löschten, sahen sie sich regenerieren. Ein Benutzer meldete, 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 jetzt Rechenressourcen (Festplatte, Arbeitsspeicher, CPU, Netzwerk) ohne Sichtbarkeit für den Betreiber. Anthropics Cowork-VM ist das sichtbare Beispiel; jeder MCP-Tool-Aufruf, jeder erzeugte Sub-Agent und jeder Web-Fetch ist ein unsichtbares. Die Kontrolle von Agents erfordert drei Schichten 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 adressieren die Richtlinien- und Audit-Schichten (mcp-firewall und Logira), aber kein Produktivtool deckt alle drei ab. Im Folgenden: das Sichtbarkeitsproblem, der Drei-Schichten-Stack, was jede Schicht erkennt, und minimale Monitoring-Hooks, die Sie heute implementieren können.

Das Sichtbarkeitsproblem

Traditionelle Software arbeitet unterhalb einer Observability-Grenze, die Betreiber bewusst festlegen. Ein Webserver schreibt Zugriffsprotokolle, weil Entwickler 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 ausgeführt wird. Ein Coding-Agent, der „behebe den Login-Endpunkt” erhält, liest möglicherweise 47 Dateien, schreibt in 12, erzeugt drei Sub-Agents, ruft zwei Webseiten ab und führt 15 Bash-Befehle aus. Jede Aktion verbraucht Ressourcen. Nichts davon taucht im traditionellen Monitoring auf.

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

Skalieren Sie das Muster auf Agent-Sitzungen. Mein Hook-Orchestrierungssystem fängt 15 Ereignistypen über jeden Tool-Aufruf hinweg ab.¹¹ Über 60 Sitzungen hinweg protokollierte das System 84 Hooks, die bei jeder Aktion feuerten, und produzierte 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, die in meinem NIST-Kommentar dokumentiert sind, nicht erkannt.³

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 Testing Qualität, Lead Time und Gesamtzuverlässigkeit beeinflusst.”⁴ Agent-Observability ist kein Nice-to-have. Das Messen von Agent-Verhalten ist eine Voraussetzung für dessen Steuerung.

Drei Schichten der Agent-Sichtbarkeit

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

Die Schichten 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 auditieren, die Sie nie definiert haben. Jede Schicht baut auf der darunter liegenden auf.

Schicht 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 Festplattenspeicher. Der Renderer-Prozess verbrauchte im Leerlauf 24 % CPU. Die Swap-Aktivität stieg während der Sitzungen stetig an. All diese Metriken existierten im macOS Activity Monitor. Keine davon erschien in der Oberfläche von Claude Desktop.¹

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

Festplatte. Jeder Dateischreibvorgang, jeder Cache-Eintrag, jede Protokolldatei. Meine Sitzungen erzeugen 200–400 KB an Zustandsdateien pro Sitzung (jiro.state.json, jiro.progress.json, Hook-Protokolle). Über 60 Sitzungen hinweg akkumuliert das 12–24 MB an Zustandsdaten, die sitzungsübergreifend bestehen bleiben, sofern sie nicht explizit bereinigt werden.²

Arbeitsspeicher. Kontextfenster-Verbrauch pro Zug. Ein 200.000-Token-Kontextfenster kostet bei aktuellen Opus-Preisen etwa 3 $ pro vollständiger Füllung. Mein Kostentracker protokolliert den kumulativen Token-Verbrauch pro Sitzung mit Budget-Schwellenwerten 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), kumuliert sich aber über automatisierte Pipelines. Die ralph Autonomous Loop feuert den Dispatcher 50–100 Mal pro Story und fügt 10–20 Sekunden Hook-Overhead pro Story hinzu.²

Netzwerk. Web-Fetches, API-Aufrufe, 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 mit 5 KB unterscheidbar.⁶

Kein kommerzielles Agent-Tool bietet ein Ressourcen-Dashboard pro Sitzung. Cloud-Anbieter messen Compute für die Abrechnung, nicht für die Sichtbarkeit 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 Sitzung, die 400 KB an Zustandsdateien schreibt, ist nichts. Sechzig Sitzungen, die jeweils 400 KB schreiben, ohne Bereinigung, hinterlassen 24 MB verwaisten Zustand. Ein Web-Fetch, der 847 KB zurückgibt, ist vernachlässigbar. Eine Scanning-Pipeline, die 80 URLs pro Durchlauf abruft, erzeugt 67 MB an gecachtem 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.¹

Schicht 2: Richtliniendurchsetzung

Richtliniendurchsetzung beantwortet: Welche Regeln schränken den Agent ein, und werden diese Regeln konsistent angewandt?

mcp-firewall adressiert die Richtlinienschicht für CLI-Agents.⁷ Das Tool sitzt zwischen dem Agent und allen Tool-Use-Anfragen und bewertet jede Anfrage anhand einer Regex-basierten 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 über 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 Prefix-Only-Matching. Jeder Ansatz deckt eine Teilmenge des Richtlinienraums ab. mcp-firewall zentralisiert die Regeln in einer Engine, die agentübergreifend funktioniert.

Betrachten Sie die Richtlinienlücke ohne zentrale Durchsetzung. Mein Hook-System umfasst 12 PreToolUse:Bash-Handler, die auf Anmeldedatenmuster, 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 auditieren muss, welche Regeln existieren, grepe ich durch 12 Dateien. mcp-firewall konsolidiert das in einer einzigen Konfigurationsdatei mit expliziten Allow-Arrays.

Die OWASP Top 10 for 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 dennoch Tool-Aufrufe durch. Ein Agent mit übermäßiger Handlungsfähigkeit fordert dennoch 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, in den genehmigten Umfang?” 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 Wirkungsradius. Die Regex-Muster von mcp-firewall können zwischen ihnen unterscheiden. Standard-Agent-Berechtigungen können das nicht.

Schicht 3: Laufzeit-Auditing

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

Logira adressiert die Audit-Schicht mittels eBPF-Probes, die Systemaufrufe auf Kernel-Ebene abfangen.⁹ Das Tool zeichnet drei Ereigniskategorien auf: Prozessausführung (Exec-Events), Dateioperationen (einschließlich Zugriff auf Anmeldedatendateien) und Netzwerkverbindungen (mit Zielverfolgung). Jeder auditierte Durchlauf erzeugt drei Dateien: events.jsonl für die Zeitachsen-Überprüfung, index.sqlite für filterbares Abfragen und meta.json für Lauf-Metadaten.

Die Design-Philosophie ist „observe-only”: Logira zeichnet auf und erkennt, aber erzwingt oder blockiert nicht.⁹ Die Trennung von der Durchsetzungsschicht ist beabsichtigt. Richtliniendurchsetzung verhindert bekannte schädliche Aktionen. Laufzeit-Auditing entdeckt unbekannte schädliche Aktionen im Nachhinein. Die beiden Schichten dienen unterschiedlichen zeitlichen Funktionen: Prävention (vorher) und Forensik (nachher).

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

Eingebaute Erkennungsregeln zielen speziell auf KI-Agent-Risiken ab: Zugriff auf Anmeldedatendateien, Änderungen an Persistenzmechanismen (/etc, systemd, cron), verdächtige Befehlsketten (Curl-Pipe-sh-Muster), destruktive Operationen (rm -rf) und anomalen Netzwerk-Egress.⁹ Die Regeln sind meinungsstarke Standardwerte für das Agent-Bedrohungsmodell, nicht 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 eBPF-basiertes Auditing nicht nutzen. Meine OS-Sandbox verwendet macOS-Seatbelt-Profile als nächstliegendes Äquivalent: Kernel-durchgesetzte Deny-Regeln, die Schreibvorgänge auf sensible Pfade blockieren.³ Seatbelt ist Durchsetzung, nicht Auditing. macOS fehlt ein produktionsreifes Äquivalent zu Logiras Observe-Only-Audit-Trail.

Die Unterscheidung zwischen Durchsetzung und Auditing bildet eine zeitliche Aufspaltung in der Incident Response ab. Durchsetzung verhindert den Vorfall. Auditing ermöglicht die Rekonstruktion nach dem Vorfall. Beides ist notwendig. Eine Durchsetzungsschicht, die jeden Zugriff auf Anmeldedaten blockiert, verhindert Exfiltration, aber auch legitime SSH-Operationen. Eine Audit-Schicht, die jeden Zugriff auf Anmeldedaten protokolliert, ohne zu blockieren, ermöglicht es dem Betreiber, Zugriffsmuster zu überprüfen und Durchsetzungsregeln auf Basis von Evidenz anzupassen. Die Rückkopplungsschleife zwischen Audit-Daten und Richtlinienverfeinerung ist der Mechanismus, durch den sich der Visibility-Stack im Laufe der Zeit verbessert: Auditing enthüllt Muster, Muster informieren Richtlinien, Richtlinien reduzieren die Angriffsfläche, die das Audit abdecken muss.

Logiras cgroup-v2-Isolation fügt eine Fähigkeit hinzu, die Auditing auf Anwendungsebene nicht replizieren kann: laufbezogene Attribution. Das System ordnet jedes Ereignis einem bestimmten auditierten Lauf zu, nicht dem System global. Wenn zwei Agent-Sitzungen gleichzeitig auf derselben Maschine laufen, stellt die cgroup-Isolation sicher, dass Dateizugriffe in Sitzung A nicht im Audit-Trail von Sitzung B erscheinen. Hooks auf Anwendungsebene können dieselbe Garantie nicht bieten, da die Hooks innerhalb des Agent-Prozesses feuern, der keine Kernel-Level-Grenze zwischen gleichzeitigen Sitzungen hat.⁹

Was ich tatsächlich betreibe

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

Ressourcenmessung. Der Cost-Gate-Hook verfolgt den Token-Verbrauch pro Sitzung anhand konfigurierbarer Budget-Schwellenwerte.⁵ 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-Aufrufe und berechnet die Kosinusähnlichkeit zwischen dem Embedding des ursprünglichen Prompts und einem gleitenden Fenster kürzlicher Aktionen.²

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

Laufzeit-Auditing. PostToolUse-Hooks protokollieren jedes Tool-Call-Ergebnis. Die Sicherheits-Scanning-Hooks prüfen Bash-Ausgaben nach der Ausführung auf Anmeldedaten-Leaks. Sitzungszustandsdateien (jiro.state.json) zeichnen jede Story-Fertigstellung, jedes Reviewer-Urteil und jedes Evidence-Gate-Ergebnis auf.² Das System verwendet kein eBPF (macOS-Beschränkung), erfasst aber Tool-Level-Telemetrie über die Hook-Pipeline.

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

Der kumulative blinde Fleck

Agents, die Agents erzeugen, multiplizieren die Opazität. Jeder Delegationssprung führt zu Informationsverlust.

Wenn mein Orchestrierungssystem die ralph Autonomous Loop ausführt, erzeugt 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-Aufrufe, Dateizugriffe oder den Ressourcenverbrauch des Kind-Agents.²

Bei Tiefe eins (Eltern erzeugt Kind) sieht der Eltern-Agent die endgültige Ausgabe des Kind-Agents. Bei Tiefe zwei (Kind erzeugt Enkel) sieht der Eltern-Agent den Bericht des Kind-Agents über die Ausgabe des Enkel-Agents. Jeder Sprung komprimiert Informationen. Die Delegationskettenanalyse in meinem NIST-Kommentar maß drei kumulative 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 inspiziert hat).³

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

Ein konkretes Beispiel aus meinem Produktivsystem: Die Ralph-Loop erzeugte einen Kind-Agent zur Implementierung einer Datenbankmigrations-Story. Der Kind-Agent entschied, dass die Migration einen „Verifikationsschritt” benötigte, und erzeugte einen eigenen Sub-Agent, um Integrationstests auszuführen. Der Enkel-Agent schlug still 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: complete.” 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 Sprünge tief, unsichtbar für jede Monitoring-Schicht, die ich auf dem Root deployt hatte.²

Das OWASP-Framework für Agentic Applications behandelt kaskadierende Ausfälle und außer Kontrolle geratene Agents, schreibt aber keine Observability-Anforderungen für Multi-Agent-Delegationsketten vor.⁸ Die Lücke ist strukturell: Jeder Agent in der Kette bräuchte eigene Ressourcenmessung, Richtliniendurchsetzung und Laufzeit-Auditing, unabhängig konfiguriert und unabhängig berichtet. Der Overhead ist multiplikativ. Drei Schichten Monitoring 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 Visibility-Stack abdecken:

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

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

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

Ein ausgearbeitetes Beispiel des Deny-Listen-Hooks 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 den Befehlsstring 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ückfrage. Der gesamte Hook fügt genehmigten Befehlen null Latenz hinzu (die Regex-Prüfung läuft in unter 5 ms) und bietet sofortiges Feedback für blockierte.

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 folgende Governance-Entscheidung. Sie können kein Ressourcenbudget festlegen, ohne zu messen. Sie können keine Scope-Richtlinie durchsetzen, ohne eine Deny-Liste. Sie können keinen Vorfall untersuchen, ohne ein Audit-Protokoll. Beginnen Sie mit dem Protokoll. Die anderen beiden folgen.

Kernaussagen

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

Für Sicherheitsteams: Richtliniendurchsetzung an der Tool-Call-Grenze ist die minimale tragfähige Agent-Sicherheitsposition. Der zentralisierte Ansatz von mcp-firewall konsolidiert agentspezifische Allow/Deny-Logik in einer auditierbaren Konfiguration. Bewerten Sie, ob die eingebauten Berechtigungen Ihres Agents den Richtlinienraum abdecken, den Ihr Bedrohungsmodell erfordert.

Für Engineering-Manager: Stellen Sie drei Fragen zu Ihrem Agent-Tooling: Können Sie den Ressourcenverbrauch pro Sitzung sehen? Können Sie Tool-Call-Richtlinien definieren und auditieren? Können Sie rekonstruieren, was ein Agent im Nachhinein getan hat? Wenn eine Antwort „Nein” lautet, haben Sie eine Sichtbarkeitslücke, die mit jedem zusätzlichen 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 Anthropics Cowork 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 bei jeder macOS-Installation, auch für Benutzer, die die Funktion nie aktivieren, und behält es bis zur manuellen Löschung bei.¹

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 sie anhand Regex-basierter Allow/Deny-Regeln vor der Ausführung bewertet.⁷

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.⁹

Quellen