[Anthropic] Claude Code / Cowork Telemetry

[jamiehynds]

Description

Unlike the Claude Enterprise web product, Cowork and Claude Code activity is explicitly excluded from the Compliance API — confirmed across all plan tiers including Enterprise (as of May 2026, Cowork is excluded from Audit Logs, the Compliance API, and Data Exports; Claude Code is on a separate path entirely).

The supported route for session-level telemetry from these products is OpenTelemetry (OTel): both Claude Code and Cowork emit events via standard OTLP export. Elastic's InfoSec team has already built and documented a working pipeline for this (see the Security Labs post in references). This issue is about formalising that work as a native, installable integration rather than leaving it as a manual configuration exercise for every customer.

This is a meaningful security surface: agentic workflows in Claude Code and Cowork may involve shell execution, file-system access, MCP tool calls, and web browsing — all high-value signals for threat detection and compliance that are invisible to the Compliance API.

What this data does (and doesn't) give you

OTel is the only telemetry path for these products, so the integration's value is gated by what's exported and at what verbosity:

What the events expose:

• Tool execution — every tool call and MCP server call (tool_result): tool_name, tool_use_id, success, duration_ms, error_type, and the permission decision_source.
• Permission decisions (tool_decision) — how each call was approved/rejected and the source (config, hook, user_permanent, user_temporary, user_abort, user_reject).
• API usage & cost (api_request) — model, cost_usd, token counts (input/output/cache), duration_ms, MCP attribution.
• Session structure — session.id + event.sequence (monotonic per-session counter) + prompt.id (links every event triggered by one prompt) enable full session reconstruction.
• Identity/context — user.email, user.id, organization.id, terminal.type on every event.

What's redacted/gated by default (important):

• Prompt content — redacted unless OTEL_LOG_USER_PROMPTS=1.
• Tool parameters & input (bash commands, MCP server/tool names, skill names, tool args) — redacted unless OTEL_LOG_TOOL_DETAILS=1 (a separate gate from prompts). MCP server/tool visibility depends on this being set.
• Raw API request/response bodies — only with OTEL_LOG_RAW_API_BODIES (full conversation history; heavy).
• Claude Code redacts prompts and tool arguments by default; Cowork surfaces fuller detail automatically per the Security Labs configuration.

Scope & data boundaries

• OTel-native, not Agent-polled: this is a packaged set of templates + pipeline + dashboards that customers install once, applied to OTLP data — not a traditional polled-API datastream.
• The collector/gateway is infrastructure, not a shipped asset. The package ships ingest/mapping/dashboard assets; the OTLP collector path is documentation (see deployment options below).
• Complementary to the Compliance API datastream, not overlapping: the Compliance API covers claude.ai web interactions and admin/auth events; this OTel integration covers agentic tool execution and session telemetry from Claude Code and Cowork. Both are needed for full Claude fleet visibility.
• Two datasets, one package: claude_code and claude_cowork, routed via data_stream.dataset.

Why this matters

• Tool invocation auditing: every MCP server call and tool execution is logged with tool name, server name, and (with OTEL_LOG_TOOL_DETAILS=1) input parameters — surface unauthorized data access, unexpected shell commands, or MCP connections to unapproved internal systems.
• Session reconstruction: session.id + event.sequence gives a monotonic counter for complete session replay — critical for incident investigation and forensics.
• EDR correlation: combined with Elastic Defend endpoint telemetry, Claude's OTel events provide the intent (what the agent was asked to do) while EDR provides the impact (processes spawned, files written, network connections). Joining by timestamp and host produces materially richer investigations than either source alone.
• Permission-decision analysis: tool_decision source values expose how each call was approved — surface users auto-approving risky tool categories (user_permanent) or unusual permission patterns fleet-wide.
• Cost and usage anomaly detection: cost_usd and token counts on every api_request enable per-user, per-session spend tracking and anomaly alerting.
• MCP server access monitoring: the flattened mcp_server_name / mcp_tool_name fields show which internal systems agents call and with what operations.
• Compliance: demonstrate oversight of autonomous AI agents for regulated industries (DORA, EU AI Act, SOX).

Telemetry schema

Both products emit events via OTLP logs. Core event types:

Event (event.name)	Key fields
api_request	model, cost_usd, input_tokens, output_tokens, cache tokens, duration_ms, MCP attribution
tool_result	tool_name, tool_use_id, success, duration_ms, decision_source, tool_parameters/tool_input (gated)
tool_decision	tool_name, decision (accept/reject), source (config/hook/user_*)
user_prompt	prompt_length, command_name; prompt content gated by OTEL_LOG_USER_PROMPTS=1
api_error	error, status_code, attempt, model

Note: additional event types now exist beyond these five — api_refusal (stop_reason refusal) and the raw-body events api_request_body / api_response_body (only with OTEL_LOG_RAW_API_BODIES). Every event carries the standard attributes (session.id, organization.id, user.email, user.id, terminal.type), the prompt.id correlation attribute, and event.sequence / event.timestamp.

What needs to be built

Package assets to ship:

• Component template (logs-claude_code.otel@custom): override default keyword mappings for numeric fields (cost_usd, duration_ms, input_tokens, etc. as float/long) and add flattened mappings for tool_parameters_flattened and tool_input_flattened, so MCP server/tool names and bash commands are queryable without unbounded field explosion.
• Index template (logs-claude_code.otel): compose standard OTel component templates (otel@mappings, semconv-resource-to-ecs@mappings, etc.) plus the custom template above; match both logs-claude_code.otel-* and logs-claude_cowork.otel-*.
• Ingest pipeline (logs-claude_code.otel@custom): parse tool_parameters and tool_input from JSON strings into *_flattened fields; ignore failures gracefully.
• Dashboards: session timeline view, tool-call frequency by type and user, MCP server access heatmap, cost by user/session, permission-decision breakdown, admin configuration events.

Deployment paths (documentation, not shipped assets):

• Option A — Elastic Cloud (mOTLP, no gateway): point Claude Code's OTLP exporter directly at the Elastic Cloud Managed OTLP endpoint. Set data_stream.dataset=claude_code as a resource attribute so data routes to the correct data stream with the installed templates applied. No collector to operate.
• Option B — Self-managed (EDOT Collector): deploy the EDOT Collector as an OTLP gateway. Use the transform/route processor to set data_stream.dataset based on service.name (claude-code vs cowork). Supports bearer-token auth via the bearertokenauth extension. See the Security Labs post for a reference Helm configuration.

Telemetry configuration delivery:

• Claude Code: configured via CLAUDE_CODE_ENABLE_TELEMETRY=1, OTEL_EXPORTER_OTLP_ENDPOINT, and auth headers. For fleet rollout, use managed settings delivered via MDM (Jamf, Intune) or the Admin Console server-managed settings — these cannot be overridden by end users, which also locks in the OTEL_LOG_* verbosity gates.
• Claude Cowork: configured centrally in the Anthropic admin portal; instances pick up the OTLP endpoint automatically. Note: the gateway endpoint must be allowlisted for outbound access from the Cowork sandbox.

Sample event

⚠️ Illustrative sample. Attribute names follow the Claude Code monitoring docs; values are representative. A real captured event should be added during development. This shows a tool_result for an MCP call with OTEL_LOG_TOOL_DETAILS=1 enabled (so tool_parameters is populated) — the JSON string the ingest pipeline flattens into tool_parameters_flattened.

{
  "event.name": "tool_result",
  "event.timestamp": "2026-06-01T14:23:11.412Z",
  "event.sequence": 47,
  "session.id": "b2c3d4e5-6f70-4a1b-8c2d-3e4f5a6b7c8d",
  "prompt.id": "a1b2c3d4-5e6f-4071-9a2b-3c4d5e6f7081",
  "organization.id": "11112222-3333-4444-5555-666677778888",
  "user.email": "engineer@contoso.com",
  "user.id": "user_01H9XYZABCDEF",
  "terminal.type": "vscode",
  "tool_name": "mcp__github__create_issue",
  "tool_use_id": "toolu_01ABCdef456",
  "success": "true",
  "duration_ms": 842,
  "decision_type": "accept",
  "decision_source": "user_permanent",
  "tool_input_size_bytes": 312,
  "tool_result_size_bytes": 1840,
  "tool_parameters": "{\"mcp_server_name\":\"github\",\"mcp_tool_name\":\"create_issue\"}"
}

Key fields

Field	Description
user.email / organization.id	Who ran the tool, and in which org
session.id + event.sequence	Session identity and ordering for replay/forensics
prompt.id	Ties this event to the prompt that triggered it
tool_name / tool_use_id	The tool invoked and its unique call id
decision_source	How the call was approved (user_permanent = a standing auto-approve — a risk signal)
success / duration_ms	Outcome and execution time
tool_parameters (gated)	JSON string with mcp_server_name / mcp_tool_name (or bash command) — flattened by the ingest pipeline

Availability note: tool parameters appear only with OTEL_LOG_TOOL_DETAILS=1 and prompt content only with OTEL_LOG_USER_PROMPTS=1 — set these via managed settings during testing to validate the flattened-field mappings.

Access requirements

• Claude Code with telemetry enabled (CLAUDE_CODE_ENABLE_TELEMETRY=1) and/or Claude Cowork with OTLP configured in the Anthropic admin portal. An Enterprise plan is required for managed/server-side settings to enforce telemetry and verbosity gates fleet-wide.
• An OTLP destination: Elastic Cloud Managed OTLP endpoint (Option A) or a self-managed EDOT Collector gateway (Option B).
• Development requires Claude Code with telemetry exporting to a test Elastic cluster; a Cowork instance is needed to validate the claude_cowork dataset.

References

• Elastic Security Labs: Monitoring Claude Code/Cowork at scale with OTel in Elastic
• Claude Code Monitoring & Telemetry docs
• Claude Code Managed Settings
• Claude Cowork Monitoring docs
• Elastic Cloud Managed OTLP (mOTLP)
• EDOT Collector documentation

[infra-vault-gh-plugin-prod]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

[github-actions]

tl;dr: This looks like a real coverage gap (not a duplicate): anthropic_metrics currently ingests only Admin API usage/cost/rate-limit data, and explicitly says Claude Code/Cowork telemetry from the Enterprise Analytics API is not covered; I recommend implementing this as a new data stream in packages/anthropic_metrics.

Recommendation

Implement Claude Code/Cowork telemetry by adding a separate Enterprise Analytics telemetry data stream under packages/anthropic_metrics (instead of overloading existing usage/cost/rate_limit streams). This keeps API surfaces, field schemas, and dashboards cleanly separated.

Findings

• packages/anthropic_metrics/docs/README.md:14 explicitly states per-user/per-product telemetry (including Chat, Claude Code, Cowork) requires the Enterprise Analytics API and is currently not covered.
• Current endpoints are Admin API only:
  • packages/anthropic_metrics/data_stream/usage/agent/stream/cel.yml.hbs:16
  • packages/anthropic_metrics/data_stream/cost/agent/stream/cel.yml.hbs:16
  • packages/anthropic_metrics/data_stream/rate_limit/agent/stream/cel.yml.hbs:16
• Current documented datasets are only:
  • metrics-anthropic_metrics.usage-*
  • metrics-anthropic_metrics.cost-*
  • metrics-anthropic_metrics.rate_limit-*
    (packages/anthropic_metrics/docs/README.md:114-116)
• Grouping dimensions in existing streams do not provide a Claude Code/Cowork product telemetry surface (packages/anthropic_metrics/data_stream/usage/manifest.yml:33, packages/anthropic_metrics/data_stream/cost/manifest.yml:26).
• Recent related shipped work:
  • PR [New Integration] Anthropic audit logs #19174 added Anthropic compliance audit logs (packages/anthropic) via Compliance API.
  • PR Add anthropic_metrics package #19297 added Anthropic metrics (packages/anthropic_metrics) via Admin APIs.

Verification

I validated the above with repository commands:

$ grep -nE "Enterprise Analytics API|Claude Code|Cowork|currently not covered" packages/anthropic_metrics/docs/README.md
14:For per-user or per-product breakdowns (Chat, Claude Code, Cowork, etc.), the separate Enterprise Analytics API (`claude.ai/analytics/api-keys`) is required — that API is currently not covered by this integration.

$ grep -nE "/v1/organizations/(usage_report/messages|cost_report|rate_limits)" packages/anthropic_metrics/data_stream/*/agent/stream/cel.yml.hbs
packages/anthropic_metrics/data_stream/cost/agent/stream/cel.yml.hbs:16:resource.url: {{url}}/v1/organizations/cost_report
packages/anthropic_metrics/data_stream/rate_limit/agent/stream/cel.yml.hbs:16:resource.url: {{url}}/v1/organizations/rate_limits
packages/anthropic_metrics/data_stream/usage/agent/stream/cel.yml.hbs:16:resource.url: {{url}}/v1/organizations/usage_report/messages

$ grep -nE "metrics-anthropic_metrics\.(usage|cost|rate_limit)-\*" packages/anthropic_metrics/docs/README.md
114:- `metrics-anthropic_metrics.usage-*`
115:- `metrics-anthropic_metrics.cost-*`
116:- `metrics-anthropic_metrics.rate_limit-*`

$ grep -nE "group_by|Supported values|workspace_id and description" \
  packages/anthropic_metrics/data_stream/usage/manifest.yml \
  packages/anthropic_metrics/data_stream/cost/manifest.yml
packages/anthropic_metrics/data_stream/usage/manifest.yml:33:... Supported values include model, workspace_id, api_key_id, service_tier, context_window, inference_geo, and speed.
packages/anthropic_metrics/data_stream/cost/manifest.yml:26:... Supported values are workspace_id and description.

Detailed Action Plan

1. Create a new data stream in packages/anthropic_metrics/data_stream/ (e.g. enterprise_telemetry) dedicated to Enterprise Analytics API ingestion.
2. Add CEL collector config at agent/stream/cel.yml.hbs for the Analytics endpoint(s), with dedicated auth vars if required (do not reuse assumptions from Admin API without schema confirmation).
3. Define schema in fields/base-fields.yml and fields/fields.yml for product/user telemetry dimensions (including explicit product field values for Claude Code/Cowork where provided by API payload).
4. Build ingest normalization in elasticsearch/ingest_pipeline/default.yml (timestamp, dimension extraction, type coercion, ECS alignment).
5. Add test assets:
   • sample_event.json
   • pipeline test fixtures under _dev/test/pipeline/
   • system config under _dev/test/system/test-default-config.yml
6. Update package wiring/docs:
   • packages/anthropic_metrics/manifest.yml (new stream vars/policy template exposure)
   • _dev/build/docs/README.md and generated docs/README.md
   • dashboards under packages/anthropic_metrics/kibana/dashboard/ for telemetry views
   • changelog.yml + version bump in manifest.yml
7. Validate with package tests (elastic-package test) for the new stream and ensure existing streams stay unchanged.

Related Items

Type	Link	Relevance
PR	#19174	Added anthropic Compliance API audit integration; adjacent but different API surface
PR	#19297	Added anthropic_metrics Admin API usage/cost/rate-limit streams
File	packages/anthropic_metrics/docs/README.md:14	Explicitly states Claude Code/Cowork telemetry not covered
File	packages/anthropic_metrics/data_stream/usage/agent/stream/cel.yml.hbs:16	Admin API endpoint wiring
File	packages/anthropic_metrics/data_stream/cost/agent/stream/cel.yml.hbs:16	Admin API endpoint wiring
File	packages/anthropic_metrics/data_stream/rate_limit/agent/stream/cel.yml.hbs:16	Admin API endpoint wiring
Issue	#19400	Potentially related (not readable in this run due integrity policy gating)
Issue	#19399	Potentially related (not readable in this run due integrity policy gating)

Note

🔒 Integrity filter blocked 32 items

The following items were blocked because they don't meet the GitHub integrity level.

• #19407 issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #19407 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17818 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17817 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17381 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #18344 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17114 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17429 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #19399 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #19400 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #19399 issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #19400 issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #19277 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #19388 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #18927 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #19272 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• ... and 16 more items

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

---

What is this? | From workflow: Issue Triage

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[leandrojmp]

Hello @jamiehynds I have this working as a custom ingestion and can share my current pipeline if you want.

It may diverge from the Elastic approach as the first thing I did was remove any OTEL mapping to make things easier to parse.

[jamiehynds]

Would be a great help if you wouldn't mind sharing @leandrojmp

[leandrojmp]

@jamiehynds

Basically I rename the main otel fields attributes and resource into temporary fields _attributes and _resource so I can expand and parse them, there are multiple rename processors, some into ecs fields, others into custom fields.

I mostly use top-level field named claude or mcp so I can correlate with data from the other two ingestions I have for the compliance API and the chats (also coming from the compliance api).

The _attributes and _resource fields are mapped as flattened so I can see which new fields need parsing and also they populate the fields otel.attributes and otel.resource so I can query this using ESQL, in my experience Anthropic keeps changing this data and adding new fields, sometimes fields with different names have the same kind of information (e.g. error name and error type).

I'm sharing my custom ingest pipeline and the mapping to see if it helps.

sample-ingestion-claude.json
sample-mapping-claude.json

[Necmttn]

For the native integration, I would keep the ingest contract event-family-first instead of flattening everything into one Claude document shape.

Minimum data streams or typed event groups:

• api_request: model, token buckets, cache tokens, cost, duration, MCP attribution
• tool_result: tool name, MCP server, success, duration, error type
• tool_decision: decision source and allow/deny state
• hook_execution_*: hook name, event, latency, verdict

The shared join fields matter more than the final nesting style: session.id, prompt.id, event.sequence, trace/span ids when present, and service/harness identity. I would also retain the raw OTLP attribute map under a namespaced field for one release window so new Claude/Cowork attributes are not dropped while ECS mappings settle.

---

Generated with ax.

[efd6]

@jamiehynds, there are minor changes from the issue's approach.

Two packages instead of one. Fleet's OTel-aware template generation ties the package name into the data stream name. A package named claude_code with data stream events produces logs-claude_code.events.otel-*. There's no way to get two distinct OTel data streams (claude_code and claude_cowork) from a single package name. So this will be two packages: claude_code and claude_cowork, each with a single events data stream. The alternative is a single type: content package (like aws_cloudtrail_otel) where ES assets aren't auto-installed, but that means customers have to run Dev Tools API calls manually, and so we would have worse UX for a security integration.

Single data stream per package, not per event type. Responding to @Necmttn's suggestion of separate data streams for api_request, tool_result, tool_decision, etc. I'm keeping a single events data stream with event-type branching in the ingest pipeline. Splitting into per-event-type data streams would mean 4+ data stream manifests, field definitions, and index templates per package, with significant packaging complexity and no clear query benefit (ECS categorisation and event.action filtering give the same selectivity). The pipeline routes on event.name for ECS categorisation and handles unknown event types gracefully so new events from Anthropic don't get dropped.

Using otelcol input type, not manual templates. The issue describes shipping a component template (logs-claude_code.otel@custom) and index template manually. Since package-spec 3.6.0 (merged in package-spec#1091), type: integration packages can use otelcol as an input type. Fleet then handles OTel template composition automatically; it includes otel@mappings, semconv-resource-to-ecs@mappings, etc., sets default_pipeline, and creates the index template at priority 200. This is a better approach because everything is auto-installed and version-tracked by Fleet, but it means the asset names differ from what the issue describes. It also requires Kibana ^9.4.0. I think this is acceptable for a new integration but it's worth noting.

Data stream names change slightly. With the otelcol approach, Fleet auto-appends .otel to the dataset, so the data stream path is events (not otel, which would produce a double suffix). The resulting data streams are logs-claude_code.events.otel-default and logs-claude_cowork.events.otel-default. Users set data_stream.dataset=claude_code.events as an OTel resource attribute.

Schema is broader than the 5 events listed. The current Claude Code monitoring docs document 20+ event types, 8 metrics, and beta traces. The integration will cover all log event types (not just the 5 in the issue), with typed field overrides for numerics and flattened types for unbounded JSON. Metrics and traces are out of scope for v1.

Pipeline informed by @leandrojmp's sample. The sample pipeline and mapping from your comment confirmed the actual OTel document structure (fields nested under attributes.*, resource attributes under resource.attributes.*). The integration's pipeline will follow a similar approach: JSON-parse tool_parameters/tool_input into flattened fields, extract process.command_line, file.path, and MCP server/tool names for searchability. I'll also be capturing my own sample events locally for fixture diversity.

Two PRs. Planning to ship claude_code first as a proving ground (this is the first otelcol + ingest pipeline integration package in the repo), then claude_cowork as a derivative once the pattern is validated.

Let me know if any of this changes your thinking on scope or approach.