Claude Code telemetry exposes per-session AI usage and tool activity

At a glance

What this is: Bindplane says Claude Code can emit per-session OpenTelemetry data for cost, tokens, prompts, and tool activity, exposing a gap between available telemetry and what most teams actually observe.

Why it matters: IAM, security engineering, and AI governance teams need to treat AI coding tools as observable systems with controllable data flows, especially where tool output can contain sensitive commands or paths.

Context

Claude Code telemetry sits at the intersection of AI governance and operational visibility. The core issue is simple: if a tool is generating prompts, tool calls, and session metrics, but only aggregate dashboards are visible, teams cannot review usage, cost drivers, or sensitive activity at the level they actually need.

That gap matters for AI coding programmes because telemetry is itself governed data. Once prompts, tool results, file paths, or command output move into an observability pipeline, security teams have to decide who can see it, what gets redacted, and whether the collection path is centrally controlled. For AI-assisted development, the audit boundary now includes the telemetry pipeline itself.

Key questions

Q: What breaks when AI coding telemetry is only visible in aggregate dashboards?

A: Teams lose the ability to attribute usage, audit tool activity, and spot sensitive data flowing through prompts or tool results. Aggregate dashboards are useful for budgeting, but they are too coarse for governance. Per-session telemetry is the level needed to support security review, redaction, and accountable AI tool deployment.

Q: Why do per-session tool events create governance risk in AI coding workflows?

A: Because tool events can include commands, file paths, and other operational details that were never meant to leave the developer environment untouched. Once that data enters shared observability, it becomes a secondary exposure path. The risk is not the metric itself, but the lack of filtering and access control around it.

Q: How should teams govern prompt and tool telemetry from AI coding assistants?

A: Treat it like production telemetry with security sensitivity. Define approved destinations, redact fields that can reveal secrets or code structure, and use central policy so developers do not manage exports individually. Governance should cover collection, transport, retention, and access, not just the tool setting that turns telemetry on.

Q: What should security teams do before turning on AI coding telemetry org-wide?

A: Start with a pilot, verify the exact records being emitted, and confirm that redaction and routing behave as intended. Then decide whether prompt content should remain disabled, since even apparently routine telemetry can contain operational context. Enterprise rollout should follow validation, not precede it.

Technical breakdown

What Claude Code emits through OpenTelemetry

Claude Code exports metrics and logs to any OTLP endpoint, including per-session API cost, token usage, session counts, lines of code changed, user prompts, API requests, and tool results. That means the product is already instrumented as a telemetry-producing agentic workflow, not just an editor helper. The important design point is that the data is structured and machine-readable, so it can be routed, filtered, enriched, or suppressed before it reaches a backend. In practical terms, the security question is not how to add visibility, but how to govern the visibility already present.

Practical implication: Treat AI coding telemetry as a governed data stream and define where collection, filtering, and storage are allowed before rollout.

Why aggregate consoles miss the real control problem

Aggregate spend and token totals are useful for budgeting, but they do not answer the operational questions that matter in AI coding governance. Per-user and per-session telemetry shows which workflows are expensive, which developers are generating unusual activity, and which tools are being invoked against the codebase. That makes the telemetry boundary closer to audit logging than to simple product analytics. Where prompts and tool outputs can include commands or paths, the risk is not only cost leakage but also accidental disclosure through observability tooling. The control problem is therefore visibility with restraint, not visibility without limits.

Practical implication: Use session-level telemetry to support auditability, but apply redaction and access controls before exporting to shared observability systems.

Why administrator-managed deployment changes the governance model

If each developer configures export settings independently, telemetry governance fragments across endpoints and becomes difficult to enforce consistently. An administrator-managed settings file or centrally rolled-out collector makes telemetry policy part of the platform, not a local preference. That matters because telemetry controls are only reliable when they are deployable at scale, versioned, and reversible. In identity terms, the pattern resembles centralised policy for a machine identity: the collection endpoint, exporter settings, and redaction steps become the trusted control plane for the workflow. For AI coding programmes, the issue is lifecycle governance, not just instrumentation.

Practical implication: Centralise telemetry configuration so export targets, retention boundaries, and redaction rules can be governed like other production controls.

Threat narrative

Attacker objective: The objective is not a classic breach, but uncontrolled disclosure of sensitive development context through telemetry pipelines that were treated as benign.

1. Entry occurs when Claude Code sessions generate telemetry that can include prompts, tool results, and operational metadata about codebase activity.
2. Credential or sensitive-data exposure can follow if tool parameters contain bash commands, file paths, or other values that should not leave the developer environment unfiltered.
3. Impact occurs when those telemetry records are exported into shared observability systems without redaction, creating unnecessary exposure of code, workflow, or secret-adjacent context.

Breaches seen in the wild

• Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI coding telemetry is becoming part of the control surface: once prompts, tool results, and session metrics exist in the same pipeline as infrastructure and application telemetry, the governance question shifts from collection to stewardship. Teams must decide whether that data is operational observability, regulated development evidence, or both. The correct answer is usually all three, which means policy has to exist before rollout, not after a developer turns it on.

Session-level visibility is the missing layer in AI coding governance: aggregate spend data cannot explain who used a tool, what it touched, or whether the output included sensitive context. That creates a blind spot for AI-assisted development programmes that want auditability without over-collection. Session auditing gap: the absence of per-session governance leaves teams unable to separate productivity analytics from security-relevant activity. Practitioners should treat that as an architectural gap, not a reporting inconvenience.

Telemetry redaction now belongs in the same design conversation as secrets handling: tool results, file paths, and shell commands can carry more exposure than a simple prompt count suggests. If those fields leave the developer environment unfiltered, the observability layer becomes a secondary data exposure path. That makes telemetry pipelines part of the secure development boundary, especially where AI coding tools are approved across multiple teams.

Administrative control is the difference between local convenience and enterprise governance: AI coding tools that rely on per-user export settings will always be harder to govern than centrally managed deployments. This is the same pattern security teams have seen with secrets, agents, and other machine-driven workflows. The practitioner conclusion is clear: if the organisation cannot centrally govern the exporter, it cannot claim to govern the telemetry.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: AI Coding Agents Security Guide

What this signals

Session-level AI coding telemetry will become a governance baseline: organisations that adopt AI-assisted development will increasingly need per-session visibility, not just spend summaries. The operational question is whether teams can explain tool activity, redact sensitive fields, and centralise policy before telemetry becomes a shadow data stream.

Telemetry pipelines now deserve the same attention as secrets pipelines: if command output and file paths can flow into observability, the security team has to treat export, filtering, and retention as control points. That is especially true where AI coding tools are approved across multiple teams and the data leaves the developer boundary.

AI coding observability and NHI governance are converging: once an AI tool acts through a machine-like session with its own telemetry, the programme has to govern it more like a controlled non-human workflow than a simple desktop utility. The practical implication is to tie telemetry policy to identity, access, and redaction controls from the start.

For practitioners

• Define telemetry collection boundaries for AI coding tools Specify which Claude Code metrics and logs are permitted, which fields must be redacted, and which destinations are approved before enabling export.
• Route tool-result data through a redaction step Inspect claude_code.tool_result fields for commands, file paths, and secret-adjacent values, then remove or mask them before they reach shared observability systems.
• Manage exporter settings centrally Use an administrator-managed configuration so telemetry endpoints, protocols, and export flags are enforced consistently across developer machines.
• Pilot on one developer workstation first Verify that per-session telemetry is flowing, confirm the fields you expect, and only then expand the configuration to the wider team.

Key takeaways

• Claude Code telemetry exposes a gap between what is available for governance and what most teams actually inspect, because aggregate dashboards do not show session-level activity.
• Per-session prompts, tool calls, and tool results can reveal sensitive operational context, so the telemetry pipeline itself becomes part of the security boundary.
• The control that matters most is centralised routing with redaction, followed by constrained rollout and explicit policy for what may leave the developer environment.

Key terms

• Telemetry pipeline: A telemetry pipeline is the path security data follows from collection to analysis and retention. In mature environments it must preserve context, maintain throughput, and avoid introducing blind spots as sources, formats, and volumes change over time.
• Session-level telemetry: Security data captured from inside the browser session, such as logins, clipboard events, file transfers, extension changes, and OAuth consents. It is more useful than alert-only reporting because it preserves the context needed to explain how identity and data risks developed.
• Observability Redaction: Observability redaction is the removal or masking of sensitive fields before logs or metrics leave the source system. For AI tools, it is a control that prevents commands, file paths, and other sensitive details from becoming permanent records in shared monitoring platforms.
• Administrator-Managed Settings File: An administrator-managed settings file is a centrally controlled configuration mechanism used to enforce tool behaviour across many endpoints. In identity and security programmes, it reduces local variation by making collection targets, exporter flags, and policy choices consistent at scale.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It is a practical fit for practitioners who need to bring machine-driven workflows under policy control.