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
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
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
Applicable Harmonic guides for Anthropic
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
Applicable Harmonic guides for OpenAI
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
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
Was this helpful?