Vaikora › Blog › Detection & SOC

Microsoft Sentinel for AI Security: Integration Guide

Detection & SOC · June 30, 2026 · 10 min read

Microsoft Sentinel for AI security means capturing AI agent runtime telemetry, every tool call, prompt, and decision, into Log Analytics, then writing KQL detection rules to surface threats in real time. By forwarding policy decisions and runtime events to a Log Analytics custom table and authoring detection queries, your SOC team can identify policy violations, unusual tool sequencing, and authentication anomalies as they occur, keeping AI risks visible in your existing SIEM. Routing AI security events into Sentinel unifies your detection posture: SOC teams see AI anomalies in the same workspace where they're already monitoring infrastructure, identity, and endpoints.

Why Sentinel for AI Agent Monitoring

Microsoft Sentinel is the natural home for AI agent security monitoring. It ingests data from hundreds of sources, correlates across cloud and on-premises infrastructure, and surfaces high-fidelity alerts to human analysts. That same pattern applies to AI agents. The alternative, a separate AI-specific monitoring tool, fragments your alerting, forces duplicate dashboards, and leaves blind spots where AI-specific events don't reach your core SOC workflow.

Sentinel's advantages for AI security are clear. First, you're leveraging infrastructure that's already deployed and staffed: Log Analytics workspaces, incident response playbooks, and on-call rotations. Second, Sentinel's rule-authoring engine (KQL) scales to handle AI event streams and surface both low-importance alerts and high-priority anomalies in the same query. Third, Sentinel's playbooks and automation can respond to AI threats by pausing agent execution, invoking approval workflows, or logging raw decision traces for forensics.

The challenge is that Sentinel's built-in detections assume network traffic, user logins, and file access. AI agent events, prompt injections, tool-call anomalies, policy violations, are domain-specific. You need to ingest the right signals and author the right detection logic.

Ingesting AI Agent Events into Log Analytics

The first step is deciding what to send. Not every AI event belongs in Sentinel; your ingestion strategy should focus on security-relevant signals.

High-confidence events to ingest:

• Policy decisions: Every time an AI agent proposes an action and your runtime control system evaluates policy. Log the proposed action, the policy applied, and the decision: ALLOW, CONSTRAIN, LOG, or BLOCK.
• Authentication and authorization: Agent service principal authentication, API key validation, and role-based access control enforcement. Anomalies here often precede downstream abuse.
• Tool invocations: Every call to an external tool, database queries, API calls, email sends, with metadata: tool name, parameters (sanitized), result, latency, and error codes. This is where exfiltration often surfaces.
• Prompt and response data: Store sanitized prompts and responses (or hashes of them) for threat forensics. Include prompt source, timestamp, and model identifier.
• Anomalies detected locally: If your AI runtime includes local detection (unusual tool sequencing, repeated retries, sudden parameter escalation), send those events immediately.

Events to skip (or sample):

• Token parsing logs (too verbose).
• Per-token cost/usage tracking (useful for chargeback, not security).
• Routine cache hits (low signal-to-noise).

Use an Azure Function or Logic App to forward agent telemetry to a Log Analytics custom table, or use the Azure Monitor Logs Ingestion API. Batch events every 10-30 seconds to reduce API call volume while keeping latency acceptable.

Define a schema. Here's a minimal example:

AgentSecurityEvent
├── TimeGenerated (datetime)
├── AgentId (string)
├── TenantId (string)
├── EventType (string: PolicyEvaluation, ToolInvocation, AuthFailure, Anomaly)
├── Action (string)
├── PolicyDecision (string: ALLOW, CONSTRAIN, LOG, BLOCK)
├── ToolName (string)
├── ToolParameters (dynamic, sanitized)
├── ToolResult (string)
├── PromptHash (string, SHA-256)
├── ResponseHash (string, SHA-256)
├── ModelId (string)
├── ErrorCode (int)
├── Severity (int: 1-4)
├── SourceSystem (string)

KQL Queries for AI Threat Detection

Once data flows into Log Analytics, write KQL queries to detect abuse patterns. Sentinel will evaluate these queries on a schedule (every 5 minutes, every 15 minutes, etc.) and fire alerts when thresholds are met.

Query 1: Repeated policy violations by a single agent

AgentSecurityEvent
| where EventType == "PolicyEvaluation" and PolicyDecision in ("CONSTRAIN", "BLOCK")
| summarize ViolationCount = count(), UniqueDecisions = dcount(PolicyDecision) by AgentId, bin(TimeGenerated, 5m)
| where ViolationCount >= 5
| project TimeGenerated, AgentId, ViolationCount, Severity = 2

This detects an agent hitting policy limits repeatedly in a 5-minute window. High violation rates often indicate misconfiguration (agent stuck in a loop) or an attack (agent attempting unauthorized actions).

Query 2: Unauthorized tool invocations

AgentSecurityEvent
| where EventType == "ToolInvocation" and PolicyDecision == "BLOCK"
| summarize BlockedToolCount = count(), Tools = make_set(ToolName) by AgentId, TimeGenerated
| where BlockedToolCount >= 3
| project AgentId, BlockedToolCount, Tools, Severity = 3

If an agent repeatedly tries to call tools it's not authorized for, something is wrong. This query surfaces agents attempting forbidden actions.

Query 3: Sudden spike in tool invocation rate

AgentSecurityEvent
| where EventType == "ToolInvocation"
| summarize CallCount = count() by AgentId, bin(TimeGenerated, 1m)
| extend AvgRate = avg(CallCount) by AgentId
| where CallCount > (AvgRate * 3)
| project TimeGenerated, AgentId, CallCount, AnomalousIncrease = CallCount - AvgRate, Severity = 2

A normal agent might call tools at a baseline rate. A sudden 3x increase in one-minute call volume suggests either a runaway loop or an adversary. Adjust the multiplier based on your baseline behavior.

Query 4: Authentication failures followed by tool invocation

AgentSecurityEvent
| where EventType == "AuthFailure"
| join kind=inner (
    AgentSecurityEvent
    | where EventType == "ToolInvocation" and PolicyDecision == "BLOCK"
) on AgentId
| where TimeGenerated1 < TimeGenerated and TimeGenerated - TimeGenerated1 < 30s
| project TimeGenerated, AgentId, AuthFailure = EventType1, ToolBlock = EventType, Severity = 4

If an agent fails authentication and then immediately attempts (and is blocked from) a sensitive tool call, that's a high-confidence attack signal. The 30-second window keeps false positives low.

Query 5: High-entropy prompts or unusual model parameters

AgentSecurityEvent
| where EventType == "PolicyEvaluation" and PolicyDecision == "LOG"
| where Severity >= 3
| summarize Count = count() by AgentId, ModelId, bin(TimeGenerated, 10m)
| where Count >= 10
| project TimeGenerated, AgentId, ModelId, SuspiciousPromptCount = Count, Severity = 2

If your runtime control layer flags prompts as suspicious (high entropy, pattern-matched injection attempts, known jailbreak tokens), this query aggregates those LOG-level events. High frequency suggests fuzzing or probing.

Building an AI Security Workbook

Sentinel workbooks let SOC teams visualize AI agent health and threats in one pane. Here's a minimal workbook structure for AI agent monitoring.

Workbook sections:

1. Summary tiles: Event count (last 24 hours), unique agents, blocked actions, high-severity incidents. kusto AgentSecurityEvent | where TimeGenerated > ago(24h) | summarize Count = count(), Agents = dcount(AgentId), Blocked = countif(PolicyDecision == "BLOCK")

2. Timeline of policy decisions: Stacked area chart showing ALLOW, CONSTRAIN, LOG, and BLOCK over time. kusto AgentSecurityEvent | where EventType == "PolicyEvaluation" | summarize Count = count() by PolicyDecision, bin(TimeGenerated, 1h) | render areachart

3. Top agents by violation count: Table of agents with the highest policy violations, sorted descending. kusto AgentSecurityEvent | where PolicyDecision in ("CONSTRAIN", "BLOCK") | summarize Violations = count() by AgentId | top 10 by Violations

4. Tool invocation heatmap: Matrix showing which agents call which tools most frequently, color-coded by frequency. kusto AgentSecurityEvent | where EventType == "ToolInvocation" | summarize Count = count() by AgentId, ToolName | render table

5. Recent high-severity events: List of events with severity >= 3, sortable by time and AgentId. kusto AgentSecurityEvent | where Severity >= 3 | sort by TimeGenerated desc | project TimeGenerated, AgentId, EventType, PolicyDecision, ToolName, Severity

Alert Rules and Response Automation

Create Sentinel analytics rules (scheduled query rules) to convert KQL detections into incidents.

Rule: Repeated Policy Violations

• Query: (use Query 1 from above)
• Trigger: When ViolationCount >= 5 in any 5-minute period
• Alert severity: Medium
• Automation: Email SOC, create incident, attach KQL results

Rule: Unauthorized Tool Access Attempts

• Query: (use Query 2 from above)
• Trigger: When an agent is blocked from 3+ tools in 1 minute
• Alert severity: High
• Automation: Invoke playbook to pause the agent, notify the team lead, and query for historical similar patterns

Rule: Authentication Failure + Blocked Tool Call

• Query: (use Query 4 from above)
• Trigger: Any match
• Alert severity: Critical
• Automation: Auto-create incident, attach forensic data, and escalate to IR lead immediately

For automation, use Sentinel playbooks to call Logic Apps. Example playbook actions:

• Pause the agent: Call an Azure Function to set the agent's status to "paused" and queue a manual review.
• Collect forensics: Retrieve the raw prompt, response, and policy traces from your AI agent management platform.
• Notify external systems: Send an HTTPS webhook to your incident management tool (ServiceNow, Jira, etc.).

Tuning and False Positive Reduction

AI agent telemetry requires careful tuning. You'll see activity spikes during legitimate, heavy-load tasks (batch processing, data pipeline runs). Sentinel's built-in ML baselines can help, but manual tuning is often necessary.

Techniques:

• Baseline by workload: If you have batch jobs that legitimately show high activity volumes, exclude them from alert rules. Use where TenantId !in ("batch-jobs") to skip non-prod tenants.
• Severity weighting: Not every policy violation is equally important. A CONSTRAIN (agent action was modified, not blocked) carries lower risk than a BLOCK. Adjust query thresholds accordingly.
• Time-series anomaly detection: Sentinel supports ML-based anomaly rules. Use make_series and series_outliers() to detect statistically unusual patterns without hardcoding thresholds.

kusto AgentSecurityEvent | where EventType == "ToolInvocation" | make_series CallCount = count() on TimeGenerated from ago(7d) to now() step 1h by AgentId | extend Anomalies = series_outliers(CallCount) | where Anomalies != 0

• Whitelisting: For agents that are known to call tools as part of normal operation, add a row to a whitelist table and join against it in your detection queries.

Compliance and Audit Trail

Storing AI agent events in Log Analytics automatically gives you a searchable audit trail. For compliance with HIPAA, GDPR, PCI DSS, or SOC 2, your AI telemetry becomes evidence that you're monitoring runtime behavior and detecting anomalies in real time.

When a regulator asks, "How do you know your AI agent isn't exfiltrating data?", you can run a KQL query to show every blocked tool call over the past 90 days and explain how Sentinel detected and prevented it. That's defensible compliance.

How Runtime Policy Enforcement Works with Sentinel

AI security requires two layers: runtime policy enforcement and post-incident analysis. A runtime policy engine evaluates each AI action against defined rules, returning ALLOW, LOG, CONSTRAIN, or BLOCK in milliseconds. Every decision gets logged with metadata (action, policy applied, decision, timestamp). You then forward those policy decisions to Log Analytics to build your audit trail and write detection queries in Sentinel.

The open-source vaikora-llm-gateway (MIT) provides a reverse-proxy pattern for routing AI requests through a policy check layer. The vaikora-guard-mcp server (MIT) exposes policy evaluation as an MCP tool for AI agents to call directly. Both are available on GitHub. If you integrate a commercial policy control system (or build your own), the same forwarding pattern to Log Analytics applies: every policy decision becomes a Sentinel detection opportunity.

Frequently asked questions

How do you monitor AI agents in Microsoft Sentinel?

Ingest AI agent telemetry into a Log Analytics custom table: policy decisions, tool invocations, authentication events, and local anomalies. Write KQL queries to detect abuse patterns (repeated violations, blocked tools, spikes in activity rate). Create Sentinel analytics rules to trigger alerts and automate response. Use workbooks to visualize agent health and threat trends over time.

What KQL queries detect AI agent threats?

Look for repeated policy violations within a time window, spikes in tool-call rates relative to baseline, unauthorized tool access attempts, and authentication failures followed by blocked actions. Use aggregation and anomaly detection to surface statistically unusual patterns. Baseline normal behavior per agent and tenant to reduce false positives.

Can Microsoft Sentinel detect AI agent attacks?

Yes. Sentinel can detect prompt injection attempts (if flagged by your runtime control layer), tool-call anomalies (unusual sequences or rates), repeated authorization failures, and attempted exfiltration (blocked sensitive tool calls). Detection quality depends on the telemetry you ingest and the detection rules you author.

How do you build an AI security workbook in Sentinel?

Open Sentinel Workbooks and create a new workbook. Add summary tiles showing event counts (last 24 hours), unique agent count, blocked action count, and incident count. Add a timeline chart displaying policy decisions (ALLOW, CONSTRAIN, LOG, BLOCK) over time. Include a sorted table of top-offending agents by violation count. Add a heatmap showing which agents call which tools most frequently. Finally, add a table of recent high-severity events (severity >= 3) sorted by timestamp. Each tile queries your AgentSecurityEvent table using KQL; Sentinel renders results as charts, tables, and heatmaps. The workbook becomes your real-time AI agent health dashboard.

What should I send to Sentinel from my AI agent runtime?

Send policy decisions (ALLOW, CONSTRAIN, LOG, BLOCK), every tool invocation with sanitized parameters and result, authentication and authorization events, local anomalies detected by your agent runtime, and error conditions. Skip routine logs with low security signal (token parsing, cache hits, usage tracking).

How often should Sentinel evaluate AI threat detection rules?

Every 5 to 15 minutes, depending on your tolerance for alert latency. AI agent events can be frequent; you can afford shorter intervals. For near-real-time response, consider a Logic App that processes events as they arrive instead of a scheduled rule.

More from the Vaikora blog