Claude Code, Cowork, Codex e ChatGPT Work podem reportar atividades ao KonaSense via OpenTelemetry, ampliando o mesmo control plane usado para browser e agentes para os fluxos de IA no desktop.
O KonaSense começou a suportar OpenTelemetry em junho de 2026, inicialmente com ingestão de traces OTLP e telemetria do ecossistema Claude. Nas semanas seguintes, ampliamos esse suporte para novas superfícies de IA desktop e agentic, incluindo Codex em julho e a diferenciação da telemetria do ChatGPT Work em agosto.
Isso não exige um novo sensor instalado no endpoint. As próprias aplicações já geram telemetria. O KonaSense recebe esses eventos, normaliza os dados, atribui a atividade a usuários e dispositivos, avalia o conteúdo e o contexto contra as mesmas políticas utilizadas no restante da plataforma e leva os resultados para a mesma visão operacional.
O terceiro caminho de telemetria
Hoje o KonaSense possui três formas principais de entender a atividade de IA.
| Integração | Cobertura | Gera incidentes | Pode intervir |
|---|---|---|---|
| Kona for Browser | Uso de GenAI em browsers suportados | Sim | Sim: block, redact, warn, coach |
| Kona for Agents | Ações de agentes em IDEs e CLIs suportados | Sim | Sim: allow ou deny antes da execução |
| OpenTelemetry | Aplicações e runtimes de IA suportados que exportam telemetria | Sim | Não: observa e avalia |
As integrações de browser e agentes participam diretamente do fluxo de execução e podem aplicar uma decisão antes que ela termine. OpenTelemetry funciona de outra maneira: a aplicação gera um evento, log, métrica ou trace, e o KonaSense processa essa informação depois que ela foi produzida. Por isso, OTel deve ser entendido como uma camada de monitoramento e governança para superfícies onde a interceptação direta não está disponível ou não é necessária.
O mesmo control plane continua sendo aplicado. A telemetria pode ser classificada pelo mesmo policy engine. Detectores de dados sensíveis podem analisar prompts quando a fonte exporta esse conteúdo. Matches de política podem gerar incidentes. As atividades podem alimentar as visões de governança, segurança, inventário e auditoria. Mas o resultado é observacional, não preventivo.
O que governança significa neste contexto
Quando dizemos que OpenTelemetry coloca aplicações de IA desktop dentro da governança, estamos falando de quatro capacidades.
Visibilidade
O time de segurança consegue entender quem está usando IA, qual aplicação está envolvida e que tipo de atividade está ocorrendo.
Avaliação de política
A telemetria é avaliada contra as políticas organizacionais de IA usando o mesmo policy engine aplicado a outras superfícies do KonaSense.
Evidência
Telemetria relevante, classificações, detecções, contexto de usuário, contexto da aplicação e matches de política passam a fazer parte de um registro auditável.
Auditabilidade
Findings podem aparecer nos mesmos fluxos de incidentes e ser exportados para os processos existentes de operações de segurança.
Governança não significa necessariamente prevenção. Enforcement preventivo continua exigindo uma integração capaz de participar da ação antes que ela seja concluída, como Kona for Browser ou Kona for Agents.
O suporte não começou nesta semana
O suporte a OpenTelemetry no KonaSense vem evoluindo há vários meses.
Telemetria do Claude
A telemetria do Claude, incluindo atividades relacionadas ao Cowork, também começou a ser integrada em junho.
Work e Codex, separados
O KonaSense adicionou lógica adicional para diferenciar atividade do ChatGPT Work de atividade do Codex quando ambos utilizam componentes do mesmo runtime subjacente.
Portanto, não se trata de uma funcionalidade lançada em uma única data. É uma camada de telemetria que vem expandindo progressivamente as superfícies de IA cobertas pelo control plane do KonaSense.
Superfícies de IA suportadas e testadas
Hoje, as principais integrações de OpenTelemetry relevantes para o KonaSense incluem:
Claude Code
Logs e eventos OpenTelemetry, métricas e tracing suportado.
Claude Cowork
Logs e eventos OTLP configurados pela organização.
Codex
Telemetria OpenTelemetry gerada pelo runtime do Codex.
ChatGPT Work
Telemetria testada pelo KonaSense através do runtime compartilhado do Codex, quando disponível.
A quantidade e o tipo de dados disponíveis dependem de cada aplicação, e esse ponto é importante. OpenTelemetry é um protocolo e um modelo de telemetria. Ele não obriga todos os fornecedores de IA a emitirem as mesmas informações.
Uma aplicação pode expor prompts, chamadas de ferramentas, atividade MCP, aprovações e metadados do modelo. Outra pode fornecer apenas eventos de uso e dados operacionais. O KonaSense normaliza o que está disponível, mas não inventa telemetria que a aplicação de origem nunca gerou.
Telemetria não é a mesma coisa que captura de conteúdo
Um time de segurança pode receber telemetria útil de IA sem receber o conteúdo de um prompt. São capacidades diferentes.
O que uma aplicação pode reportar
- identidade do usuário
- nome da aplicação
- provedor do modelo
- identificador da sessão
- consumo de tokens
- atividade de ferramentas
- resultado de execução
- atividade MCP
- latência
- erros
- decisões de aprovação
O que ela ainda pode omitir
O texto digitado pelo usuário.
Isso ainda é útil para inventário, análise de uso, visibilidade de agentes e auditoria. Mas não é suficiente para inspecionar o que foi escrito dentro de um prompt.
Para detectar um número de cartão, código-fonte, credencial, registro de cliente ou informação confidencial dentro de um prompt, o KonaSense precisa receber o conteúdo correspondente. A maioria das implementações de telemetria de IA trata captura de conteúdo separadamente por questões de privacidade. No Codex, por exemplo, prompts brutos não são incluídos na telemetria sem que o logging de prompts seja explicitamente ativado, e o Claude também oferece controles sobre a inclusão de conteúdo de prompts e respostas.
Claude Code
Claude Code possui suporte nativo a OpenTelemetry. Dependendo da configuração, sua telemetria pode fornecer informações sobre uso, sessões, ferramentas, chamadas de API, erros, atividade MCP e outros elementos do contexto de execução. O conteúdo dos prompts é uma decisão separada: organizações que querem inspeção de dados sensíveis precisam configurar explicitamente a telemetria necessária para disponibilizar esse conteúdo.
Claude Code também suporta configuração gerenciada, o que é relevante para ambientes corporativos. Uma configuração controlada individualmente pelo desenvolvedor é útil para observabilidade. Uma configuração centralizada, na qual o destino e as políticas de telemetria são protegidos contra alterações em nível de projeto, se aproxima muito mais de uma implantação de governança.
A diferença não está na existência do OpenTelemetry. A diferença está em quem controla a configuração.
Claude Cowork
Cowork oferece uma integração particularmente útil para empresas porque a telemetria pode ser configurada de forma centralizada por um administrador Claude. O administrador configura o destino OpenTelemetry usando os controles de monitoramento disponíveis: endpoint OTLP, protocolo e headers. Um lugar, um destino, definido por um administrador e não por cada usuário.
Cowork então envia telemetria para o destino configurado. Quando a captura de conteúdo está habilitada, o KonaSense pode avaliar prompts e respostas contra políticas de dados sensíveis e de uso de IA. Quando a captura de conteúdo está desabilitada, o KonaSense ainda recebe telemetria operacional e de uso que contribui para inventário, análise de sessões e governança.
Cowork também pode fornecer atividade relacionada ao trabalho executado, como uso de ferramentas, chamadas de API, erros e eventos relacionados a permissões. Isso torna a telemetria útil para mais do que apenas monitorar prompts: ela fornece visibilidade sobre o que o sistema de IA está efetivamente fazendo.
Codex
Codex também suporta OpenTelemetry. Sua telemetria pode expor informações relevantes para governança de IA, incluindo atividade de sessão, prompts quando configurados, eventos de aprovação, execução de ferramentas, decisões relacionadas a rede e atividade MCP. O modelo de configuração é diferente do Claude, e esse é outro motivo pelo qual o KonaSense trata OpenTelemetry como uma camada de ingestão e normalização, sem assumir que todos os produtos de IA funcionam da mesma maneira.
Uma propriedade importante no Codex é que configurações locais do projeto não podem simplesmente redefinir a configuração OpenTelemetry. Isso reduz o risco de um repositório redirecionar telemetria para um destino controlado pelo desenvolvedor ou por um atacante. Administradores corporativos também podem aplicar configurações centralizadas ao Codex.
Ainda existe uma diferença importante entre configuração gerenciada e imutabilidade absoluta durante a execução. Uma configuração fornecida centralmente oferece governança mais forte do que uma configuração puramente local, mas os controles de cada fornecedor precisam ser avaliados pelo comportamento real, e não pela suposição de que toda configuração seja impossível de alterar.
Codex e ChatGPT Work
ChatGPT Work e Codex são experiências de produto diferentes, mas partes da arquitetura de execução no desktop compartilham componentes do ecossistema Codex. Isso cria um problema de atribuição: se uma plataforma de telemetria observar apenas um identificador genérico do runtime, atividades de produtos diferentes podem ser agrupadas como se fossem a mesma aplicação.
O KonaSense trata esse problema analisando contexto adicional emitido pela telemetria. Nos dados que testamos, campos associados à origem do runtime permitem diferenciar superfícies do Codex de atividade do ChatGPT Work.
O resultado prático é mais importante do que o detalhe técnico. O time de segurança consegue diferenciar uma atividade originada de um coding agent de uma atividade originada de um work assistant, em vez de visualizar tudo como uma única aplicação genérica.
Visibilidade de MCP
A telemetria de agentes se torna significativamente mais útil quando inclui contexto de MCP. Saber que um agente de IA executou uma ferramenta é útil. Saber qual MCP server disponibilizou essa ferramenta é ainda melhor.
A telemetria do Codex pode fornecer informações de MCP relacionadas à sessão e à execução. A telemetria do Claude Code também pode fornecer contexto de MCP server e ferramentas, incluindo identidade do servidor em eventos suportados. Isso permite responder perguntas como:
- Quais sessões utilizaram um MCP server do GitHub?
- Quais agentes tinham acesso a ferramentas externas?
- Quais sessões interagiram com ferramentas de banco de dados ou browser?
- Quais usuários estavam operando agentes com integrações sensíveis?
- Quais MCP servers existem dentro da organização?
Visibilidade de MCP está se tornando parte do inventário de ativos de IA. Não basta mais inventariar modelos e aplicações. As organizações também precisam entender quais ferramentas e sistemas estão conectados aos agentes.
Collectors centralizados
Uma organização não precisa fazer com que cada endpoint envie telemetria diretamente para o KonaSense. Um OpenTelemetry Collector pode agregar telemetria de vários sistemas e encaminhá-la ao KonaSense, o que é útil para roteamento centralizado, filtragem e transformação, gerenciamento de certificados, segmentação de rede, mTLS, controles adicionais de autenticação, arquiteturas de residência de dados e buffering local.
Um collector compartilhado não precisa eliminar a atribuição individual. Se atributos de usuário, dispositivo, serviço, sessão e resource forem preservados, o KonaSense continua conseguindo distinguir a origem das atividades. O collector funciona como infraestrutura de transporte, não como a identidade de todos os eventos que passam por ele.
Autenticação e segurança de transporte
As integrações OpenTelemetry não utilizam o mesmo mecanismo de assinatura de requests usado pelo Kona for Browser e pelo Kona for Agents. Isso não significa que OTLP seja um protocolo sem autenticação: exporters OTLP podem suportar mecanismos como HTTP headers, TLS, autoridades certificadoras customizadas, client certificates, mTLS e autenticação através de collectors.
As capacidades exatas dependem do exporter. Claude Code, Codex e outras implementações OpenTelemetry possuem controles de segurança diferentes. Organizações que exigem isolamento ou autenticação adicional também podem utilizar um OpenTelemetry Collector intermediário como uma nova fronteira de transporte e política.
Os limites reais
OpenTelemetry aumenta significativamente a visibilidade de IA, mas não elimina a necessidade de controles diretos. Existem três limites importantes.
1. O conteúdo pode não estar disponível
Sem o conteúdo do prompt ou da resposta, o KonaSense não pode inspecionar o que foi escrito dentro de um prompt. Tudo o que a aplicação reporta continua sendo atribuído, avaliado e auditado. A pergunta sobre dados sensíveis é a que fica sem resposta.
2. Os schemas de telemetria são diferentes
OpenTelemetry padroniza transporte e conceitos de telemetria. Ele não faz com que todos os produtos de IA emitam os mesmos eventos. A visibilidade depende do que cada aplicação fornece.
3. OpenTelemetry não bloqueia a ação
OTLP é telemetria assíncrona. Quando o KonaSense recebe o evento, a aplicação pode já ter concluído a operação. Para atividades que exigem controle preventivo, o KonaSense utiliza integrações capazes de participar diretamente do workflow. É para isso que Kona for Browser e Kona for Agents foram projetados.
Observabilidade e enforcement são camadas diferentes
Isso cria uma arquitetura clara.
OpenTelemetry
Observar. Atribuir. Avaliar. Detectar. Auditar.
Kona for Browser
Observar. Avaliar. Redigir. Alertar. Orientar. Bloquear.
Kona for Agents
Observar. Avaliar. Aprovar. Negar. Controlar ações de agentes.
Nem toda superfície precisa da mesma integração. Todas precisam do mesmo control plane.
Um único control plane
A parte mais importante do suporte a OpenTelemetry não é o OTLP. É a convergência. Um prompt no browser, uma sessão do Claude Code, uma tarefa no Cowork, uma execução de ferramenta no Codex e uma atividade suportada do ChatGPT Work podem fazer parte da mesma visão organizacional.
O time de segurança não precisa criar um modelo de governança separado para cada fornecedor de IA. O KonaSense pode normalizar esses sinais em torno dos conceitos que realmente importam: usuário, dispositivo, aplicação, modelo, prompt, agente, sessão, ferramenta, MCP server, dado sensível, política, incidente e evidência.
Traga suas aplicações de IA no desktop para o control plane
