KonaSense Supports OpenTelemetry: Governance and Observability for Desktop AI Apps

Claude Code, Cowork, Codex, and ChatGPT Work can now report into KonaSense over OpenTelemetry, extending the same control plane used for browser and agent activity into desktop AI workflows.

KonaSense began supporting OpenTelemetry in June 2026, initially with OTLP trace ingestion and Claude telemetry. Over the following weeks, we expanded that support to additional desktop and agentic AI surfaces, including Codex in July and differentiated ChatGPT Work telemetry in August.

This is not a new sensor installed on the endpoint. The applications already generate telemetry. KonaSense receives it, normalizes it, attributes it to users and devices, evaluates it against the same policies used across the platform, and brings the resulting activity and findings into the same operational view.

The third telemetry path

KonaSense currently has three primary ways to understand AI activity.

The browser and agent integrations operate directly inside the workflow and can enforce policy before an action completes. OpenTelemetry is different: the application emits an event, log, metric, or trace, and KonaSense processes it after the application has generated it. For that reason, OTel should be understood as a monitoring and governance tier for surfaces where direct interception is unavailable or unnecessary.

The same control plane still applies. Telemetry can be classified by the same policy engine. Sensitive-data detectors can inspect prompt content when the source exports it. Policy matches can generate incidents. Activities can contribute to governance, security, inventory, and audit views. But the outcome is observational, not preventive.

What governance means here

When we say OpenTelemetry brings desktop AI applications into governance, we mean four things.

Governance does not automatically mean prevention. Preventive enforcement still requires an integration capable of participating in the action before it completes, such as Kona for Browser or Kona for Agents.

Support did not start this week

OpenTelemetry support in KonaSense has been evolving for several months.

The result is not one feature released on one date. It is an expanding telemetry layer that has progressively brought more AI surfaces into the KonaSense control plane.

Supported and tested AI surfaces

Today, the primary OpenTelemetry integrations relevant to KonaSense include:

The exact telemetry available depends on the application, and that point is important. OpenTelemetry is a protocol and data model. It does not force every AI vendor to emit the same information.

One application may provide prompts, tool calls, MCP activity, approvals, and model metadata. Another may expose only usage events and operational metadata. KonaSense normalizes what is available, but it does not invent telemetry that the source never emitted.

Telemetry is not the same as content capture

A security team can receive useful AI telemetry without receiving the contents of a prompt. These are different capabilities.

To detect a credit card number, source code, credential, customer record, or confidential business information inside a prompt, KonaSense needs access to the relevant content. Most AI telemetry implementations treat content capture separately because of privacy considerations. Codex, for example, does not expose raw user prompts through telemetry unless prompt logging is explicitly enabled, and Claude also provides controls governing whether prompt and response content is included.

Claude Code

Claude Code includes native OpenTelemetry support. Depending on configuration, its telemetry can provide information about usage, sessions, tool activity, API requests, errors, MCP activity, and other execution context. Prompt content is a separate decision: organizations that want sensitive-data inspection must explicitly configure the telemetry required to make that content available.

Claude Code also supports managed configuration, which matters for enterprise deployments. A developer-controlled telemetry configuration is useful for observability. A centrally managed configuration that protects the destination and telemetry policy from project-level modification is much closer to a governance-grade deployment.

The distinction is not whether OpenTelemetry exists. The distinction is who controls it.

Claude Cowork

Cowork provides a particularly useful enterprise integration because telemetry can be configured centrally by a Claude administrator. The administrator configures the OpenTelemetry destination using the available monitoring settings: OTLP endpoint, protocol, and headers. One place, one destination, set by an administrator rather than by each user.

Cowork then emits telemetry to the configured destination. When content capture is enabled, KonaSense can evaluate prompt and response content against sensitive-data and AI-use policies. When content capture is disabled, KonaSense still receives operational and usage telemetry that can contribute to inventory, session analysis, and governance.

Cowork can also expose working activity such as tool usage, API activity, errors, and permission-related events. That makes the telemetry useful for more than prompt monitoring: it provides visibility into what the AI system is actually doing.

Codex

Codex also supports OpenTelemetry. Its telemetry can expose information relevant to AI governance, including session activity, prompts when configured, approval events, tool execution, network-related decisions, and MCP activity. The configuration model differs from Claude, which is another reason KonaSense treats OpenTelemetry as an ingestion framework rather than assuming every AI product behaves identically.

One useful security property in Codex is that project-local configuration cannot simply redefine the OpenTelemetry configuration. This reduces the risk that a repository redirects telemetry to an attacker-controlled or developer-controlled destination. Enterprise administrators can also apply centrally managed Codex configuration.

There is still an important distinction between managed configuration and absolute runtime immutability. A centrally supplied configuration provides stronger governance than a purely local configuration, but administrators should validate the behavior of each control rather than assume every setting is impossible for a user to change.

Codex and ChatGPT Work

ChatGPT Work and Codex are different product experiences, but parts of their desktop execution architecture share underlying Codex components. That creates an attribution problem: if a telemetry platform looks only at a generic runtime identifier, activity from separate products can collapse into a single application.

KonaSense handles this by examining additional telemetry context emitted by the runtime. In telemetry we have tested, fields associated with the runtime origin allow KonaSense to distinguish Codex surfaces from ChatGPT Work activity.

The practical outcome is more important than the plumbing. A security team can distinguish activity originating from a coding agent from activity originating from a general-purpose work assistant instead of seeing both as one generic application.

MCP visibility

Agent telemetry becomes significantly more useful when it includes MCP context. Knowing that an AI agent executed a tool is useful. Knowing which MCP server exposed that tool is better.

Codex telemetry can expose MCP-related session and execution information. Claude Code telemetry can also expose MCP server and tool context, including server identity in supported events. This makes questions like these possible:

• Which sessions used a GitHub MCP server?
• Which agents had access to external tools?
• Which sessions interacted with a database or browser tool?
• Which users were operating agents with sensitive integrations enabled?
• Which MCP servers appear across the organization?

MCP visibility is becoming part of AI asset inventory. It is no longer enough to inventory models and applications. Organizations also need to understand the tools and systems attached to those agents.

Central collectors

Organizations do not need every endpoint to communicate directly with KonaSense. An OpenTelemetry Collector can aggregate telemetry from many systems and forward it to KonaSense, which is useful for centralized routing, filtering and transformation, certificate management, network segmentation, mTLS, additional authentication controls, data residency architectures, and local buffering.

A shared collector does not have to destroy attribution. If user, device, service, session, and resource attributes are preserved, KonaSense can continue to distinguish the originating activity. The collector becomes transport infrastructure, not the identity of every event behind it.

Authentication and transport security

OpenTelemetry integrations do not use the same request-signing mechanism used by Kona for Browser and Kona for Agents. That does not mean OTLP is unauthenticated: exporters can support authentication and transport controls including HTTP headers, TLS, custom certificate authorities, client certificates, mTLS, and collector-based authentication.

The exact capabilities depend on the exporter. Claude Code, Codex, and other OTel implementations provide different security controls. For organizations that require additional isolation or authentication, an intermediate OpenTelemetry Collector can provide another policy and transport boundary.

The honest limits

OpenTelemetry materially expands AI visibility, but it does not eliminate the need for direct controls. There are three important limits.

1. Content may not be available

Without prompt or response content, KonaSense cannot inspect what was written inside a prompt. Everything the application does report is still attributed, evaluated and audited. The sensitive-data question is the one that goes unanswered.

2. Telemetry schemas differ

OpenTelemetry standardizes transport and telemetry concepts. It does not make every AI product emit the same events. Visibility therefore depends on what each application exposes.

3. OpenTelemetry cannot block the action

OTLP is asynchronous telemetry. By the time KonaSense receives the event, the application may already have completed the operation. For activities that require preventive controls, KonaSense uses integrations capable of participating directly in the workflow. That is what Kona for Browser and Kona for Agents are designed to do.

Observability and enforcement are different layers

This creates a useful architecture.

Not every surface needs the same integration. They need the same control plane.

One control plane

The important part of OpenTelemetry support is not OTLP itself. It is convergence. A browser prompt, a Claude Code session, a Cowork task, a Codex tool call, and supported ChatGPT Work activity can all become part of the same organizational picture.

The security team does not need a separate governance model for every AI vendor. KonaSense can normalize those signals around the concepts that matter: user, device, application, model, prompt, agent, session, tool, MCP server, sensitive data, policy, incident, and evidence.