Telemetry spine

OpenTelemetry gen_ai.* semantic conventions

The OpenTelemetry GenAI Working Group semantic conventions define span and metric attributes for LLM and agent telemetry, but remain in Development status rather than a stable standard. Helmwart mitigations can emit these attributes as a provisional interoperable format, so that any OTel-compatible backend (Grafana, Honeycomb, Datadog, OpenSearch) can ingest mitigation telemetry without per-vendor attribute mapping.

A SIEM (Security Information and Event Management) platform that ingests these attributes can correlate mitigation events across the full agent fleet without per-source parsers. The sections below define the shared AnomalyEvent schema that Helmwart mitigations emit into that SIEM pipeline.

The full spec is maintained at opentelemetry.io/docs/specs/semconv/gen-ai/. Additional attributes cover tool calls, agent events, and span events for prompt and completion content. Use the spec as the source of truth; the attributes above are the subset most directly relevant to mitigation telemetry. Pin the convention version used in production because Development-status names and requirements may change.

Shared AnomalyEvent schema

OpenTelemetry attributes describe individual spans. Cross-mitigation correlation requires a shared event envelope: a schema that lets a SIEM join an event from m-mem-anomaly with an event from m-divergence-monitor with an event from m-output-egress-dlp without per-vendor parsing. The AnomalyEvent schema is Helmwart's minimal interop envelope.

{
  "event_id":   "string  // UUID v4 — stable across retransmits",
  "timestamp":  "string  // ISO 8601 UTC — e.g. 2026-05-12T14:23:01.000Z",
  "agent_id":   "string  // SPIFFE SVID or stable agent identifier",
  "control_id": "string  // Helmwart mitigation ID — e.g. m-mem-anomaly",
  "severity":   "string  // low | medium | high | critical",
  "signal_type":"string  // anomaly | threshold_breach | policy_violation |
                //          kill_switch | override | egress_block",
  "context": {
    "gen_ai_response_id": "string  // links to the OTel span",
    "threat_ids":         ["T1"],  // OWASP threat IDs this event is evidence for
    "detail":             "string  // human-readable, one sentence"
  }
}

Why this schema exists

Each Helmwart mitigation is implemented independently, across different languages, different infrastructure stacks, and different vendors. Without a shared envelope, a SIEM analyst correlating a memory-anomaly event with a divergence event with a DLP egress block must write three separate parsers and maintain the join logic outside any schema. The AnomalyEvent schema makes the join structural:

• event_id is stable across retransmits, giving idempotent ingestion with no duplicate alerts.
• agent_id is the SPIFFE SVID or equivalent stable identifier, matching what m-spiffe and m-actor-recorder-split use. A SIEM can group all events for one agent across all mitigations without a lookup table.
• control_id is the Helmwart mitigation ID, so a SIEM rule can filter to all events from a specific control without parsing free-text.
• signal_type is a bounded enum, so correlation rules can match on type without regex.
• context.gen_ai_response_id links the AnomalyEvent to the OTel span, so the SIEM can retrieve the full trace for any alert without a second lookup.
• context.threat_ids maps the event to OWASP threat taxonomy, so the SIEM can count evidence-weight per threat without a threat-model lookup.

Mitigations on this spine

The following mitigations should emit AnomalyEvent records on the telemetry spine. Each entry notes the primary signal_type and the OTel attributes that must be present in the associated span.

Wiring it together

A minimal telemetry-spine deployment has three moving parts:

1. OTel instrumentation on every agent span: emit gen_ai.* attributes on every LLM call and tool execution. The OpenTelemetry GenAI instrumentation libraries for Python, Node, and Java cover the major LLM SDKs automatically; verify attribute completeness against the spec before relying on them in production.
2. AnomalyEvent emission at each mitigation: each mitigation that trips emits one AnomalyEvent to a shared event bus (Kafka topic, SNS topic, or OTLP log endpoint). The recorder identity from m-actor-recorder-split should be the only identity with write access to that bus.
3. SIEM correlation rules: join on agent_id and context.gen_ai_response_id. A response ID that appears in both an injection AnomalyEvent and a divergence AnomalyEvent within the same session is a high-confidence indicator of a successful injection leading to goal manipulation; escalate to m-kill-switch evaluation.

Takeaway

A newcomer's starting point: instrument every LLM call with the gen_ai.* OTel attributes, have each mitigation emit one AnomalyEvent per trip to a shared bus, and write two SIEM join rules: one on agent_id, one on gen_ai_response_id. Those three steps give you cross-mitigation correlation out of the box. For the accountability layer that preserves these records against tampering, see the Tamper-Evident Accountability handbook page.