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

At a glance

What this is: This article shows that Claude Code emits detailed OpenTelemetry telemetry for sessions, costs, tokens, prompts, and tool calls, while the default console view remains only aggregated.

Why it matters: That matters because AI coding assistants are becoming operational systems that touch code, commands, and possibly secrets, so IAM, PAM, and security teams need visibility and control over what is being exported, redacted, and centrally governed.

By the numbers:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.

👉 Read Bindplane's how-to guide for sending Claude Code telemetry to Bindplane

Context

Claude Code telemetry is not just an observability detail. It is a governance problem because the same signals that help teams understand cost and usage can also expose commands, file paths, and other operational traces if they are exported without controls. In AI-assisted development, the boundary between productivity data and sensitive runtime data is thin, especially when code changes, shell execution, and prompt activity are all part of the same workflow.

For identity and access teams, the relevant issue is not whether Claude Code can emit telemetry. It is whether the organisation can govern who sees that telemetry, how long it is retained, and whether sensitive content is filtered before it reaches downstream systems. That makes the article relevant to machine identity, secrets handling, and administrator-managed deployment, not just to observability engineering.

Key questions

Q: How should security teams govern AI coding assistants that can execute commands?

A: Treat them as delegated non-human identities with bounded execution authority. Require human approval for destructive commands, keep command scopes narrow, and log every tool action. The key control question is not whether the assistant is helpful, but whether it can be prevented from acting outside intended scope when prompts, context, or rules are manipulated.

Q: Why is tool-result telemetry riskier than token or cost metrics?

A: Tool-result telemetry can include commands, file paths, and other runtime parameters that expose repository context or secrets-adjacent detail. Token and cost metrics are usually safer because they describe volume, not content. The risk rises when exported data can be correlated with code changes or shell activity across sessions.

Q: What breaks when AI developer telemetry is configured locally on each machine?

A: Local configuration breaks consistency. Different developers may send data to different endpoints, retain records for different periods, or skip redaction entirely, which creates uneven governance and makes audit coverage unreliable. A central policy is needed so observability, security review, and content handling all follow the same rules.

Q: Should organisations enable full prompt logging for AI coding tools?

A: Usually not by default. Full prompt logging increases the chance that sensitive instructions, context, or code fragments will be copied into telemetry systems that were intended for operational observability. Organisations should start with minimal necessary data, assess the review value of prompts, and enable richer logging only with explicit controls and justification.

Technical breakdown

What Claude Code telemetry actually emits

Claude Code exports OpenTelemetry metrics and logs for per-session cost, token usage, session counts, lines of code changed, user prompts, API requests, and tool results. Because each record carries a service.name attribute, it can be separated from other telemetry in a shared pipeline. The key architectural point is that telemetry is generated by the AI coding client itself, not reconstructed later from backend logs, so export configuration determines what the organisation can observe and control.

Practical implication: treat Claude Code as a telemetry producer with governance requirements, not as a simple developer utility.

Why tool-result telemetry is the sensitive control point

The highest-risk field is claude_code.tool_result, because tool calls can include bash commands, file paths, and other runtime parameters that may reveal secrets or sensitive repository context. This is a classic data minimisation issue: useful operational telemetry can also carry credential-adjacent detail if it is not filtered before export. The article also notes that full prompt logging is disabled by default, which shows the vendor has already separated lower-risk metadata from higher-risk content, but the organisation still has to decide what is allowed downstream.

Practical implication: build redaction and allow-listing into the telemetry path before records leave the local pipeline.

Why administrator-managed rollout matters for identity governance

The article points to an administrator-managed settings file that can push telemetry configuration org-wide. That matters because decentralised export settings create inconsistent visibility and inconsistent leakage risk across developers, teams, and environments. From an identity governance perspective, this is closer to policy enforcement than preference setting: the organisation needs a consistent control plane for export endpoints, retention, and content handling. Without that, telemetry becomes another unmanaged surface for secrets and sensitive development data.

Practical implication: centralise telemetry configuration so export, retention, and filtering follow the same policy across the developer estate.

NHI Mgmt Group analysis

Telemetry from AI coding tools is now a governance surface, not just an observability feed. Claude Code is emitting enough session and tool activity to create a second control plane for sensitive development data. That matters because telemetry can reveal code paths, command execution, and the shape of developer work even when the application itself is not exposed. Practitioners should manage AI tool telemetry with the same discipline they apply to access logs and secrets logs.

Tool-result data is the named concept teams should focus on: it is the point where observability becomes exposure. The article makes clear that prompts are not the main problem by default, but tool outputs and parameters can carry bash commands and file paths. That is where secrets, source context, and operational intent become visible. For IAM and PAM teams, the lesson is to treat exported tool artefacts as governed data, not harmless metadata.

Administrator-managed configuration is the difference between policy and hope. If telemetry settings live on individual laptops, the organisation cannot guarantee consistent redaction, retention, or endpoint control. Centralised rollout is therefore the governance mechanism that turns an AI assistant from a fragmented developer preference into an enforceable programme. Teams should align AI tooling with the same policy management model used for other high-trust enterprise software.

AI-assisted development is pushing secrets risk further left into the developer workflow. The article sits in the same risk category as secret sprawl and unmanaged NHI exposure because the assistant can sit close to code, commands, and pipeline metadata. That increases the chance that credentials or sensitive paths are observed, logged, or exported before security teams see them. Practitioners should assume the developer workstation is now part of the identity boundary.

The field should expect more agent-like tooling to emit native telemetry that security teams must govern. As AI tools become more capable, they will increasingly produce records that look like operational evidence, not simple usage metrics. That will force identity, security, and data governance teams to decide what counts as approved telemetry, what must be redacted, and which logs belong in security systems versus product analytics. The organisations that define those boundaries early will have a clearer audit trail and lower exposure.

What this signals

AI developer tooling is pushing security teams toward a new operating model where telemetry itself becomes sensitive data. That means export endpoints, retention settings, and content filters need the same governance discipline that organisations already apply to logs, secrets, and identity data. The safest default is to collect the minimum needed for operations and to treat all tool-output fields as potentially sensitive until proven otherwise.

Telemetry boundary control: the point where observability data turns into governance risk is the same point where many teams will need policy, redaction, and review. Organisations that define this boundary early will be better positioned to scale AI coding tools without creating another uncontrolled secrets path.

For programmes already dealing with secret sprawl, this is a warning sign that AI assistants can amplify the same exposure patterns through developer workflows rather than through repositories alone. The practical response is to align AI tool telemetry controls with existing identity and secrets management controls, then validate them against the standards that already govern secure logging and access control, including NIST SP 800-53 Rev 5 Security and Privacy Controls.

For practitioners

• Implement telemetry redaction before export Inspect AI tool telemetry for command strings, file paths, and other parameters that could expose secrets, then redact or suppress those fields in the local pipeline before they reach any backend.
• Centralise export settings for developer AI tools Use administrator-managed configuration to standardise telemetry endpoints, protocols, and logging choices across the team instead of relying on per-user shell profiles.
• Separate operational telemetry from sensitive content Allow session counts, cost, and token metrics to flow, but put explicit controls around tool_result data and any optional prompt-content logging so higher-risk fields are reviewed first.
• Pilot with one workstation before broad rollout Validate what the assistant emits on a single machine, confirm the records in your observability pipeline, and only then extend the same control set across the developer estate.

Key takeaways

• Claude Code telemetry turns AI-assisted development into a governed data stream, not just a productivity feature.
• Tool-result fields are the exposure point because they can carry commands, paths, and secrets-adjacent context.
• Teams should centralise export policy, redact sensitive telemetry before it leaves the pipeline, and keep only the minimum data needed for audit and cost control.

Key terms

• Tool-Result Telemetry: Telemetry generated by an AI assistant after it invokes a tool and receives output. It often includes commands, file paths, or runtime parameters, which makes it useful for auditing but also capable of exposing sensitive development context if exported without filtering.
• Server-Managed Settings: Server-managed settings are centrally delivered configuration values that cannot be overridden locally by the end user. For AI agent governance, they prevent hook drift by ensuring policy enforcement is pushed to every managed device and cannot be bypassed by personal config changes.
• Telemetry Redaction: The process of removing or masking sensitive fields before logs or metrics leave the local collection path. For AI assistants, redaction is essential when tool outputs or prompt-related data might reveal secrets, paths, or other operational details.
• Operational Data Minimisation: A governance principle that limits collection to the smallest set of data needed for a valid operational purpose. In AI tooling, it reduces the chance that observability systems become repositories for sensitive prompts, commands, or code context.

What's in the full article

Bindplane's full how-to guide covers the operational detail this post intentionally leaves for the source:

• Kubernetes in-cluster DNS names and how to wire the collector for production use
• TLS, authentication headers, and troubleshooting steps for the OpenTelemetry pipeline
• Step-by-step configuration for the OTLP source and destination setup
• Live Preview validation steps for confirming telemetry is flowing end to end

👉 Bindplane's full guide covers the Kubernetes setup, transport security, and troubleshooting details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps security practitioners build the policy and operational discipline needed when AI tools and non-human systems generate sensitive data.