Microsoft Sentinel AI Logs Need a Deliberate Data Contract

A Microsoft Sentinel incident can contain an Azure OpenAI latency event and two related records: an application trace plus a gateway denial. All three describe the same model call. Without a shared correlation ID, those events look like three unrelated rows. Sentinel AI logs need a data contract before the first connector or diagnostic setting is enabled.

TL;DR

• Inventory Azure OpenAI diagnostics and application traces before choosing connectors. Include identity events and gateway decisions. Include network evidence as well.
• Use DCRs to normalize fields and route sensitive content separately. Let table design control retention by evidence type.
• Link service telemetry with the independent authorization decision through stable request and trace IDs.
• Build analytics around policy facts instead of prompt keyword searches. Start with denied actions and missing identity. Include route changes and gateway bypass.

Inventory the diagnostic sources

Microsoft Sentinel uses data connectors to bring sources into the workspace. Microsoft's connector guidance directs administrators to install the solution associated with a connector through Content Hub and shows installed or active connectors on the Data connectors page. A custom connector remains an option when a source lacks a packaged route.

For an Azure-hosted LLM application, list the evidence surfaces before configuration:

• Azure OpenAI resource metrics and logs for service availability and provider-side status, plus request behavior.
• Azure Activity Log events for resource administration and diagnostic-setting changes.
• Microsoft Entra sign-in and workload identity events for authentication context.
• Application traces for the caller's view of the operation.
• Gateway decision records for identity-bound authorization at the model-request boundary.
• Network or egress events for calls that attempt to bypass the approved route.

Preserve source type, resource ID, tenant, subscription and the original event reference before normalizing fields. That lets an investigator distinguish a model-service event from an identity change or an attempted route bypass.

Configure diagnostic export with its limits in view

Microsoft's Azure OpenAI monitoring guide says Azure Monitor collects and aggregates metrics and logs. Metrics live in the metrics database, while log data lives in the Azure Monitor logs store. Diagnostic settings can route metric and activity log data to other storage locations, and Log Analytics can query and link the resulting records.

Enable only the resource categories required by the incident and audit use cases. Record the scope and category selection. Record the destination workspace and configuration owner. Changes to the diagnostic setting should be monitored because disabling export can create an evidence gap.

Azure OpenAI telemetry reflects the service's perspective. It does not automatically become proof that a particular employee was permitted to send a classified prompt. Join it with a trusted identity event and an independent policy decision. The existing AI logs in a SIEM guide covers the field boundary between service telemetry and authorization evidence.

The monitoring guide also warns that diagnostic settings and Azure Monitor Logs can create additional costs. That makes minimization an operational control as well as a privacy decision.

Use DCRs to enforce the ingestion contract

A Data Collection Rule should express which streams enter the workspace, the transformations applied, and their destinations. Treat the DCR as reviewed infrastructure, then version and test it against representative events. Send unauthorized changes into a named security alert.

Normalize event time beside ingestion time, then add tenant, subscription, resource, and environment. Identify the authenticated subject and calling application or agent. Preserve provider, requested model, resolved model, and route. Finish the event with policy version, data classification, action, reason code, request ID, trace ID, latency, and source type.

Preserve the original provider field when normalization could lose meaning. A normalized Outcome=Denied can sit beside the gateway's native decision code. This lets detection content remain stable while investigators retain access to the exact source semantics.

Reject secrets at ingestion. Credential values and authorization headers have no place in the analytic event. Connection strings do not belong there either. Hashes or stable aliases can identify the affected account without copying the secret.

Put events in tables that match access and retention

Use table placement to separate operational telemetry from two security data classes: decisions and restricted content. AzureDiagnostics may be useful for supported resource logs, and Microsoft's monitoring example queries that table for TimeGenerated and _ResourceId. It also queries Category and OperationName, along with duration and result information. A purpose-built custom table can provide a cleaner schema for normalized gateway decisions.

Keep raw prompts and responses out of the general security table. Those bodies can contain source code, health records, legal material, customer messages, or credentials. Store the classification, content hash, byte count, and restricted evidence reference in the Sentinel event. Send approved full content to a separate store with narrower roles and its own deletion schedule.

Our AI audit log JSON schema offers a starting point for the decision event. Preserve the source event ID so an analyst can return to the original record instead of depending on a transformed copy alone.

I think default prompt ingestion into a broad SIEM workspace is indefensible. A midnight responder first needs the identity, route, decision, and reason code. Full customer content should require a separate, logged access path.

Correlate the request path

Generate a request ID at the controlled entry point and carry it through the application and gateway. Continue carrying it into the provider integration when the interface permits. Use a trace ID for distributed application spans and preserve provider request identifiers as separate fields. One identifier should never be overwritten with another source's value.

Trace the investigation from the authenticated subject into the calling application. The matching gateway decision shows which policy governed the request, and provider telemetry confirms the upstream call and response. Match events by request ID and time bounds, with resource and route as secondary checks.

Clock skew and asynchronous processing need explicit handling. Record event time and ingestion time. A delayed provider event should still join to the original gateway decision. For batch work, keep a parent job ID with child request IDs rather than treating the entire file as one opaque call.

This correlation design supports LLM security monitoring without asking analysts to search copied prompt text for every investigation.

Build analytics from policy facts

Start with detections that use structured facts:

• Repeated denied model requests by one identity or agent.
• A privileged route used by a role outside its approved population.
• Missing identity context on a production call.
• A resolved model or provider that differs from the approved route.
• A spike in restricted-data classifications.
• Direct provider traffic with no matching gateway decision.
• A diagnostic setting or DCR changed outside the approved deployment path.

Give each rule an owner and investigation query. Add suppression logic and the expected response. A route change after an approved deployment may be routine. The same route change with no change record deserves escalation.

Prompt keyword alerts create noise and can pressure teams to retain more content than the investigation needs. Use content classification and policy reason codes as the first signal. Open restricted content only when the incident demands it.

Set retention by evidence purpose

Define retention separately for service telemetry and identity events. Set distinct periods for gateway decisions and full content. Define another period for incident case records. Base each period on the legal, contractual and investigation requirements for that data class. Avoid copying one default across every table.

Retention also includes deletion and access review. Test that expired restricted content disappears while metadata references remain understandable. Review who can query each table and export results. Review who can change retention. AI audit log retention is a policy decision backed by technical tests, rather than a workspace slider set once.

Archive choices should preserve queryability required by the incident plan. Document the restore path and run it during an exercise. Evidence that exists only in an archive nobody has tested is weak operational evidence.

DeepInspect

DeepInspect can emit per-decision records for authenticated HTTP AI traffic, including identity and route. The records also include policy version and classification. They include outcome and reason code, along with correlation fields. A DCR can normalize and route those records into a restricted Sentinel table while provider diagnostics keep their original service meaning.

DeepInspect covers requests deliberately sent through its HTTP enforcement point. Sentinel retains the wider investigation view across identity, Azure resources, applications, and network evidence.

Book a technical deep dive at deepinspect.ai.