Which AI events belong in the SIEM?

Send decisions and administrative changes that support detection, including denied and redacted request decisions. High-risk permits and events with missing identity also belong in the SIEM. Record exception use and route changes. Policy publication and evidence-integrity failures also belong there. Sample routine low-risk permits if volume demands it, while retaining the full record in the authoritative audit store. Keep raw sensitive prompts out of the SIEM unless a documented investigation process and access model support them.

Is every blocked prompt an incident?

A blocked prompt alone is insufficient to declare an incident. A block can show that policy worked. Triage severity should reflect the data class and actor. Repetition and destination also affect severity. Intent indicators and alternate-path evidence complete the assessment. One accidental paste of an internal identifier differs from repeated attempts to send a credential set across several model routes. The decision event supplies the facts needed to make that distinction without weakening the control.

What should the SOC test before launch?

Run an allowed request and a restricted-data request. Test a missing-identity request and an expired exception. Try an unapproved destination and a policy rollback. Finish the launch test with a simulated evidence-write failure. Confirm the outcome at the client and the event fields in the SIEM. Then test an alternate egress path and a local process so the runbook records where visibility ends. The boundary result belongs in the launch evidence.

AI Governance for SOC Analysts: Turn Policy Decisions Into Investigable Events

An AI policy decision becomes useful to the SOC when it arrives as a structured event. The analyst needs the caller identity and application. The event should also show the model route and data classification. It must identify the policy version and outcome, along with the correlation ID. A message saying "unsafe prompt blocked" creates a ticket. A record showing that a finance user tried to send pre-announcement earnings data to an unapproved model at 02:17 UTC creates an investigation.

I think the SOC should reject any AI control that produces screenshots as its main evidence. Analysts need events they can join and filter against policy history. They also need to replay them.

TL;DR

SOC analysts need structured AI decision events. Each event should identify the identity and route. It should record the classification and policy. The outcome, reason, and correlation fields complete the record.
Detection content should focus on repeated denials and sensitive-data attempts. It should also cover route bypass and missing identity. Exception abuse and policy changes near an event need their own detections.
Response playbooks must preserve the original decision record. They must join it with application and identity-provider logs. Endpoint and destination logs complete the evidence.
HTTP AI controls cover routed model traffic. Local processes require separate telemetry, as do downstream tool actions.

Governance should produce security events

NIST SP 800-61 Revision 3, published in April 2025, places incident response inside broader cybersecurity risk management. The guidance aims to improve preparation and detection, followed by response and recovery. AI governance should feed that loop with records designed for analysis, rather than periodic compliance exports.

Start the event schema with the decision ID and timestamp. Record the authenticated principal and role, then the tenant and source application. Include the route and destination model. Add the data classifications and policy version. Finish with the decision outcome and reason code, plus the exception ID and correlation ID. Include hashes or references for protected content rather than copying every prompt into the SIEM. The SOC needs context without turning its analytics platform into a second repository for regulated data.

AI security for SOC teams covers the other side of the issue: analysts themselves send internal telemetry to models during triage. Governance has to protect those requests while also giving the SOC usable events about the rest of the enterprise.

Detection logic starts with deviations

A single denied request may show a working control. A pattern can show misuse or broken workflow design. It may also expose a compromised identity or policy confusion. Build detections around changes and concentrations.

Useful signals include repeated attempts to send the same restricted class and one identity testing several unapproved model routes. Watch for a service account producing user-like prompt volume and decisions missing required identity claims. An exception used outside its approved application also matters. So does a sharp rise in redaction events after a deployment. Correlate those signals with policy-administration events. A burst of permitted requests immediately after a policy change deserves different scrutiny than the same traffic under a stable rule.

The AI incident response playbook should name thresholds and owners for each pattern. Keep the first alert understandable to the on-call analyst. One row showing identity, route, classification, outcome, and policy version gives the analyst a place to start. Twelve loosely related dashboard panels usually slow the first ten minutes.

My preferred test is simple: can the on-call analyst explain why the event fired without opening the policy repository? If the answer is no, the reason codes need work.

Triage preserves the decision chain

Triage begins by validating the event and its control boundary. Confirm that the request traversed the governed HTTP route. Check the identity assertion against the identity provider. Retrieve the exact policy version and exception state. Match the application event with the model-provider request where available, then determine whether the control blocked, redacted, or permitted the request.

A denied event confirms prevention on the governed route and gives the analyst a starting point for investigating alternate paths. Check whether the same actor used another route, an unmanaged credential, or a local desktop client. A permitted event involving newly classified data may require containment even though the policy behaved exactly as configured. Governance policy can be wrong, and the evidence should make that visible.

Signed audit logs for AI requests strengthen the chain of custody. NIST SP 800-86 provides practical guidance for using forensic techniques during incident response. Preserve the original record and signature verification result. Keep the policy version and correlation fields with them, and store analyst notes separately. The event under investigation should remain unchanged while the case file records each later interpretation.

Response respects adjacent control surfaces

The traffic path determines the containment action. For a routed HTTP model call, response may disable a route or revoke an exception. It may narrow a role or change a data-class rule. Suspending a principal is another option. If the event points to local MCP execution over STDIO, endpoint tooling owns containment. If a remote tool performed an unauthorized business action, the destination system and MCP authorization logs become part of the case.

This boundary discipline prevents the SOC from asking one control to explain an entire agent workflow. The AI request record proves the policy decision on the model-call path. Application telemetry proves the initiating business action. Identity-provider logs prove the related authentication activity. Remote MCP and destination logs prove the tool invocation and resulting state change.

The AI operational governance loop closes when incident findings change policy and later events prove the treatment took effect. Record the owner and effective time. Keep the policy version and validation request with that record. Recovery is complete when the protected workflow returns under the new rule and the SOC can see that rule operating.

DeepInspect

DeepInspect evaluates deliberately routed HTTP AI traffic between authenticated users or agents and LLM endpoints. Each request receives an identity-aware policy decision based on role and data classification. The decision also accounts for the model route and policy state. The system produces a signed, tamper-evident per-decision record outside the application write path.

For the SOC analyst, those records become investigable events with stable reason codes and correlation fields. DeepInspect covers the governed AI HTTP route. Endpoint telemetry and identity-provider logs add evidence from adjacent systems. MCP server records and destination-system evidence complete the wider case. Book a technical deep dive at deepinspect.ai.