AI Logs in a SIEM Need Decisions, Identity, and Content Minimization
AI logs sent to a SIEM should record caller identity, model route, policy version, data classification, decision, latency, and correlation IDs. Raw prompts and responses require a separate content decision. OpenTelemetry can standardize model events, while an independent gateway record proves what policy allowed before the call.

A provider latency event and a policy decision answer different incident questions. The latency event says the model call took 1.8 seconds. The decision record says which authenticated agent sent it, which rule allowed it, and what data class crossed the boundary. A SIEM needs both without becoming a warehouse of copied prompts.
TL;DR
- Send the caller identity and model route to the SIEM. Include the policy version, classification, outcome, timing, and correlation IDs in the same event.
- Treat raw prompt and response content as a separate, restricted data stream.
- Use telemetry standards for event shape. Keep an independent enforcement record as authorization evidence.
Start with the incident question
NIST's Guide to Computer Security Log Management frames logging around collection, storage, analysis, and operational responsibility. For AI traffic, the useful fields start with the decision: caller identity, agent or application, requested model, provider endpoint, policy version, classification result, action, reason code, timestamp, and request ID.
Add duration and token counts when they support operations. Provider status belongs in the event when it helps distinguish a policy denial from a failed upstream call. Keep credential values out. A key alias can identify the provider account without leaking the secret.
The event should let an investigator reconstruct the request path without reading the request body. Start with the authenticated principal, then connect that identity to the application or agent that initiated the call. Record the selected route separately from the requested model because a gateway may redirect an allowed request to another approved endpoint.
Policy context needs the same precision. A policy name alone becomes ambiguous after the rule changes. The version records which rule set was evaluated at that moment, while the action and reason code explain the result. The request ID connects that decision to later telemetry without copying sensitive content into every system.
OpenTelemetry covers model events
The OpenTelemetry generative AI semantic conventions define attributes and events for model operations. They give platform teams a common vocabulary for providers, models, operations, usage, and errors. Adoption status and individual attributes can change, so pin the convention version in the collector configuration.
Telemetry emitted by an application reflects what that application recorded. An independent gateway decision answers a different question: what traffic crossed the controlled boundary. Our AI audit-log guide explains why that write path should remain outside the application under review.
Keep the telemetry envelope stable even when individual providers expose different response fields. The collector can normalize model names and usage measurements while preserving the original provider status where an investigation requires it. The gateway record can then contribute the authenticated identity and policy decision through the shared request ID.
This separation also clarifies ownership. Application teams can instrument model operations without controlling the authorization evidence used to review their calls. Security teams can query the gateway decision while platform teams continue using provider spans to diagnose latency or service errors.
Raw content needs another pipe
Prompts and responses may contain source code, health information, legal advice, customer records, or credentials. Shipping that content into a broad SIEM index expands access and retention. Store classifications and hashes in the general event when those fields settle the investigation. Route approved full content to a restricted evidence store with narrower roles and a shorter period.
At 2 a.m., an analyst should be able to pivot from one blocked request to the affected identity without opening the customer's entire prompt. I think raw-prompt-by-default logging is indefensible once a classification layer exists.
A content reference can preserve the investigative path without placing the content in the primary index. The SIEM event can carry a restricted record identifier after the content store accepts the approved copy. Access to that record should follow the evidence store's controls rather than inheriting every SIEM user's permissions.
The same split supports deletion. Operational metadata may remain useful after the approved content period ends because it still shows the caller, route, decision, and timing. Removing the prompt or response should not break the correlation chain needed to count denials or examine model-route changes.
Detection rules should use policy facts
Useful alerts include repeated denied requests by one identity, sudden model-route changes, fallback to an unapproved provider account, classification spikes, missing identity context, and direct model egress that bypasses the gateway. Correlate gateway IDs with provider and application spans.
The AI policy enforcement guide covers the upstream control. A SIEM detects patterns and supports investigation. It cannot retroactively prevent a prompt that already reached the model.
Build detections from fields that describe the policy decision directly. A denied action with a reason code is stronger evidence than a text search for words that might appear in an application message. Missing identity context should also be visible as its own condition because an unlinked event weakens every later investigation.
Route changes deserve a baseline tied to the authenticated identity or application. A new provider account may be legitimate after an approved configuration change. The correlation ID gives the analyst a path to compare the gateway decision with the provider span before escalating the event.
DeepInspect
DeepInspect evaluates authenticated HTTP AI traffic inline and emits per-decision records with identity and route information. Each record also carries policy, classification, outcome, and timing. Those records can feed a SIEM while full content follows a separately approved retention path.
Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Should token counts go to the SIEM?
They can support cost and anomaly analysis. Keep them as operational metadata and avoid presenting them as proof of content safety.
Token counts can show that a call differed from the caller's normal pattern. They cannot reveal which policy evaluated the content or why the gateway allowed it. Pair them with the request ID so an analyst can inspect the corresponding decision record when the count triggers an alert.
- Can application logs serve as the audit record?
They help, but an application can omit or lose its own event. Independent boundary records give stronger evidence of what was permitted or denied.
Application telemetry remains useful for debugging because it can describe the operation from the caller's perspective. The boundary record covers the enforcement point. Joining both records through the same correlation ID shows the application's intended request alongside the gateway's actual decision.