Claude Code/Cowork-Überwachung im großen Stil mit Otel & Elastic

Da KI-Programmierassistenten immer mehr zu Standardwerkzeugen in Entwicklungsabläufen werden, stehen Sicherheitsteams vor einer neuen Herausforderung: Wie behält man den Überblick darüber, was ein KI-Agent im gesamten Unternehmen tut (und warum)? Wenn diese Agenten Shell-Befehle ausführen, Dateien lesen, APIs aufrufen und über MCP-Konnektoren mit internen Systemen interagieren können, benötigen Sie Echtzeit-Beobachtbarkeit, um Bedrohungserkennung, Reaktion auf Vorfälle und Compliance zu unterstützen.

Dieser Beitrag beschreibt, wie das InfoSec-Team von Elastic eine Monitoring-Pipeline für Claude Code und Claude Cowork mithilfe ihrer nativen OpenTelemetry (OTel) -Exportfunktionen und der eigenen OTel-Ingestionsinfrastruktur von Elastic aufgebaut hat. Wir behandeln das Telemetrieschema, die Gateway-Bereitstellung, benutzerdefinierte Elasticsearch-Mappings und Ingest-Pipelines, die verwaltete Konfigurationsbereitstellung sowie die durch diese Daten ermöglichten Sicherheitsanwendungsfälle.

Warum das InfoSec-Team von Elastic KI-Agenten überwacht

Bei Elastic praktizieren wir das, was wir „Customer Zero“ nennen. Das InfoSec-Team ist der erste und anspruchsvollste Nutzer der Produkte von Elastic und setzt in der Produktion stets die neuesten Versionen ein. Unser Ziel ist es, unsere Sicherheitslage wann immer möglich mit unseren eigenen Produkten zu verbessern.

Claude Code und Cowork werden mittlerweile in der gesamten Entwicklungsabteilung von Elastic aktiv genutzt. Claude Code läuft lokal auf den Entwicklerrechnern als CLI-basierter KI-Codierungsassistent. Cowork ist Teil der Claude Desktop-App und läuft auch lokal. Es kann Dateien lesen, Code in einer Sandbox ausführen, im Web suchen und über MCP-Konnektoren mit verbundenen Diensten wie Slack, GitHub, Jira und Google Calendar interagieren. Beide Tools unterstützen die Anbindung an interne Systeme, was bedeutet, dass sie in einem Vertrauensbereich operieren, der von den Sicherheitsteams überwacht werden muss.

Was Claude Code und Cowork über OpenTelemetry exportieren

Beide Produkte exportieren Telemetriedaten über die Standardprotokolle von OpenTelemetry und geben dabei dieselben fünf Ereignistypen aus:

api_request — Modell, Kosten, Tokenanzahl, Latenz
tool_result — Toolname, MCP-Server- und Toolname, Erfolg/Fehler, Dauer
tool_decision — automatisch genehmigt vs. benutzergenehmigt
user_prompt — was der Nutzer den Agenten gebeten hat zu tun
api_error — Fehlermeldung, Statuscode

Jedes Ereignis beinhaltet die Benutzeridentität (user.email, organization.id), den Sitzungskontext (session.id, prompt.id, event.sequence) und die Kosten-/Token-Felder bei API-Anfrageereignissen. Die Claude Code-Telemetrie ist optional und unterdrückt standardmäßig Eingabeaufforderungen und Tool-Argumente; aktivieren Sie sie mit OTEL_LOG_USER_PROMPTS=1 und OTEL_LOG_TOOL_DETAILS=1. Cowork wird zentral im Anthropic-Adminportal konfiguriert und enthält automatisch alle Details.

Das vollständige Telemetrieschema finden Sie in der Dokumentation zu Claude Code Monitoring und in der Dokumentation zu Claude Cowork Monitoring.

Architektur: Daten zu Elasticsearch übertragen

Es gibt zwei Möglichkeiten, Claude Code- und Cowork OTel-Daten in Elasticsearch zu importieren. Wir haben zunächst den Ansatz des selbstverwalteten Gateways implementiert, aber Elastic Cloud-Benutzer haben eine einfachere Option.

Option 1: EDOT OTel Gateway (selbstverwaltet)

Dies ist die Vorgehensweise, die wir intern angewendet haben. Da das InfoSec-Team von Elastic selbstverwaltete ECK-Cluster (Elastic Cloud on Kubernetes) betreibt, haben wir eine Elastic Distribution of the OpenTelemetry Collector (EDOT) als Gateway eingesetzt. Sowohl Claude Code als auch Cowork laufen lokal auf den Benutzerrechnern und senden OTLP/HTTP an das Gateway, das die Anfrage authentifiziert und in Elasticsearch schreibt.

Wir verwendeten das Helm-Chart opentelemetry-collector mit dem EDOT-Collector-Image (docker.elastic.co/elastic-agent/elastic-otel-collector). Das EDOT-Image bietet natives Elastic-Datenstrom-Routing, was wichtig ist, um Protokolle ohne zusätzliche Konfiguration in die richtigen Datenströme zu leiten.

Das Gateway läuft im Deployment-Modus und verwendet Bearer-Token-Authentifizierung über die bearertokenauth -Erweiterung.

Hier ist die Kernkonfiguration des Collectors:

config:
  extensions:
    bearertokenauth:
      scheme: "Bearer"
      token: "${env:OTEL_GATEWAY_TOKEN}"
  receivers:
    otlp:
      protocols:
        http:
          endpoint: "0.0.0.0:4318"
          auth:
            authenticator: bearertokenauth
  processors:
    transform/route:
      log_statements:
        - context: log
          conditions:
            - resource.attributes["service.name"] == "claude-code"
          statements:
            - set(resource.attributes["data_stream.dataset"], "claude_code")
        - context: log
          conditions:
            - resource.attributes["service.name"] == "cowork"
          statements:
            - set(resource.attributes["data_stream.dataset"], "claude_cowork")
  exporters:
    elasticsearch:
      endpoints: ["https://your-elasticsearch:9200"]
      user: "${env:ES_USERNAME}"
      password: "${env:ES_PASSWORD}"
  service:
    extensions: [bearertokenauth]
    pipelines:
      logs:
        receivers: [otlp]
        processors: [transform/route]
        exporters: [elasticsearch]

Option 2: Elastic Cloud Managed OTLP Endpoint (kein Gateway erforderlich)

Wenn Sie Elastic Cloud (Serverless oder Hosted) nutzen, können Sie das Gateway komplett überspringen. Der Managed OTLP (mOTLP)-Endpunkt von Elastic bietet eine robuste, automatisch skalierende Aufnahmeschicht, die OTLP-Daten direkt akzeptiert – es muss keine Collector-Infrastruktur bereitgestellt oder gewartet werden.

Um es zu verwenden, verweisen Sie den OTLP-Exporter von Claude Code direkt auf Ihren Elastic Cloud mOTLP-Endpunkt:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_LOGS_EXPORTER=otlp
export OTEL_METRICS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT="https://<your-motlp-endpoint>"
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=ApiKey <your-api-key>"
export OTEL_RESOURCE_ATTRIBUTES="data_stream.dataset=claude_code"

Das Ressourcenattribut data_stream.dataset ist hier wichtig; es steuert, welcher Datenstrom die Protokolle empfängt. Ohne diese Einstellung landen die Daten in einem generischen OTel-Datenstrom, in dem Ihre benutzerdefinierten Indexvorlagen und Datenaufnahmepipelines nicht anwendbar sind. Stellen Sie es auf claude_code oder claude_cowork ein, damit die Daten mit den korrekten Feldzuordnungen an die entsprechenden logs-claude_code.otel-* oder logs-claude_cowork.otel-* Streams weitergeleitet werden.

Mit mOTLP erhalten Sie native OTLP-Erfassung mit automatischem Datenstrom-Routing, einen integrierten Fehlerspeicher zum Schutz der Daten bei Indizierungsproblemen und benötigen keinen APM-Server.

Der verwaltete Endpunkt unterstützt alle unten beschriebenen benutzerdefinierten Indexvorlagen und Ingest-Pipelines; Sie müssen lediglich das Gateway nicht betreiben.

Ausführliche Informationen zur Einrichtung finden Sie in der Dokumentation zu Elastic Cloud Managed OTLP.

Benutzerdefinierte Elasticsearch-Mappings und Ingest-Pipelines

Standardmäßig werden OTel-Attribute in Elasticsearch als Schlüsselwörter indexiert. Das funktioniert zwar für Filterung und Gruppierung, aber es funktioniert nicht für numerische Aggregationen. Ein Schlüsselwortfeld kann nicht summiert oder gemittelt werden. Wir haben benutzerdefinierte Zuordnungen erstellt, um die Feldtypen zu korrigieren, und eine Ingest-Pipeline, um JSON-Zeichenfolgenfelder in strukturierte Objekte zu parsen.

Komponentenvorlage

Die Komponentenvorlage überschreibt die Standard-Schlüsselwortzuordnungen für numerische und boolesche Felder und fügt flattened -Typzuordnungen für die JSON-codierten Werkzeugparameter hinzu:

PUT _component_template/logs-claude_code.otel@custom
{
  "template": {
    "mappings": {
      "properties": {
        "cost_usd":                  { "type": "float" },
        "duration_ms":               { "type": "long" },
        "input_tokens":              { "type": "long" },
        "output_tokens":             { "type": "long" },
        "cache_creation_tokens":     { "type": "long" },
        "cache_read_tokens":         { "type": "long" },
        "prompt_length":             { "type": "long" },
        "tool_result_size_bytes":    { "type": "long" },
        "success":                   { "type": "boolean" },
        "tool_parameters_flattened": { "type": "flattened" },
        "tool_input_flattened":      { "type": "flattened" }
      }
    }
  }
}

Der Typ flattened ist hier wichtig. tool_parameters und tool_input werden als JSON-Zeichenketten mit verschachtelten Schlüsseln wie mcp_server_name, mcp_tool_name, bash_command oder command empfangen. Durch die Aufteilung in flattened Felder können Sie einzelne Schlüssel abfragen, ohne eine unbegrenzte Anzahl zugeordneter Felder zu erstellen.

Eine zukünftige Verbesserung wird darin bestehen, aus diesen JSON-Nutzdaten besonders wertvolle Felder in dedizierte zugeordnete Felder zu extrahieren – beispielsweise MCP-Servernamen, Toolnamen und Bash-Befehle –, um direkt auf diesen Werten umfassendere Analysen, Aggregationen und Erkennungsregeln zu ermöglichen.

Indexvorlage

Die Indexvorlage setzt sich aus allen Standard-OTel-Komponentenvorlagen sowie unserer benutzerdefinierten Vorlage zusammen. Es entspricht sowohl logs-claude_code.otel-* als auch logs-claude_cowork.otel-* , sodass beide Datenströme die gleichen Feldzuordnungen verwenden:

PUT _index_template/logs-claude_code.otel
{
  "index_patterns": [
    "logs-claude_code.otel-*",
    "logs-claude_cowork.otel-*"
  ],
  "composed_of": [
    "logs@mappings",
    "logs@settings",
    "otel@mappings",
    "otel@settings",
    "logs-otel@mappings",
    "semconv-resource-to-ecs@mappings",
    "logs@custom",
    "logs-otel@custom",
    "logs-claude_code.otel@custom",
    "ecs@mappings"
  ],
  "priority": 150,
  "data_stream": {},
  "allow_auto_create": true,
  "ignore_missing_component_templates": [
    "logs@custom",
    "logs-otel@custom"
  ]
}

Ingest pipeline (Ingest-Pipeline)

Die Ingest-Pipeline analysiert tool_parameters und tool_input aus JSON-Strings und wandelt sie in Objekte um, wobei die Werte in separate *_flattened -Zielfelder geschrieben werden, um Konflikte mit den ursprünglich per Schlüsselwortzuordnung festgelegten Attributen zu vermeiden:

PUT _ingest/pipeline/logs-claude_code.otel@custom
{
  "description": "Parse JSON string fields in Claude Code/Cowork OTel telemetry",
  "processors": [
    {
      "json": {
        "field": "attributes.tool_parameters",
        "target_field": "tool_parameters_flattened",
        "if": "ctx.attributes?.tool_parameters != null && ctx.attributes.tool_parameters.startsWith('{')",
        "ignore_failure": true
      }
    },
    {
      "json": {
        "field": "attributes.tool_input",
        "target_field": "tool_input_flattened",
        "if": "ctx.attributes?.tool_input != null && ctx.attributes.tool_input.startsWith('{')",
        "ignore_failure": true
      }
    }
  ]
}

Nach der Erstellung aller drei Ressourcen verfügen neue Daten, die in die Datenströme logs-claude_code.otel-* und logs-claude_cowork.otel-* fließen, über korrekte numerische Feldtypen und durchsuchbare strukturierte Werkzeugparameter.

Telemetrieexport konfigurieren

Claude Code und Cowork sind unterschiedlich konfiguriert. Claude Code verwendet standardmäßige OpenTelemetry-Umgebungsvariablen. Der Cowork OTel-Export wird zentral von Administratoren im Anthropic-Adminportal konfiguriert.

Claude Code unterstützt verwaltete Einstellungen , die von der IT-Abteilung bereitgestellt werden und von Benutzern nicht überschrieben werden können. Die Konfiguration ist eine JSON-Datei, die einen env -Block enthält:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_LOG_TOOL_DETAILS": "1",
    "OTEL_LOG_USER_PROMPTS": "1",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://your-otel-gateway:443",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer your-token"
  }
}

Diese verwaltete Einstellungsdatei kann über MDM (Jamf, Intune), serverseitig verwaltete Einstellungen über die Claude.ai-Administrationskonsole oder dateibasierte Bereitstellung bereitgestellt werden. Eine vollständige Liste der Zustellungsmechanismen und ihrer Sicherheitseigenschaften finden Sie in der Dokumentation zu den verwalteten Einstellungen von Claude Code .

Für lokale Tests können Sie die gleiche Konfiguration in ~/.claude/settings.json auf Ihrem eigenen Rechner einrichten, bevor Sie sie unternehmensweit ausrollen.

Coworking

Der Cowork OTel-Export wird zentral von Administratoren im Anthropic-Adminportal konfiguriert. Administratoren legen den OTLP-Endpunkt und die Authentifizierungsheader in der Administrationskonsole fest, und Cowork-Instanzen übernehmen die Konfiguration automatisch. Eingabeaufforderungsinhalte und Werkzeugdetails sind standardmäßig enthalten, ohne dass zusätzliche Optionen erforderlich sind.

Da Cowork in einer Sandbox ausgeführt wird, muss der OTel-Gateway-Endpunkt für ausgehenden Netzwerkzugriff aus der Sandbox-Umgebung auf die Zulassungsliste gesetzt werden. Ohne dies schlägt der Telemetrieexport stillschweigend fehl.

Sicherheitsanwendungsfälle

Die Kombination aus Ereignistypen, Identitätsfeldern und Werkzeugparametern schafft einen umfangreichen Datensatz für Sicherheitsoperationen. Hier sind die Anwendungsfälle, um die wir unsere Erkennungs- und Untersuchungsfähigkeiten herum aufbauen.

Überwachung der Toolaufrufe. Jeder Werkzeugaufruf wird mit Werkzeugnamen und Eingabeparametern protokolliert. Bei MCP-Tools umfasst dies den MCP-Servernamen und den Toolnamen (z. B. slack_send_message, github/search_issues). Sie können unautorisierte Datenzugriffe, ungewöhnliche Shell-Befehle oder unerwartete Interaktionen des MCP-Servers erkennen. Verwenden Sie die attributes.tool_name + attributes.tool_parameters Felder.

Sitzungsrekonstruktion. Das Feld session.id in Kombination mit event.sequence ergibt einen monoton steigenden Zähler innerhalb jeder Sitzung. Sie können den gesamten Ablauf einer Claude-Sitzung rekonstruieren: welche Fragen der Benutzer gestellt hat, welche Tools ausgeführt wurden, auf welche Daten zugegriffen wurde und welche APIs aufgerufen wurden. Dies ist wertvoll für die Reaktion auf Sicherheitsvorfälle – wenn Sie einen verdächtigen Tool-Aufruf feststellen, können Sie den vollständigen Sitzungskontext abrufen.

Genehmigungsentscheidungsanalyse. Die Ereignisse attributes.event.name: tool_decision geben Aufschluss darüber, wie die Verwendung der einzelnen Werkzeuge genehmigt wurde. Dies ermöglicht es Ihnen, Benutzer zu erkennen, die riskante Tool-Kategorien automatisch genehmigen, oder ungewöhnliche Berechtigungsmuster in der gesamten Tool-Flotte zu identifizieren.

Entscheidungsquelle	Bedeutung
`config`	Automatisch durch Einstellungen oder Richtlinien zugelassen
`hook`	Wird durch ein konfiguriertes Hook-Skript entschieden.
`user_temporary`	Der Nutzer hat diese Anfrage akzeptiert.
`user_permanent`	Der Benutzer hat für dieses Tool auf „Immer zulassen“ geklickt.
`user_abort`	Der Benutzer hat die Sitzung abgebrochen.
`user_reject`	Der Nutzer hat die Verwendung des Tools ausdrücklich abgelehnt.

Erkennung von Kostenanomalien. Das Feld cost_usd bei jedem api_request -Ereignis ermöglicht die Kostenverfolgung pro Anfrage, pro Sitzung und pro Benutzer. Sie können Warnungen bei ungewöhnlich teuren Sitzungen einrichten oder Benutzer mit überdurchschnittlich hohem Verbrauchsverhalten identifizieren.

Korrelation mit EDR-Daten. Wenn Sie Elastic Defend auf Ihren Endpunkten ausführen, können Sie die OTel-Telemetrie von Claude mit EDR-Prozess- und Dateiereignissen korrelieren, um sich ein umfassendes Bild zu verschaffen. Wenn Claude Code einen Bash-Befehl ausführt, teilt Ihnen das OTel tool_result -Ereignis mit, was der Agent ausführen wollte und warum (über das vorhergehende user_prompt). Das entsprechende Elastic Defend-Prozessereignis zeigt Ihnen genau an, was auf dem Host passiert ist – untergeordnete Prozesse wurden gestartet, Dateien geschrieben, Netzwerkverbindungen hergestellt. Durch die Verknüpfung dieser beiden Datenquellen über Zeitstempel und Host erhalten Sie in einer einzigen Untersuchung sowohl die Absicht (aus der Telemetrie des KI-Agenten) als auch die Auswirkungen (aus der Endpunkt-Telemetrie).

Überwachung des MCP-Serverzugriffs. Da Unternehmen KI-Agenten über MCP mit internen Systemen verbinden, wird die Überwachung, auf welche Server zugegriffen wird und mit welchen Tools, von entscheidender Bedeutung. Die Felder tool_parameters_flattened.mcp_server_name und tool_parameters_flattened.mcp_tool_name ermöglichen diese Sichtbarkeit.

Um beispielsweise die Tool-Aufrufe für Slack anzuzeigen, könnten Sie tool_name: "mcp_tool" AND tool_parameters_flattened.mcp_tool_name:slack* abfragen.

Jenseits von OTel: Claude-Unternehmensauditprotokolle

Die Telemetrie von Claude Code und Cowork erfasst die Agentenaktivitäten an den Endpunkten, aber nicht alles. Für vollständige Transparenz sollten Organisationen auch die Claude-Unternehmensaudit-Protokolle über die Compliance-API erfassen. Dies ist die einzige Quelle für Aktivitäten auf der Weboberfläche (claude.ai) und für traditionelle Sicherheitsauditereignisse wie Anmeldeaktivitäten, Berechtigungsänderungen und Administration auf Organisationsebene. Durch die Kombination beider Datenquellen erhalten die Sicherheitsteams ein vollständiges Bild über alle Claude-Produkte hinweg.

Fazit

KI-Programmierassistenten und autonome Agenten werden zu einem Bestandteil des Standard-Werkzeugkastens von Unternehmen. Wenn Ihr Sicherheitsteam keinen Einblick in die Funktionsweise dieser Tools hat, entsteht eine Sicherheitslücke. Claude Code und Cowork werden mit OpenTelemetry-Unterstützung ausgeliefert, die genau die Art von Telemetriedaten liefert, die Sicherheitsteams benötigen: Identität, Sitzungskontext, Details zum Toolaufruf, Kostendaten und Berechtigungsentscheidungen. Die nativen OTel-Ingestionsfunktionen von Elastic, sei es über den Managed OTLP-Endpunkt in der Elastic Cloud oder den EDOT Collector in einer selbstverwalteten Umgebung, ermöglichen es, diese Daten unkompliziert in Elasticsearch zu übertragen, wo sie durchsucht, Dashboards erstellt und Erkennungsregeln geschrieben werden können.

Wenn Sie loslegen möchten, melden Sie sich für eine kostenlose Testversion von Elastic Cloud an und probieren Sie den Managed OTLP-Endpunkt aus oder installieren Sie den EDOT OTel Collector in Ihrer bestehenden Umgebung.

Überwachung von Claude Code/Cowork im großen Maßstab mit OTel in Elastic