Monitorización de Code/Cowork a escala con Otel & Elastic

A medida que los asistentes de codificación de IA se convierten en herramientas estándar en los flujos de trabajo de ingeniería, los equipos de seguridad se enfrentan a un nuevo desafío: ¿cómo mantienes la visibilidad de lo que hace un agente de IA (y por qué) en toda tu organización? Cuando esos agentes pueden ejecutar comandos shell, leer archivos, llamar APIs e interactuar con sistemas internos a través de conectores MCP, se necesita observabilidad en tiempo real para apoyar la detección de amenazas, la respuesta a incidentes y el cumplimiento.

Esta publicación explica cómo el equipo de InfoSec de Elastic construyó una canalización de monitorización para Claude Code y Claude Cowork empleando sus capacidades nativas de exportación OpenTelemetry (OTel) y la propia infraestructura de ingesta OTel de Elastic. Cubrimos el esquema de telemetría, el despliegue de la puerta de enlace, mapeos personalizados de Elasticsearch y pipelines de ingest, la entrega gestionada de configuración y los casos de uso de seguridad habilitados por estos datos.

Por qué el equipo de InfoSec de Elastic monitoriza a los agentes de IA

En Elastic, practicamos lo que llamamos "Cliente Cero". El equipo de InfoSec es el primer y más exigente usuario de los productos de Elastic, siempre empleando las versiones más recientes en producción. Nuestro objetivo es emplear nuestros propios productos para mejorar nuestra postura de seguridad siempre que podamos.

Claude Code y Cowork están ahora en uso activo en toda la organización de ingeniería de Elastic. Claude Code se ejecuta localmente en máquinas de desarrolladores como asistente de codificación de IA basado en CLI. Cowork forma parte de la aplicación Claude Desktop y también se ejecuta localmente. Puede leer archivos, ejecutar código en un sandbox, buscar en el sitio web e interactuar con servicios conectados como Slack, GitHub, Jira y Google Calendar a través de conectores MCP. Ambas herramientas soportan la conexión a sistemas internos, lo que significa que operan dentro de un límite de confianza que los equipos de seguridad deben monitorizar.

Qué exportan Claude Code y Cowork vía OpenTelemetry

Ambos productos exportan telemetría a través de protocolos estándar OpenTelemetry, emitiendo los mismos cinco tipos de eventos:

api_request — modelo, costo, conteo de tokens, latencia
tool_result — nombre de la herramienta, servidor MCP y nombre de la herramienta, éxito/fracaso, duración
tool_decision — aprobado automáticamente vs aprobado por el usuario
user_prompt — lo que el usuario pidió al agente que hiciera
api_error — mensaje de error, código de estado

Cada evento incluye la identidad del usuario (user.email, organization.id), el contexto de la sesión (session.id, prompt.id, event.sequence) y los campos de costo/token en los eventos de solicitud de API. La telemetría de Claude Code es opt-in y elimina por defecto los prompts y los argumentos de herramientas; Habilitarles con OTEL_LOG_USER_PROMPTS=1 y OTEL_LOG_TOOL_DETAILS=1. Cowork está configurado de forma centralizada en el portal de administración de Anthropic e incluye todos los detalles automáticamente.

Para ver el esquema completo de telemetría, consulte la documentación de Claude Code Monitoring y la documentación de Claude Cowork Monitoring.

Arquitectura: Obtener los datos a Elasticsearch

Hay dos formas de introducir datos Claude Code y Cowork OTel en Elasticsearch. Primero desplegamos el enfoque de pasarela autogestionada, pero los usuarios de Elastic Cloud tienen una opción más sencilla.

Opción 1: Gateway OTel EDOT (autogestionado)

Este es el enfoque que usamos internamente. Dado que el equipo de InfoSec de Elastic gestiona clústeres ECK (Elastic Cloud on Kubernetes) autogestionados, desplegamos una Distribución Elástica del OpenTelemetry Collector (EDOT) como puerta de enlace. Tanto Claude Code como Cowork se ejecutan localmente en las máquinas de usuario y envían OTLP/HTTP a la pasarela, que autentica la solicitud y escribe en Elasticsearch.

Usamos la carta de Helm con colector de telemetría abierta con la imagen colectora EDOT (docker.elastic.co/elastic-agent/elastic-otel-collector). La imagen EDOT proporciona enrutamiento nativo de flujos de datos Elastic, lo cual es importante para que los registros lleguen a los flujos de datos adecuados sin configuraciones adicionales.

La pasarela funciona en modo de despliegue y emplea autenticación de token portador mediante la extensiónbearertokenauth .

Aquí está la configuración del colector principal:

config:
  extensions:
    bearertokenauth:
      scheme: "Bearer"
      token: "${env:OTEL_GATEWAY_TOKEN}"
  receivers:
    otlp:
      protocols:
        http:
          endpoint: "0.0.0.0:4318"
          auth:
            authenticator: bearertokenauth
  processors:
    transform/route:
      log_statements:
        - context: log
          conditions:
            - resource.attributes["service.name"] == "claude-code"
          statements:
            - set(resource.attributes["data_stream.dataset"], "claude_code")
        - context: log
          conditions:
            - resource.attributes["service.name"] == "cowork"
          statements:
            - set(resource.attributes["data_stream.dataset"], "claude_cowork")
  exporters:
    elasticsearch:
      endpoints: ["https://your-elasticsearch:9200"]
      user: "${env:ES_USERNAME}"
      password: "${env:ES_PASSWORD}"
  service:
    extensions: [bearertokenauth]
    pipelines:
      logs:
        receivers: [otlp]
        processors: [transform/route]
        exporters: [elasticsearch]

Opción 2: Endpoint OTLP gestionado en la nube de Elastic (no se necesita gateway)

Si usas Elastic Cloud (sin servidor o alojado), puedes saltarte el gateway por completo. El endpoint Managed OTLP (mOTLP) de Elastic proporciona una capa de ingestión resiliente y autoescalable que acepta directamente los datos OTLP — sin infraestructura de colectores que desplegar o mantener.

Para usarlo, apunta el exportador OTLP de Claude Code directamente a tu endpoint mOTLP de Elastic Cloud:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_LOGS_EXPORTER=otlp
export OTEL_METRICS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT="https://<your-motlp-endpoint>"
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=ApiKey <your-api-key>"
export OTEL_RESOURCE_ATTRIBUTES="data_stream.dataset=claude_code"

El atributo de recurso data_stream.dataset es importante aquí; Él controla qué flujo de datos recibe los registros. Sin él, los datos caen en un flujo de datos OTel genérico donde tus plantillas de índice personalizadas y tus pipelines de ingesta no se aplicarán. Configúralo en claude_code o claude_cowork para que los datos se enruten a los flujos dedicados de logs-claude_code.otel-* o logs-claude_cowork.otel-* con los mapeos de campo correctos.

Con mOTLP, obtienes ingesta nativa OTLP con enrutamiento automático de flujos de datos, un almacén de fallos integrado para proteger los datos durante problemas de indexación y no requiere un servidor APM.

El endpoint gestionado soporta todas las mismas plantillas de índices personalizadas y pipelines de ingesta descritos más abajo, simplemente no necesitas operar la pasarela.

Para detalles completos de configuración, consulte la documentación OTLP gestionada por Elastic Cloud.

Mapeos personalizados de Elasticsearch y pipelines de ingesta

Por defecto, los atributos OTel se indexan como palabras clave en Elasticsearch. Eso funciona para filtrar y agrupar, pero rompe las agregaciones numéricas. No puedes hacer SUM ni hacer un AVG en un campo de palabras clave. Creamos mapeos personalizados para fijar los tipos de campos y una tubería de ingesta para analizar los campos de cadenas JSON en objetos estructurados.

Plantilla de componentes

La plantilla de componentes anula los mapeos de palabras clave por defecto para campos numéricos y booleanos, y agrega mapeos de flattened tipos para los parámetros de la herramienta codificada en JSON:

PUT _component_template/logs-claude_code.otel@custom
{
  "template": {
    "mappings": {
      "properties": {
        "cost_usd":                  { "type": "float" },
        "duration_ms":               { "type": "long" },
        "input_tokens":              { "type": "long" },
        "output_tokens":             { "type": "long" },
        "cache_creation_tokens":     { "type": "long" },
        "cache_read_tokens":         { "type": "long" },
        "prompt_length":             { "type": "long" },
        "tool_result_size_bytes":    { "type": "long" },
        "success":                   { "type": "boolean" },
        "tool_parameters_flattened": { "type": "flattened" },
        "tool_input_flattened":      { "type": "flattened" }
      }
    }
  }
}

El tipo de flattened es importante aquí. tool_parameters y tool_input llegan como cadenas JSON que contienen claves anidadas como mcp_server_name, mcp_tool_name, bash_commando command. Al analizarlas en flattened campos, puedes consultar claves individuales sin crear un número ilimitado de campos asignados.

Una mejora futura será extraer campos de alto valor de estas cargas útiles JSON en campos mapeados dedicados — como nombres de servidores MCP, nombres de herramientas y comandos bash — para impulsar análisis más ricos, agregaciones y reglas de detección directamente sobre esos valores.

Plantilla de índice

La plantilla de índice incluye todas las plantillas estándar de componentes OTel, además de la personalizada. Coincide tanto logs-claude_code.otel-* como logs-claude_cowork.otel-* por lo que ambos flujos de datos comparten el mismo mapeo de campos:

PUT _index_template/logs-claude_code.otel
{
  "index_patterns": [
    "logs-claude_code.otel-*",
    "logs-claude_cowork.otel-*"
  ],
  "composed_of": [
    "logs@mappings",
    "logs@settings",
    "otel@mappings",
    "otel@settings",
    "logs-otel@mappings",
    "semconv-resource-to-ecs@mappings",
    "logs@custom",
    "logs-otel@custom",
    "logs-claude_code.otel@custom",
    "ecs@mappings"
  ],
  "priority": 150,
  "data_stream": {},
  "allow_auto_create": true,
  "ignore_missing_component_templates": [
    "logs@custom",
    "logs-otel@custom"
  ]
}

Pipeline de ingesta

El pipeline de ingesta analiza tool_parameters y tool_input de cadenas JSON en objetos, escribiendo para separar *_flattened campos de destino y evitar conflictos con los atributos originales asignados a palabra clave:

PUT _ingest/pipeline/logs-claude_code.otel@custom
{
  "description": "Parse JSON string fields in Claude Code/Cowork OTel telemetry",
  "processors": [
    {
      "json": {
        "field": "attributes.tool_parameters",
        "target_field": "tool_parameters_flattened",
        "if": "ctx.attributes?.tool_parameters != null && ctx.attributes.tool_parameters.startsWith('{')",
        "ignore_failure": true
      }
    },
    {
      "json": {
        "field": "attributes.tool_input",
        "target_field": "tool_input_flattened",
        "if": "ctx.attributes?.tool_input != null && ctx.attributes.tool_input.startsWith('{')",
        "ignore_failure": true
      }
    }
  ]
}

Tras crear los tres recursos, los nuevos datos que fluyen hacia los flujos de datos logs-claude_code.otel-* y logs-claude_cowork.otel-* tendrán los tipos numéricos correctos de campos y parámetros de herramientas estructuradas buscables.

Configuración de la exportación de telemetría

Claude Code y Cowork están configurados de forma diferente. Claude Code emplea variables estándar de entorno OpenTelemetry. La exportación OTel de Cowork se configura de forma centralizada por los administradores en el portal de administración de Anthropic.

Claude Code soporta configuraciones gestionadas que son implementadas por TI y que no pueden ser anuladas por los usuarios. La configuración es un archivo JSON que contiene un bloque de env :

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_LOG_TOOL_DETAILS": "1",
    "OTEL_LOG_USER_PROMPTS": "1",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://your-otel-gateway:443",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer your-token"
  }
}

Este archivo de configuración gestionada puede entregar mediante MDM (Jamf, Intune), configuraciones gestionadas por el servidor a través de la Consola de Administración Claude.ai, o despliegue basado en archivos. Consulte la documentación de configuración gestionada de Claude Code para la lista completa de mecanismos de entrega y sus propiedades de seguridad.

Para pruebas locales, puedes poner la misma configuración en ~/.claude/settings.json en tu propia máquina antes de desplegarla a nivel de organización.

Colaboración

La exportación OTel de Cowork se configura de forma centralizada por los administradores en el portal de administración de Anthropic. Los administradores configuran el endpoint OTLP y las cabeceras de autenticación en la consola de administración, y las instancias de Cowork detectan automáticamente la configuración. El contenido de los prompts y los detalles de las herramientas se incluyen por defecto sin necesidad de indicaciones adicionales.

Como Cowork se ejecuta en un sandbox, el endpoint de la puerta de enlace OTel debe estar autorizado para acceder a la red saliente desde el entorno sandbox. Sin esto, la exportación de telemetría fallará silenciosamente.

Casos de uso de seguridad

La combinación de tipos de eventos, campos de identidad y parámetros de herramientas crea un conjunto de datos rico para operaciones de seguridad. Estos son los casos de uso en torno a los que estamos construyendo capacidades de detección e investigación.

Auditoría de invocación de herramientas. Cada llamada a la herramienta se registra con el nombre de la herramienta y los parámetros de entrada. Para las herramientas MCP, esto incluye el nombre del servidor MCP y el nombre de la herramienta (por ejemplo, slack_send_message github/search_issues). Puedes detectar acceso no autorizado a datos, comandos inusuales en el shell o interacciones inesperadas con servidores MCP. Usa los campos attributes.tool_name + attributes.tool_parameters .

Reconstrucción de sesiones. El campo session.id combinado con event.sequence proporciona un contador que crece monótonamente dentro de cada sesión. Puedes reconstruir la secuencia completa de una sesión de Claude: qué preguntó el usuario, qué herramientas ejecutaron, qué datos se accedieron y qué APIs se llamaron. Esto es valioso para la respuesta a incidentes: si detectas una llamada sospechosa a una herramienta, puedes consultar todo el contexto de la sesión.

Análisis de decisiones de licencia. Los eventosattributes.event.name: tool_decision ofrecen una visión de cómo se aprobó cada uso de herramienta. Esto te permite detectar que los usuarios aprueban automáticamente categorías de herramientas de riesgo, o identificar patrones de licencias inusuales en toda la flota.

Fuente de la decisión	Significado
`config`	Auto-permitido por configuración o política
`hook`	Decidido por un script hook configurado
`user_temporary`	El usuario hizo clic en aceptar para esta invocación
`user_permanent`	El usuario hizo clic en "siempre permitir" para esta herramienta
`user_abort`	El usuario abortó la sesión
`user_reject`	El usuario rechazó explícitamente el uso de la herramienta

Detección de anomalías de costo. El campo cost_usd en cada evento de api_request permite el seguimiento de costos por solicitud, sesión y usuario. Puedes alertar sobre sesiones inusualmente caras o identificar usuarios con patrones de consumo desproporcionados.

Correlacionado con los datos de EDR. Si ejecutas Elastic Defend en tus endpoints, puedes correlacionar la telemetría OTel de Claude con los eventos del proceso y archivo EDR para entender el panorama completo. Cuando Claude Code ejecuta un comando Bash, el evento OTel tool_result te dice qué decidió ejecutar el agente y por qué (a través de la user_promptanterior). El evento correspondiente del proceso Elastic Defend te dice exactamente qué ocurrió en el host: procesos hijos generados, archivos escritos, conexiones de red establecido. Unir estas dos fuentes de datos por marca de tiempo y host te da tanto la intención (de la telemetría de agentes de IA) como el impacto (de la telemetría de endpoint) en una sola investigación.

Monitorización de acceso al servidor MCP. A medida que las organizaciones conectan agentes de IA con sistemas internos a través de MCP, monitorizar qué servidores se acceden y con qué herramientas se vuelve fundamental. Los campos tool_parameters_flattened.mcp_server_name y tool_parameters_flattened.mcp_tool_name proporcionan esta visibilidad.

Por ejemplo, para ver invocaciones de herramientas para Slack, podrías consultar tool_name: "mcp_tool" AND tool_parameters_flattened.mcp_tool_name:slack*.

Más allá de OTel: Claude registros de auditoría empresarial

La telemetría de Claude Code y Cowork cubre la actividad de los agentes en los endpoints, pero no captura todo. Para una visibilidad total, las organizaciones también deberían recopilar los registros de auditoría empresarial de Claude desde la API de Cumplimiento. Esta es la única fuente de actividad en la interfaz sitio web (claude.ai) y de eventos tradicionales de auditoría de seguridad, como la actividad de inicio de sesión, cambios de licencias y la administración a nivel de organización. Combinar ambas fuentes de datos ofrece a los equipos de seguridad una visión completa de todos los productos Claude.

Conclusión

Los asistentes de codificación de IA y los agentes autónomos se están convirtiendo en parte del kit estándar de herramientas empresariales. Si tu equipo de seguridad no tiene visibilidad sobre lo que hacen estas herramientas, tienes una laguna. Claude Code y Cowork incluyen soporte OpenTelemetry que proporciona exactamente el tipo de telemetría que los equipos de seguridad necesitan; Identidad, contexto de la sesión, detalles de invocación de herramientas, datos de costo y decisiones de licencias. Las capacidades nativas de ingesta OTel de Elastic, ya sea a través del endpoint OTLP gestionado en Elastic Cloud o del colector EDOT en un entorno autogestionado, facilitan la entrada de estos datos en Elasticsearch, donde puedes buscarlos, crear paneles de control y escribir reglas de detección.

Si quieres empezar, apúntate a una prueba gratis de Elastic Cloud y prueba el endpoint Managed OTLP, o instala el EDOT OTel Collector en tu entorno actual.

Monitorización de código/cowork de Claude a escala con OTel en Elastic