> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/6.-observability-audit-and-evidence/6.5-routing-ai-telemetry-to-your-siem.md).

# 6.5 Routing AI telemetry to your SIEM

How to get compliance APIs, usage logs, and runtime telemetry into the SOC with starter detections for AI-specific events.

*Last reviewed: August 18, 2026*

{% hint style="info" %}
Telemetry is useful only when it reaches the people who respond. Normalize AI events, redact sensitive content, and write detections that match real workflows.
{% endhint %}

## What security teams need to know about routing AI telemetry to your SIEM

AI telemetry often arrives from several places: platform APIs, OpenTelemetry, endpoint logs, connector logs, proxy logs, and hosted-agent services. The SIEM should join these signals without turning prompts into uncontrolled data stores.

AI telemetry reaches a SIEM over three transports: polling compliance and analytics APIs, collector export from OpenTelemetry-instrumented runtimes, and push delivery through event streams or webhooks from hosted agent services. Most programs need at least two of the three.

Start with detections that map to control failures. Examples include sandbox escalation, denied secret reads, new connector scopes, unexpected egress, and external write actions after untrusted content.

## Common routing AI telemetry to your SIEM security failures

* Prompt content is sent to a broad log index without redaction.
* Vendor logs and endpoint logs use different identities.
* Detections fire without an owner or runbook.
* Tool-call data is too verbose to search during an incident.
* High-risk denied actions are not ingested.

## Routing AI telemetry to your SIEM security controls checklist

* Normalize identities, surfaces, runtimes, models, policies, tools, approvals, targets, outcomes, and correlation IDs.
* Redact or restrict prompts, outputs, tool parameters, file paths, and connector payloads before broad ingestion.
* Preserve source identifiers so analysts can retrieve restricted evidence when authorized.
* Build detections from approved threat scenarios and expected control behavior.
* Monitor repeated denied reads, new connector grants, tool-definition drift, unusual destinations, persistent-memory changes, cross-tenant identifiers, runaway usage, failed stops, and telemetry silence.
* Baseline by cohort, agent, project, task type, destination, time, and cost rather than only total usage.
* Test detections with representative events and verify attribution to the initiating user and acting identity.
* Attach every detection to an owner, severity rule, investigation query, containment step, and review cadence.

## Starter detection library

| Detection                     | Signal to correlate                                                                                                |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Sensitive-path probing        | Repeated denied reads, secret-scanner hits, file paths, and subsequent tool or network activity                    |
| New or widened authority      | Connector grant, role change, service-account scope, new MCP server, plugin, skill, hook, or agent version         |
| Tool or instruction drift     | Hash or version change after approval, new tool schema, changed destination, or unsigned update                    |
| Injection-to-action chain     | Untrusted content followed by privileged retrieval, external write, publishing, or credential use                  |
| Internal network reach        | Metadata, loopback, private address, management socket, unusual DNS, redirect, or callback destination             |
| Memory or retrieval poisoning | New persistent memory, knowledge-source update, unusual author, changed labels, or later cross-user effect         |
| Denial of wallet              | Token, tool, retry, duration, concurrency, storage, or third-party cost above task and cohort baseline             |
| Stop or revocation failure    | Cancellation followed by tool, queue, child-agent, webhook, or target-system activity                              |
| Evidence degradation          | Source silence, ingestion delay, parser error, schema drift, clock drift, unexpected sampling, or attribution loss |

Use detections to answer a response question. An alert without a way to identify the task, authority, target, output, and containment control will not help during an incident.

## Anthropic

### Overview

Anthropic routing combines pull and push. Claude Code emits OpenTelemetry, Claude Code cloud execution produces audit logs, and Managed Agents expose event streams and webhooks. Cowork and Claude's Microsoft 365 add-ins need their own OpenTelemetry collectors because Anthropic does not include those surfaces in the Compliance API or data exports. These feeds can carry full prompts, tool parameters, file paths or URLs, and user identity, so route them through a restricted collector and redact before broad SIEM ingestion.

Permission and approval events are strong starter detections. Claude Code deny rules take precedence over ask and allow rules, and Cowork telemetry can record approvals. Alert on repeated denials against secret paths, network tools, or cross-app actions. Normalize user, surface, agent or session, tool, target system, approval state, credential type, and data class before events land in shared indexes.

Claude Tag adds an optional hourly JSON export of Agent Proxy network events rather than the same OpenTelemetry feed. It omits Git and MCP traffic, so ingest it as one partial source and join it with Slack threads, Claude Tag routine and memory records, and target-system audit logs under the dedicated service-account identity.

### Anthropic documentation

* [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage)
* [Configure permissions](https://code.claude.com/docs/en/permissions)
* [Claude Code security](https://code.claude.com/docs/en/security)
* [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview)
* [Monitor Claude Cowork activity with OpenTelemetry](https://support.claude.com/en/articles/14477985-monitor-claude-cowork-activity-with-opentelemetry)
* [Configure OpenTelemetry for Claude's Office agents](https://support.claude.com/en/articles/14447276-configure-a-custom-opentelemetry-collector-for-office-agents)
* [Review what Claude Tag has done](https://claude.com/docs/claude-tag/admins/audit)

### Applicable Harmonic guides for Anthropic

* [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide)

## OpenAI

### Overview

OpenAI routing starts with two polled sources. The ChatGPT Enterprise Compliance API delivers messages and responses across Chat, Work, and Codex, and Codex governance exports deliver ChatGPT-authenticated Codex activity. API-key-authenticated Codex use is excluded. Neither the Compliance API nor OpenAI's 30-day Compliance Logs Platform records Work files, actions, or tool calls. Codex can additionally export runtime logs through OpenTelemetry when an exporter is configured in the user-level `~/.codex/config.toml`.

Codex approval events are the best starter detection. Approval policies generate explicit approve and deny decisions, so a spike in denied requests, or a session moving to dangerous full access, is worth an alert. For Work actions, join message records to endpoint, plugin, connected-app, and target-system logs. Keep redaction close to collection so prompts, files, and secrets do not become SIEM data spills.

### OpenAI documentation

* [Compliance APIs for Enterprise Customers](https://help.openai.com/en/articles/9261474-compliance-apis-for-enterprise-customers)
* [Codex governance](https://developers.openai.com/codex/enterprise/governance)
* [Agent approvals & security](https://developers.openai.com/codex/agent-approvals-security)
* [Config Reference (Codex)](https://developers.openai.com/codex/config-reference)
* [Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq)

### Applicable Harmonic guides for OpenAI

* [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice)

## Frequently asked questions about routing AI telemetry to your SIEM

### What AI telemetry belongs in a SIEM?

Send metadata for prompts, model calls, tool calls, approvals, denials, connectors, egress, and identity events. Prioritize the low-volume, high-signal streams first — approval and denial decisions, sandbox changes, and connector grants — before ingesting verbose tool-call traces that are expensive to store and hard to search.

### Should full prompts go into the SIEM?

Usually not by default. Use redaction, hashing, or restricted evidence storage unless full content is required for a specific investigation class, and make the decision explicitly — Codex, for example, only exports raw prompts when an opt-in flag is set. A broad index full of prompts is itself a data-spill risk.

### What are good starter detections?

Ground detections in events the platforms actually emit. Codex approval denials and Claude Code permission denials are explicit policy-enforcement records, and both are worth alerting on when they spike or touch secrets paths. Add sandbox escalation, new connector scopes, external writes after untrusted content, and unexpected network destinations as the next tier.

### How should identities be normalized?

Map user, agent, API key, service account, device, and project identifiers into one investigation view before you need it. Vendor logs and endpoint logs rarely share an identity scheme, and API keys in particular need a documented human owner or the trail stops at the key.

### Who owns AI detections?

Security owns detection quality: the rules, their tuning, and their false-positive budget. Platform and app owners hold the runbooks for product-specific response, because containment steps differ between a workspace chat, a coding agent, and a hosted agent run.

## Applicable regulations and frameworks

| Governance page                                     | Relationship to this article                                                                                                 |
| --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| G.1 Map your controls to NIST AI RMF and CSF 2.0    | This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes.                        |
| G.2 EU AI Act obligations for deployers             | Conditional: for an in-scope high-risk system, this supports incident detection and escalation.                              |
| G.3 DORA and AI resilience in financial services    | Conditional: for a DORA-regulated workflow, this supports monitoring, investigation, audit evidence, and incident reporting. |
| G.5 SANS Critical AI Security Guidelines mapping    | This article implements relevant SANS Monitoring and GRC guidance.                                                           |
| G.6 Write an AI Acceptable Use Policy that holds up | This article supplies a technical or process control used to enforce the acceptable-use policy.                              |
| G.7 Ownership and RACI for AI security              | This control depends on the ownership and evidence responsibilities defined in the RACI.                                     |
| G.9 HIPAA controls for AI systems handling PHI      | Conditional: for a workflow handling ePHI, this supports HIPAA audit controls, activity review, and investigation evidence.  |

*G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.*

## Related handbook guidance

* [6. Observability, Audit & Evidence](/handbook/6.-observability-audit-and-evidence.md)
* [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility.md)
* [6.3 Compliance APIs by platform](/handbook/6.-observability-audit-and-evidence/6.3-compliance-apis-by-platform.md)
* [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths.md)
* [5.6 Incident response for AI system](/handbook/5.-threats-and-adversarial/5.6-incident-response-for-ai-system.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://handbook.harmonic.security/handbook/6.-observability-audit-and-evidence/6.5-routing-ai-telemetry-to-your-siem.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.