A blocked prompt injection attempt is only useful if the security team can connect it to the application, identity, route and outcome that produced it. That is the practical reason to send LLM logs to SIEM: not to create another high-volume telemetry stream, but to give incident response and compliance teams evidence they can act on without copying customer prompts into a second system.
LLM traffic makes conventional application logging more difficult. A single user interaction may involve sensitive input, a policy decision, a routing choice, a model-provider response and an output moderation result. If each application logs these elements differently, the SIEM becomes a collection of partial stories. If it captures every payload indiscriminately, it becomes a sensitive data store with a much larger blast radius.
The right design preserves decision context while deliberately limiting content exposure.
Decide what your SIEM needs to prove
A SIEM does not need a transcript of every model conversation to detect most operational and security problems. It needs structured events that answer who made a request, what control was applied, what happened, and whether an investigator can correlate that event with surrounding activity.
For each LLM request, a useful event normally includes a timestamp, application or service identity, environment, request or trace identifier, selected provider and model where available, route, outcome, latency, usage or cost data, and policy actions. It should also capture the decision that matters to security operations: whether prompt shielding identified an attack pattern, DLP detected sensitive data, a request was redacted or blocked, or output moderation stopped a response.
This creates evidence that is useful across teams. Security analysts can investigate unusual policy blocks. Platform teams can isolate rising failure rates by provider or route. FinOps can correlate spend anomalies with a deployment or tenant. Compliance teams can demonstrate that controls were applied consistently, rather than relying on an application team's assertion that they were.
The trade-off is straightforward. More fields can improve investigation quality, but every additional field has a retention, access-control and data-protection cost. Treat prompt and completion content as exceptional data, not default observability data.
Use a governed event model before exporting logs
The fastest way to create unusable SIEM data is to forward raw logs from each LLM client library and hope normalisation can happen later. Establish a common event model first, then make every application and gateway emit against it.
At a minimum, separate events into three operational categories. Request lifecycle events show that a request started, completed, failed or timed out. Policy events show that a control logged, warned, redacted or blocked activity. Governance events record changes to routes, routing rules, scoped API keys, spend caps or access boundaries. Keeping these categories distinct makes alerts more precise and retention policies easier to administer.
Use stable identifiers throughout. A trace identifier should connect the gateway event to the application request, while service identity and environment distinguish a production incident from test traffic. Avoid using email addresses, account numbers, prompt snippets or raw customer identifiers as correlation keys. Where an internal user or tenant reference is necessary, use an approved pseudonymous identifier already recognised by your security and privacy teams.
Normalisation should happen at the collection boundary, not inside every detection rule. Map provider-specific response codes, model names and failure reasons into a common schema, while retaining a controlled raw field where genuinely needed for engineering investigation. This matters when applications use several providers: a provider failover is an operational event, not necessarily an error, and your SIEM schema should make that distinction clear.
Keep payloads out of the default path
The central logging decision is whether prompts and completions leave the production request path. For most teams, the answer should be no by default.
Metadata-only logging gives teams the operational record they need without automatically retaining the contents that may contain personal data, confidential source code, contract terms or regulated records. Payload retention should be explicit opt-in, narrowly scoped, access-controlled and time-limited. A blanket decision to retain prompts for debugging usually becomes difficult to defend once traffic volumes and user groups expand.
DLP controls reduce exposure before the request reaches a provider. Where the policy action is redact, records should show that redaction occurred and that the affected value was replaced with [REDACTED]. The SIEM event should not preserve the original value simply to make an alert more descriptive. If the policy is block, record the policy outcome, category and correlation identifiers, then direct investigators to the approved case-management process rather than reproducing the payload in an alert.
This approach also prevents an avoidable failure mode: sending well-protected application data to a SIEM with broader access, longer retention and different regional processing arrangements. Your log architecture must meet the same data residency and access requirements as the LLM workflow it observes.
Send LLM logs to SIEM through one control point
A governed gateway is the most practical collection point because it sees the policy and routing decisions that an application client cannot reliably reconstruct. Rather than adding separate logging middleware for every provider, applications send requests through one governed doorway and the gateway's per-request traces become the source for normalised security events.
With routeur.ai, an application can retain its OpenAI-compatible client pattern while directing traffic through the governed endpoint. The application change is limited to the API key and base URL, leaving business logic byte-for-byte identical.
import os from openai import OpenAI
client = OpenAI( api_key=os.environ["ROUTEUR_KEY"], base_url="https://api.routeur.ai/v1" )
response = client.chat.completions.create( model="auto", messages=[ {"role": "user", "content": "Summarise this support case."} ] )The gateway should evaluate controls in a defined order: prompt shield first, then DLP, then routing, then output moderation. That order matters to SIEM interpretation. A blocked request was not routed to a provider. A DLP-redacted request may continue with altered content. An output moderation event occurs after a provider response has been received. Without this context, analysts can misread policy events as provider failures or assume a provider processed data it never received.
Export only the trace metadata required by your event model. If your SIEM collector supports batching, use it to reduce network and ingestion overhead, but do not delay high-severity block events beyond the incident-response window your team has defined. For high-volume workloads, apply different retention tiers to routine successful requests, policy warnings and confirmed blocks.
Build detections around decisions, not keywords
Keyword alerts on prompt text are noisy, privacy-invasive and easy to evade. The stronger detection strategy uses patterns in policy outcomes, identities, routes and rates.
A sudden increase in prompt-shield blocks from one service identity may indicate a compromised integration, a misconfigured internal tool or an attempted misuse campaign. Repeated DLP warnings in a workflow that normally handles only public data can reveal an upstream data-classification failure. A rise in output-moderation blocks after a model or route change may require a product review, not a security escalation.
Cost and availability signals belong in the same operational view. A sharp change in provider selection, latency or usage can be correlated with application releases, model availability and routing priorities. Hard spend caps should be treated as control events: when a cap is reached, the request is alerted on or blocked with a 429 response. It is not evidence that traffic was automatically rerouted to avoid the budget.
Detection thresholds depend on the workload. An internal coding assistant and a customer-facing claims workflow have different normal patterns, different data classifications and different escalation paths. Start with a small set of high-confidence rules, review outcomes with the teams owning the applications, then tune from observed behaviour.
Make SIEM evidence usable during an incident
A security event is only as useful as the investigation path that follows it. Every LLM alert should identify the owning service, environment, relevant trace identifier, policy result and first responder. Define who can access any associated payload retention system, if one exists, and require a case reference for access. The SIEM should be the index of the event, not an unrestricted prompt archive.
Test the workflow with realistic scenarios: a prompt injection attempt, a DLP block, an output moderation block, a provider failure and a budget-cap response. Confirm that the investigator can establish what happened without needing raw content, and that engineering can find the relevant per-request trace without exposing unrelated requests.
The goal is not more LLM telemetry. It is a defensible operational record: enough context to respond quickly, enough control to protect data, and one clear path from an alert to the request decision that caused it.