Connect Microsoft Sentinel to AI Agents: Automate Security Ops

You want to connect Microsoft Sentinel to an AI agent so your system can autonomously triage incidents, query threat intelligence indicators, execute response playbooks, and update security tickets. Here is exactly how to do it using Truto's /tools endpoint and SDK, bypassing the need to build and maintain a custom Microsoft Sentinel API integration from scratch.

If your team uses ChatGPT, check out our guide on connecting Microsoft Sentinel to ChatGPT, or if you are building on Anthropic's models, read our guide to connecting Microsoft Sentinel to Claude. For developers building custom autonomous workflows, you need a programmatic way to fetch these tools and bind them to your agent framework.

Building an AI agent for Security Operations (SecOps) is a straightforward exercise in prompting and state management. Giving that agent reliable access to a complex SIEM like Microsoft Sentinel is where projects stall. If you decide to build a custom connector, you own the entire API lifecycle. You must write the JSON schemas for the LLM to understand the endpoints, handle the Azure OAuth token lifecycle, normalize pagination, and deal with deeply nested Azure Resource Manager (ARM) paths.

This guide breaks down exactly how to fetch AI-ready tools for Microsoft Sentinel, bind them natively to an LLM using frameworks like LangChain, LangGraph, CrewAI, or the Vercel AI SDK, and execute complex security workflows. For a broader look at this design pattern across the enterprise stack, read our guide on Architecting AI Agents: LangGraph, LangChain, and the SaaS Integration Bottleneck.

The Engineering Reality of the Microsoft Sentinel API

Giving a Large Language Model (LLM) access to external data sounds simple in a prototype. You write a Node.js function that makes a fetch request and wrap it in an @tool decorator. In production against complex enterprise systems, this approach collapses.

Microsoft Sentinel's API introduces several specific integration challenges that break standard REST assumptions. If you hardcode these interactions into your agent, you will spend your sprints writing defensive integration code instead of improving your model's reasoning.

The Azure Resource Manager (ARM) Path Trap

Microsoft Sentinel is not a standalone product; it sits on top of Azure Log Analytics workspaces. Because of this, every API request requires navigating the Azure Resource Manager (ARM) hierarchy. A standard LLM expects a clean REST endpoint like /incidents/123. Instead, the Microsoft Sentinel API requires paths that look like this:

/subscriptions/{subscription_id}/resourceGroups/{resource_group_name}/providers/Microsoft.OperationalInsights/workspaces/{workspace_name}/providers/Microsoft.SecurityInsights/incidents/{incident_id}

If you expose the raw API to an LLM, the model must flawlessly construct this path every single time. It will inevitably hallucinate a UUID, forget a path segment, or swap the workspace_name for the resource_group_name. Your agent needs a proxy layer that abstracts the ARM hierarchy into simple, flat parameters.

ETag-Based Optimistic Concurrency

Microsoft strictly enforces Optimistic Concurrency Control using ETags (If-Match headers) for update operations. If an AI agent wants to update the severity of a Microsoft Sentinel incident, it cannot simply fire off a PATCH request with the new severity.

It must first execute a GET request to fetch the incident, extract the etag value from the response, and include that exact etag in the subsequent update request. If the ETag is missing or stale, the API rejects the request with a 412 Precondition Failed error. LLMs are notoriously bad at remembering to pass opaque string tokens between independent tool calls. Exposing this requirement to the model guarantees high failure rates.

Handling API Rate Limits Deterministically

A critical architectural note: Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Microsoft Sentinel API returns an HTTP 429 Too Many Requests, Truto passes that error directly to your caller.

What Truto does do is normalize the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. Your agent framework is responsible for catching the 429 and executing the retry and backoff logic. Do not assume the integration layer will magically absorb rate limit errors - you must handle them in your agent loop.

Hero Tools for Microsoft Sentinel AI Agents

To safely expose Microsoft Sentinel to an LLM, you must use a unified tool layer. Truto provides these via the /tools endpoint. Your agent sees stable function names and deterministic JSON schemas, completely abstracted from the underlying ARM paths and ETag enforcement.

Here are the highest-leverage tools available for Microsoft Sentinel automation.

1. List All Microsoft Sentinel Incidents

Retrieves a list of incidents from a specified Log Analytics workspace. This tool abstracts the pagination and filtering logic, allowing the agent to ingest open security incidents without formatting ARM paths.

Usage note: Agents typically call this tool on a cron schedule or at the start of a triage loop to find New or Active incidents.

"Fetch all open Microsoft Sentinel incidents in the 'secops-prod' workspace that were created in the last 24 hours."

2. Get Single Microsoft Sentinel Incident By ID

Fetches the complete details of a specific incident, including its severity, status, title, description, and related entities.

Usage note: Required before an agent can attempt to analyze or update an incident. This provides the context window with the necessary metadata.

"Get the details for incident ID '7a4c92f1-4b31-4e2a-9d6a-4d2b7e5c3a1' to understand what triggered the alert."

3. List All Microsoft Sentinel Incident Alerts

Retrieves the raw security alerts that are correlated to a specific incident. An incident is just a container; the alerts contain the actual detection logic and signals.

Usage note: This is the most critical tool for an autonomous SOC analyst agent. The agent must read the underlying alerts to determine if the incident is a false positive.

"Retrieve all the underlying alerts for incident '7a4c92f1-4b31-4e2a-9d6a-4d2b7e5c3a1' so I can review the raw detection signals."

4. Create a Microsoft Sentinel Incident Run Playbook

Executes an Azure Logic App playbook against a specific incident. This bridges the gap between AI decision-making and deterministic automation.

Usage note: Once the LLM determines an incident is malicious, it can use this tool to trigger a predefined containment playbook (e.g., isolating a host or blocking an IP in a firewall).

"Run the 'Isolate-Defender-Endpoint' playbook on incident '7a4c92f1-4b31-4e2a-9d6a-4d2b7e5c3a1' to contain the threat."

5. Update a Microsoft Sentinel Incident Task By ID

Creates or updates a specific task tied to an incident. This is used to track the steps taken during an investigation.

Usage note: Use this tool to force the agent to document its work. As the agent performs actions, it should check off incident tasks to keep human analysts informed.

"Update the task 'Check IP Reputation' on incident '7a4c92f1-4b31-4e2a-9d6a-4d2b7e5c3a1' to mark it as completed."

6. Create a Microsoft Sentinel Main Indicator

Creates or updates a threat intelligence indicator (IOC) within the workspace.

Usage note: If the agent identifies a malicious IP address, domain, or file hash during its investigation, it can use this tool to automatically ingest the indicator into Sentinel for future alerting.

"Add the IP address '198.51.100.45' as a high-confidence threat intelligence indicator in the workspace."

For the complete inventory of available endpoints, schemas, and required parameters, review the Microsoft Sentinel integration page.

Workflows in Action

When you bind these tools to an LLM, you unlock autonomous workflows that previously required a team of Tier 1 SOC analysts. Here is how specific security personas utilize this architecture.

Scenario 1: Autonomous Alert Triage

Tier 1 analysts spend hours doing basic data gathering on new incidents. An AI agent can perform this triage instantly.

"A new incident just fired for 'Suspicious Login Activity'. Gather the alerts, check the associated IP addresses against our threat intel, and update the incident comments with your findings."

1. The agent calls list_all_microsoft_sentinel_incident_alerts to pull the raw detection data.
2. The agent parses the alerts and extracts the source IP address.
3. The agent calls an external threat intelligence tool (e.g., VirusTotal or GreyNoise) to check the IP reputation.
4. The agent calls update_a_microsoft_sentinel_incident_comment_by_id to append its analysis, noting whether the IP is a known Tor exit node or VPN.

The human analyst opens the incident and immediately sees a summarized brief of the underlying alerts and the external reputation of the entities involved.

Scenario 2: Threat Intelligence Ingestion

Security engineers constantly read threat reports and need to extract Indicators of Compromise (IOCs) to feed into their SIEM.

"Read this PDF threat report from Mandiant, extract all malicious domains and file hashes, and ingest them as threat intelligence indicators in Microsoft Sentinel."

1. The agent uses a document parsing tool to read the PDF and extract the IOCs.
2. The agent loops over the extracted domains and hashes.
3. For each IOC, the agent calls create_a_microsoft_sentinel_main_indicator to inject the threat data directly into the Sentinel workspace.

The security engineering team automates the tedious process of copying and pasting indicators from threat reports into Azure.

Scenario 3: Incident Containment and Playbook Execution

When an incident is a confirmed true positive, the agent can trigger the remediation phase.

"This incident represents a confirmed credential theft. Block the user's account and execute the host isolation playbook."

1. The agent calls create_a_microsoft_sentinel_incident_run_playbook passing the logicAppsResourceId for the 'Disable-AzureAD-User' playbook.
2. The agent calls create_a_microsoft_sentinel_incident_run_playbook passing the logicAppsResourceId for the 'Isolate-Defender-Endpoint' playbook.
3. The agent calls update_a_microsoft_sentinel_incident_by_id to change the incident status from Active to Closed and sets the closing classification to TruePositive.

The threat is contained within seconds of the decision being made, without requiring a human to log into the Azure portal.

Building Multi-Step Workflows

To build an autonomous agent, you must fetch the tool schemas from Truto, bind them to your LLM, and construct an execution loop. The agent must be able to reason about errors, handle missing parameters, and chain multiple tools together.

Here is how you architect this using standard open-source frameworks. This pattern works with LangChain, LangGraph, the Vercel AI SDK, or any system that supports OpenAI-compatible tool schemas.

sequenceDiagram
    participant Agent as Agent Loop
    participant TrutoSDK as Truto Tool Manager
    participant LLM as Large Language Model
    participant Sentinel as Microsoft Sentinel API
    
    Agent->>TrutoSDK: Initialize with Integrated Account ID
    TrutoSDK-->>Agent: Return normalized tool schemas
    Agent->>LLM: bindTools(schemas) + User Prompt
    
    loop Tool Execution
        LLM-->>Agent: function_call (e.g., get_single_microsoft_sentinel_incident_by_id)
        Agent->>TrutoSDK: Execute tool with JSON payload
        TrutoSDK->>Sentinel: Proxied REST API Request
        Sentinel-->>TrutoSDK: JSON Response
        TrutoSDK-->>Agent: Return JSON string to context
        Agent->>LLM: Pass tool observation back to model
    end
    
    LLM-->>Agent: Final summarized text response

Implementation Example

Below is a TypeScript example demonstrating how to initialize the tools and build the execution loop. We use the @langchain/core library to manage the message state and the truto-langchainjs-toolset to handle the schema generation and execution.

import { ChatOpenAI } from "@langchain/openai";
import { TrutoToolManager } from "truto-langchainjs-toolset";
import { HumanMessage, ToolMessage } from "@langchain/core/messages";
 
async function runSecOpsAgent() {
  // 1. Initialize the LLM
  const model = new ChatOpenAI({ 
    modelName: "gpt-4o",
    temperature: 0 
  });
 
  // 2. Fetch Microsoft Sentinel tools via Truto
  // You get this ID after authenticating the Sentinel tenant via Truto Link
  const toolManager = new TrutoToolManager({
    integratedAccountId: process.env.TRUTO_SENTINEL_ACCOUNT_ID,
    trutoApiKey: process.env.TRUTO_API_KEY,
  });
  
  const tools = await toolManager.getTools();
  
  // 3. Bind the deterministic schemas to the LLM
  const modelWithTools = model.bindTools(tools);
 
  // 4. Initialize the conversation state
  const messages = [
    new HumanMessage("Fetch the details for incident ID '7a4c92f1', review its alerts, and summarize the threat.")
  ];
 
  // 5. The Agent Loop
  while (true) {
    const response = await modelWithTools.invoke(messages);
    messages.push(response);
 
    // If the LLM decides no more tools are needed, break the loop
    if (!response.tool_calls || response.tool_calls.length === 0) {
      console.log("Agent Finished:", response.content);
      break;
    }
 
    // Execute requested tools in parallel
    for (const toolCall of response.tool_calls) {
      console.log(`Executing tool: ${toolCall.name}`);
      
      try {
        // The tool manager maps the function name back to the correct Truto Proxy API
        const toolResult = await toolManager.executeTool(toolCall.name, toolCall.args);
        
        messages.push(new ToolMessage({
          tool_call_id: toolCall.id,
          content: JSON.stringify(toolResult)
        }));
      } catch (error) {
        // Error handling is critical.
        // If the upstream Sentinel API returns a 429, it surfaces here.
        // You must implement your backoff logic at this layer.
        console.error(`Tool execution failed: ${error.message}`);
        messages.push(new ToolMessage({
          tool_call_id: toolCall.id,
          content: `Error executing tool: ${error.message}. Please adjust your parameters or try again later.`
        }));
      }
    }
  }
}
 
runSecOpsAgent();

Handling Errors and Rate Limits

In the catch block above, the agent framework receives the raw error from the integration layer. Because Truto normalizes the rate limit headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset), your application code can inspect the error headers to determine exactly how long to wait before retrying the tool execution.

By passing the error message back into the context window as a ToolMessage, you allow the LLM to reason about the failure. If the error is a 400 Bad Request due to a malformed incident_id, the LLM can recognize its mistake and try again with the correct format.

Final Thoughts

Automating Security Operations requires a foundation of reliable integration infrastructure. If you force your AI agents to deal with raw Azure Resource Manager paths, OAuth token refreshes, and ETag collision handling, your agents will spend all their compute cycles failing at integration tasks rather than analyzing security threats.

By leveraging a unified tool layer, you restrict the LLM to a strict set of deterministic actions. The agent sees a list of capabilities, passes a JSON object, and receives clean data back.

Stop building fragile custom API wrappers for your AI agents. Build the intelligence, and let the infrastructure handle the connectivity.