KI-Agenten sind in den letzten Monaten ziemlich schnell zum festen Arbeitswerkzeug geworden. Claude Code schreibt und refactored Code, Claude Cowork durchsucht Daten und Tabellen, baut Präsentationen und ruft dabei auch Tools und MCP-Server auf. Mit all den Vorteilen kommen auch die Risiken: Claude liest Dateien, führt Bash-Befehle aus, spricht mit Schnittstellen. Und das meiste davon passiert, ohne dass irgendjemand zuschaut.

Genau das wollten wir gemeinsam mit unserem Kunden ändern. Hier kommt die etwas längere Geschichte, warum man so etwas überhaupt überwachen sollte und wie wir die Telemetrie von Claude im Falcon Next-Gen SIEM auswerten.

Warum wir KI-Agenten über die Schulter schauen

Ein Agent, der Dateien öffnen, Skripte starten und über MCP-Server mit halb der Infrastruktur reden kann, eröffnet eine neue Angriffsfläche.

Ein paar Szenarien, die wir konkret im Kopf hatten:

• Datenabfluss: Welche Dateien fasst der Agent an, und welche Daten kippen die Mitarbeiter eigentlich in ihre Prompts und Uploads?
• Auffälliges Verhalten: Wenn das Verhalten des Agents in eine bedenkliche Richtung driftet.
• Incident-Untersuchung: Wenn doch mal was schiefgeht, will man rekonstruieren können, was der Agent auf welche Eingabe hin getan hat.
• Kosten & Nutzung: Kein direkter Security Use-Case, aber trotzdem interessant. Welche Modelle werden genutzt, wie hoch sind die Kosten?

Kurz: Ein KI-Agent ist heute näher an einem privilegierten Service-Account als an einem Chatbot. Und Service-Accounts loggt man.

Claude liefert die Telemetrie

Was die Sache deutlich angenehmer macht: Anthropic hat hier gut vorgearbeitet. Claude Cowork (und vergleichbar auch Claude Code) kann seine Aktivität als OpenTelemetry bereitstellen. Und die Datengrundlage ist wirklich stark:

• Die kompletten Benutzereingaben:
  Also den Prompt-Text, den jemand an Cowork schickt.
• Jeden Tool- und MCP-Aufruf:
  Inklusive MCP-Servername, Tool-Name, übergebenen Parametern, Erfolg oder Fehler und der Ausführungszeit.
• Sämtliche Dateizugriffe
  Jeder Pfad, den Claude liest, ändert oder anderweitig anfasst, egal ob lokal im Sandbox-Ordner oder über einen MCP.
• Skills und Plugins
  Die in einer Session aufgerufen werden.
• Die Genehmigungsentscheidungen
  Ob eine Aktion vom Nutzer freigegeben, abgelehnt oder automatisch über bestehende Berechtigungen ausgelöst wurde.
• API-Details pro Anfrage
  Modell, Token-Zahlen, geschätzte Kosten, Dauer und etwaige Fehler.

Ein Hinweis, der wichtig ist und schnell untergeht: Prompt-Inhalte, Tool-Parameter und Benutzer-E-Mail-Adressen sind in den Events enthalten. Wer die Daten Claude anvertraut, sollte in der Regel kein Problem damit haben, diese auch dem Security Tooling (Hier CrowdStrike) zur Verfügung zu stellen.

Das Problem: Falcon unterstützt (noch?) kein OTel

In der offiziellen Claude Doku werden als kompatible Ziele Dinge wie Splunk, Cribl, Elasticsearch, Loki, ClickHouse, Honeycomb oder Datadog genannt. CrowdStrike Falcon Next-Gen SIEM taucht dort nicht auf, weil OTel derzeit nicht unterstützt wird. Mit Onum könnte man eine entsprechende Pipeline bauen, aber kurzfristig ein Lizenz-Upgrade und Onum Projekt durchzuführen war keine Option. Ebenso sollte die Anbindung ohne zusätzlichen Invest von Ressourcen auf Kundenseite erfolgen.

OTEL Pipeline as a Service

Um die Daten nun von Claude an CrowdStrike zu senden, stellen wir eine OTEL Pipeline bereit. Die Einrichtung auf Claude-Seite ist erfreulich unspektakulär: In den Organisationseinstellungen unter Cowork den OTLP-Endpunkt eintragen, die Auth-Header setzen, fertig. Ab da fließen die Events in unser Rechenzentrum.

Dort verarbeiten wir die OTEL-Telemetrie von Claude und konvertieren sie, sodass der Log Collector diese annimmt und an das SIEM weiterreicht. Damit landet jedes Prompt-, Tool-, Datei- und API-Event als strukturierter Log-Eintrag genau dort, wo der Rest des Security-Monitorings ohnehin schon zusammenläuft.

Wir übernehmen dabei den gesamten Betrieb der notwendigen Infrastruktur und stellen ergänzend den notwendigen Parser und Dashboards bereit.

Claude SIEM Cockpit

Logs im SIEM sind schön, aber erst Dashboards machen sie für Menschen brauchbar. Wir haben unserem Kunden ein Claude Cockpit erstellt, welches ihm unterschiedliche Einblicke in die Claude Telemetrie ermöglicht:

1. General Usage

Der FinOps- und Überblicks-Layer. Auf einen Blick: Total Spend über den gewählten Zeitraum, eine Aufschlüsselung von Kosten und Token-Verbrauch pro Nutzer (inkl. Input-/Output-Tokens, Cache-Nutzung und API-Requests) und die Modellverteilung: bei unserem Kunden grob ein Drittel claude-opus-4-8, dazu opus-4-7, sonnet-4-6 und haiku-4-5. Plus zwei Zeitreihen für kumulierte und stündliche Kosten, damit man Ausreißer schnell sieht. Nützlich, um Nutzung und Budget im Griff zu behalten und um die eine Person zu finden, die das teure Modell für jede Kleinigkeit anwirft.

2. Prompt Monitoring

Prompt-History, hochgeladene Dateien, Verteilung nach Dateityp: die Ansicht, mit der man sieht, welche Daten die Leute dem Agenten anvertrauen. Wie sensibel das ist, sieht man schon am Screenshot: Wir mussten ihn so weit schwärzen, dass kaum etwas übrig blieb.

3. Security

Das SOC-Dashboard. User File Access zeigt, welcher Nutzer mit welchem Tool welche Datei angefasst hat. Sensitive File Access filtert das auf die Pfade, die als kritisch markiert sind. Und ganz unten: Suspicious Bash Commands.

Fazit

Die eigentliche Erkenntnis ist unspektakulär: Ein KI-Agent ist heute ein loggenswerter Akteur im System, und Claude macht es einem dankenswert leicht, weil die Telemetrie schon als sauberes OTLP rausfällt.

Das Ergebnis: Prompts, Tool-Aufrufe, Dateizugriffe und verdächtige Befehle laufen jetzt im zentralen Datalake / SIEM mit Dashboards, die sowohl der Security- als auch der Finanzabteilung etwas sagen.

‍