Connect Microsoft Intune to AI Agents: Automate Remote Fleet Actions

You want to connect Microsoft Intune to an AI agent so your internal IT systems can independently audit device compliance, execute remote wipes, trigger Defender scans, and orchestrate fleet management based on security alerts. Here is exactly how to do it using Truto's /tools endpoint and SDK, bypassing the need to manually code dozens of Microsoft Graph API endpoints or maintain complex authentication wrappers.

Giving a Large Language Model (LLM) read and write access to your Microsoft Intune tenant is an engineering headache. You either spend weeks building, hosting, and maintaining a custom connector that understands OData queries and asynchronous remote actions, or you use a managed infrastructure layer that handles the boilerplate for you. If your team uses ChatGPT, check out our guide on connecting Microsoft Intune to ChatGPT, or if you are building on Anthropic's models, read our guide on connecting Microsoft Intune to Claude. For developers building custom autonomous workflows, you need a programmatic way to fetch these tools and bind them to your agent framework.

This guide breaks down exactly how to fetch AI-ready tools for Microsoft Intune, bind them natively to an LLM using frameworks like LangChain, LangGraph, CrewAI, or the Vercel AI SDK, and execute complex remote fleet actions. For a deeper look at the architecture behind this approach, refer to our research on architecting AI agents and the SaaS integration bottleneck.

The Engineering Reality of Custom Microsoft Intune Connectors

Building AI agents is easy. Connecting them to external enterprise IT platforms is hard. Giving an 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, this approach collapses entirely, especially with an ecosystem as complex as Microsoft Intune and the Microsoft Graph API.

If you decide to build this integration yourself, you own the entire API lifecycle. The Microsoft Graph API introduces several highly specific integration challenges that break standard LLM assumptions.

The OData and Nested Relationship Trap

Microsoft Graph relies heavily on OData query parameters ($filter, $select, $expand) rather than simple RESTful path conventions. When an agent needs to retrieve a list of devices that are non-compliant, standard REST assumptions fail. The agent must know how to formulate a valid OData query string, understanding which properties can actually be filtered on (as Graph does not support filtering on every property).

If you hand-code this integration, you have to write complex prompts to teach the LLM the exact syntax of Microsoft Graph's OData implementation. When the LLM inevitably hallucinates a filter query on an unsupported property, the API throws a 400 Bad Request, and the agent loop crashes.

Asynchronous Remote Actions and State Blindness

In standard CRUD APIs, updating a record returns the updated state. Intune remote actions do not work this way. When you trigger a device wipe, lock, or scan, you do not use a PATCH request on the device. Instead, you call a specific action endpoint (e.g., .../wipe), which immediately returns an empty 204 No Content.

This creates state blindness for the LLM. The agent assumes the device is instantly wiped because the tool call succeeded. In reality, the action is queued for the device's next check-in via WNS (Windows), APNs (Apple), or FCM (Android). To verify success, the agent must know to query the device again and inspect the deviceActionResults array. Without a unified tool layer structuring this reality, the LLM will hallucinate successful operations before they actually occur.

Licensing and RBAC Quirks

Intune endpoints will often return 403 Forbidden or 400 Bad Request errors not because the OAuth token is invalid, but because the underlying tenant lacks an active Intune license, or the specific target user is not licensed, or the Role Scope Tags attached to the admin account restrict visibility. Exposing these raw Graph API errors to an LLM often causes the model to spiral into endless retry loops, hallucinating different payloads to fix an error that is fundamentally rooted in tenant licensing.

Why a Unified Tool Layer Matters for Agent Safety

Before writing a line of integration code, decide what layer your agent talks to. This choice determines how safe your production system will be.

Direct API tools (one tool per raw Microsoft Graph endpoint) push provider quirks directly into the LLM's context. The model has to remember OData syntax, asynchronous polling requirements, and complex payload structures. Every one of those quirks is a hallucination waiting to happen.

A unified tool layer collapses these endpoints into discrete, descriptive functions. Your agent sees microsoft_intune_managed_devices_wipe and list_all_microsoft_intune_device_compliance_policies instead of raw OData URIs. That gives you concrete safety wins:

1. Smaller attack surface for hallucination. The LLM only ever chooses from stable function names. It never invents OData $expand fragments.
2. Deterministic input validation. Every tool has a strict JSON schema. Invalid arguments are rejected before they hit Microsoft Graph, so a broken tool call fails fast instead of confusing the model.
3. Normalized Error Handling. Truto standardizes the errors returned by the upstream API, giving the LLM clear, parseable feedback when an action fails.

Architectural Note on Rate Limits

It is critical to understand how a proxy layer handles traffic. Truto does not retry, throttle, or apply backoff on rate limit errors. When Microsoft Graph returns an HTTP 429 Too Many Requests, Truto passes that error directly back to the caller (your agent framework).

However, Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. This allows your agent framework to catch the 429, read the ratelimit-reset header, and execute a deterministic sleep before retrying, rather than hallucinating a fix.

sequenceDiagram
    participant Agent as AI Agent Framework
    participant Truto as Truto Tool Layer
    participant Graph as Microsoft Graph (Intune)
    
    Agent->>Truto: Call microsoft_intune_managed_devices_wipe(id)
    Truto->>Graph: POST /deviceManagement/managedDevices/{id}/wipe
    
    alt Rate Limited
        Graph-->>Truto: 429 Too Many Requests
        Truto-->>Agent: 429 (with IETF ratelimit headers)
        Note over Agent: Agent parses headers & sleeps
    else Success
        Graph-->>Truto: 204 No Content
        Truto-->>Agent: Tool execution successful
    end

Hero Tools for Microsoft Intune AI Agents

To build a highly capable IT automation agent, you do not need to give it access to all 200+ Intune endpoints. You just need to provide it with high-leverage "hero tools" that cover discovery, inspection, and remediation.

Here are the most critical Intune tools exposed via Truto, how they work, and how an LLM can use them.

1. List All Managed Devices

Tool name: list_all_microsoft_intune_managed_devices

This is the foundational discovery tool. It returns the fleet of enrolled devices, including their id, deviceName, operatingSystem, complianceState, and lastSyncDateTime. Agents use this to search for specific devices by user or state.

"Find all Windows devices currently marked as non-compliant in Intune, and give me their device IDs and last sync times."

2. Get a Single Managed Device

Tool name: get_single_microsoft_intune_managed_device_by_id

Once an agent identifies a target device, it uses this tool to inspect the deep properties of that specific asset, reading the deviceActionResults array to check the status of previously issued remote actions.

"Check the status of the device with ID 8f8f9e... Has the remote wipe action we triggered yesterday completed yet?"

3. Remote Wipe a Device

Tool name: microsoft_intune_managed_devices_wipe

This executes a destructive remote wipe on the target device. The tool accepts optional parameters to control retention of enrollment data, user data, eSIM plans, and Mac obliteration behavior. It returns a 204 on success, initiating the action on Microsoft's end.

"The device belonging to user jdoe@company.com was reported stolen. Issue a remote wipe command immediately, but preserve the eSIM data plan."

4. Trigger Windows Defender Scan

Tool name: microsoft_intune_managed_devices_windows_defender_scan

Crucial for SecOps workflows, this tool commands a Windows device to initiate an antivirus scan. The agent can pass a boolean quickScan parameter to determine if it should be a quick or full scan.

"We received a suspicious alert from device DESKTOP-493. Trigger a full Windows Defender scan on it right now."

5. Sync Device

Tool name: microsoft_intune_managed_devices_sync_device

Because Intune devices normally check in on a schedule (e.g., every 8 hours), an agent needs to be able to force a check-in to push new policies or expedite pending remote actions. This tool triggers an immediate sync.

"I just assigned a new compliance policy. Force a sync on all devices belonging to the Engineering group so they pick up the new rules immediately."

6. List Device Compliance Policies

Tool name: list_all_microsoft_intune_device_compliance_policies

Agents use this to audit the rules applied to the fleet. It returns policy metadata, allowing the agent to map compliance states back to specific rule sets.

"List all active device compliance policies in our tenant. Are there any policies specifically targeting iOS devices?"

This is just a small sample of the available capabilities. For the complete inventory of Intune tools - including managing compliance policies, querying role scope tags, handling Autopilot identities, and configuring app protection - visit the Microsoft Intune integration page.

Workflows in Action

Individual tools are useful, but AI agents create value through multi-step autonomous workflows. Here is how specific personas utilize these tools in real-world scenarios.

Scenario 1: IT Admin Handling a Stolen Laptop

When a device is reported lost or stolen, response time is critical. Manual intervention requires an admin to log into the Intune portal, search for the user, find the specific device, and click through the wipe dialog.

"Sarah in marketing just reported her laptop stolen at a coffee shop. Secure the device immediately."

Agent Execution Flow:

1. Calls list_all_microsoft_intune_managed_devices filtering by Sarah's email to locate her assigned Windows device.
2. Extracts the id of the target laptop.
3. Calls microsoft_intune_managed_devices_wipe with the managed_device_id, triggering the remote wipe.
4. Returns a confirmation to the user that the wipe command has been successfully queued in Microsoft Graph.

Scenario 2: SecOps Remediating a Malware Alert

When an EDR platform alerts on suspicious behavior, an agent can instantly bridge the gap between the alert and the MDM remediation, isolating the risk before a human analyst even opens the ticket.

"We have a high severity alert on device DESKTOP-XYZ. Ensure it is scanned and force it to check in."

Agent Execution Flow:

1. Calls list_all_microsoft_intune_managed_devices to find DESKTOP-XYZ and retrieve its id.
2. Calls microsoft_intune_managed_devices_windows_defender_scan passing quickScan: false to force a deep inspection.
3. Calls microsoft_intune_managed_devices_sync_device to force the machine to check in with Intune immediately and pick up the scan command.
4. Logs the remediation actions back to the user.

flowchart TD
    A["User Prompt:<br>Remediate malware on DESKTOP-XYZ"] --> B["Agent<br>Decision Engine"]
    B --> C["Tool:<br>list_all_managed_devices"]
    C --> D["Tool:<br>windows_defender_scan"]
    D --> E["Tool:<br>sync_device"]
    E --> F["Return status<br>to user"]

Scenario 3: Compliance Auditing

Compliance drift happens when devices stop checking in or users modify local settings. An agent can proactively audit the fleet.

"Audit the fleet and give me a summary of all non-compliant devices, including their OS version and last sync time."

Agent Execution Flow:

1. Calls list_all_microsoft_intune_managed_devices.
2. The agent parses the returned JSON array, filtering out any device where complianceState is not equal to compliant.
3. Formats a clean report detailing the deviceName, osVersion, and lastSyncDateTime of the offending devices, ready for IT review.

Building Multi-Step Workflows

To execute these workflows, you need to bind Truto's proxy APIs to your agent framework. Because Truto provides tools via a standardized JSON schema representation via the /tools endpoint, you are not locked into any single framework. This works flawlessly with LangChain, Vercel AI SDK, CrewAI, or raw OpenAI/Anthropic API calls.

Step 1: Fetching the Tools

First, you fetch the available tools for the connected Intune account. Truto abstracts the integration schema into a format LLMs natively understand.

// Fetching tools via Truto's REST API
const trutoToolsResponse = await fetch(
  `https://api.truto.one/integrated-account/${INTEGRATED_ACCOUNT_ID}/tools`,
  {
    headers: {
      Authorization: `Bearer ${TRUTO_API_KEY}`
    }
  }
);
 
const availableTools = await trutoToolsResponse.json();
// availableTools contains the descriptions and JSON schemas 
// for wipe, sync, scan, etc.

Step 2: Binding Tools to the LLM

Using a framework like LangChain.js, you can use the TrutoToolManager to wrap these schemas into executable functions that the LLM can call.

import { ChatOpenAI } from "@langchain/openai";
import { TrutoToolManager } from "truto-langchainjs-toolset";
 
// Initialize the LLM
const llm = new ChatOpenAI({
  modelName: "gpt-4o",
  temperature: 0,
});
 
// Initialize the Truto Tool Manager
const toolManager = new TrutoToolManager({
  apiKey: process.env.TRUTO_API_KEY,
});
 
// Get executable tools for the Intune account
const intuneTools = await toolManager.getTools(INTEGRATED_ACCOUNT_ID);
 
// Bind the tools to the model
const llmWithTools = llm.bindTools(intuneTools);

Step 3: Handling Rate Limits in the Execution Loop

When building autonomous loops, error handling is paramount. As noted earlier, Truto does not swallow rate limit errors - it passes the HTTP 429 response back to your system. Microsoft Graph has strict throttling limits. If your agent executes a loop updating 50 devices concurrently, it will get throttled.

Your tool execution logic must catch these 429s and respect the ratelimit-reset header.

// Example logic for handling tool execution and rate limits
async function executeToolCall(toolCall, tools) {
  const tool = tools.find(t => t.name === toolCall.name);
  
  try {
    const result = await tool.invoke(toolCall.args);
    return result;
  } catch (error) {
    if (error.status === 429) {
      // Truto passes IETF rate limit headers from the upstream API
      const resetTime = error.headers['ratelimit-reset']; 
      const sleepDuration = calculateSleep(resetTime);
      
      console.warn(`Rate limited by Microsoft Graph. Sleeping for ${sleepDuration}ms`);
      await sleep(sleepDuration);
      
      // Retry the tool invocation
      return await executeToolCall(toolCall, tools);
    }
    throw error;
  }
}

By forcing the framework to handle the backoff, you maintain complete visibility into the performance and latency of your agentic workflows, rather than having an integration layer silently hang for 60 seconds while retrying.

Strategic Wrap-Up

Connecting AI agents to Microsoft Intune transforms IT administration from a reactive, click-heavy process into a proactive, conversational workflow. By leveraging a unified tool layer, you protect your LLM from the complexities of OData queries, licensing traps, and asynchronous state tracking.

Instead of spending engineering cycles maintaining custom OAuth flows and reading Microsoft Graph documentation, your team can focus on building intelligent decision engines that keep your fleet secure and compliant.