Connect ManageEngine MDM to AI Agents: Execute Actions and Compliance

You want to connect ManageEngine MDM to an AI agent so your IT systems can independently audit device fleets, enforce compliance policies, track missing hardware, and execute remote actions based on real-time organizational context. Here is exactly how to do it using Truto's /tools endpoint and SDK, bypassing the need to hardcode dozens of complex Mobile Device Management endpoints manually.

Giving a Large Language Model (LLM) read and write access to your ManageEngine MDM instance is a massive engineering undertaking. You either spend sprints building, hosting, and maintaining a custom connector that understands the nuances of MDM profiles and asynchronous device commands, or you use a managed infrastructure layer that handles the boilerplate for you. If your team uses ChatGPT, check out our guide on connecting ManageEngine MDM to ChatGPT, or if you are building on Anthropic's models, read our guide on connecting ManageEngine MDM to Claude. For developers building custom autonomous IT 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 ManageEngine MDM, bind them natively to an LLM using LangChain (or any framework like LangGraph, CrewAI, or Vercel AI SDK), and execute complex IT compliance workflows. For a deeper look at the architecture behind this approach, refer to our research on architecting AI agents and the SaaS integration bottleneck.

Why a Unified Tool Layer Matters for IT Automation Agents

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

Direct API tools - exposing one tool per raw ManageEngine MDM endpoint - look convenient initially, but they push provider-specific quirks directly into the LLM's context window. The model has to remember that requesting a device location doesn't return the location immediately, but instead returns an export batch ID. It has to understand that assigning a payload to a profile requires a different JSON schema depending on the payload type. Every one of those quirks is a hallucination waiting to happen.

A unified tool layer collapses these complexities behind a stable, semantic schema. Your agent sees manage_engine_mdm_devices_perform_action, manage_engine_mdm_compliance_groups_associate, and manage_engine_mdm_devices_request_location - each strictly typed. That gives you concrete safety wins:

1. Smaller attack surface for hallucination. The LLM only ever chooses from a stable list of function names. It never invents undocumented command IDs or incorrect HTTP verbs.
2. Deterministic input validation. Every tool has a strict JSON schema. Invalid arguments are rejected locally before they ever hit the ManageEngine API, so a broken tool call fails fast instead of creating a malformed compliance policy.
3. Decoupled authentication. The agent has no concept of API keys, OAuth tokens, or ManageEngine specific headers. It just knows it has tools.

The Engineering Reality of ManageEngine MDM APIs

Building AI agents is easy. Connecting them to external IT infrastructure securely is hard. If you decide to hand-roll this integration yourself, you own the entire API lifecycle. ManageEngine's MDM API introduces several highly specific integration challenges that break standard LLM assumptions.

Asynchronous Device Commands

When an agent wants to find a device, standard REST conventions assume a simple GET request returns the data. In ManageEngine MDM, many device actions are asynchronous. If an agent calls manage_engine_mdm_devices_request_location, the API does not return the latitude and longitude. It initiates a request to the physical device and returns an export_batch_id with a status. The agent must know it has to wait, and then subsequently call manage_engine_mdm_devices_get_location_with_address to retrieve the finalized data. If you expose raw APIs, the LLM will hallucinate that the initial 202 Accepted response contains the location data, leading to downstream logic failures.

Polymorphic Profile Payloads

ManageEngine MDM allows administrators to push configuration profiles to devices (e.g., Wi-Fi settings, Passcode policies, VPN configurations). The endpoint to update a payload (manage_engine_mdm_profiles_bulk_update) requires a highly polymorphic request body. The JSON structure for a VPN payload looks entirely different from a Web Content Filter payload. If an LLM is given a raw, untyped tool, it will invariably mix up the properties. By using heavily validated JSON schemas via Truto, the LLM is forced into the correct structure for the specific payload type before the request fires.

Group vs. Device State Conflicts

MDM operates heavily on group inheritances. A device might be non-compliant because of a group policy, but an agent might attempt to remediate it by applying a fix directly to the device ID rather than the group ID. Structuring your tools so that group operations and device operations are distinctly named prevents the LLM from attempting to apply global policies to singular endpoints.

Fetching ManageEngine MDM Tools

Truto maps ManageEngine MDM resources into Proxy APIs and exposes them as a unified list of tools. You fetch these tools via the /tools endpoint and inject them into your agent framework.

Here is how you do it using the Truto LangChain.js SDK.

import { ChatOpenAI } from "@langchain/openai";
import { TrutoToolManager } from "@trutohq/truto-langchainjs-toolset";
import { AgentExecutor, createOpenAIToolsAgent } from "langchain/agents";
import { ChatPromptTemplate } from "@langchain/core/prompts";
 
// 1. Initialize the Truto Tool Manager with your ManageEngine [integrated account ID](/how-to-architect-a-multi-tenant-mcp-server-for-enterprise-b2b-saas/)
const toolManager = new TrutoToolManager({
  trutoApiKey: process.env.TRUTO_API_KEY,
  integratedAccountId: "manageengine_mdm_acc_xyz123"
});
 
async function runAgent() {
  // 2. Fetch the ManageEngine MDM tools dynamically
  const tools = await toolManager.getTools();
  
  console.log(`Loaded ${tools.length} ManageEngine MDM tools`);
 
  // 3. Initialize your LLM
  const llm = new ChatOpenAI({
    modelName: "gpt-4o",
    temperature: 0,
  });
 
  // 4. Bind the tools to the prompt and agent
  const prompt = ChatPromptTemplate.fromMessages([
    ["system", "You are an elite IT Operations AI assistant managing a ManageEngine MDM instance. You execute device actions, check compliance, and manage profiles securely."],
    ["human", "{input}"],
    ["placeholder", "{agent_scratchpad}"],
  ]);
 
  const agent = await createOpenAIToolsAgent({
    llm,
    tools,
    prompt,
  });
 
  const executor = new AgentExecutor({
    agent,
    tools,
    max_tools: tools,
    verbose: true,
  });
 
  // 5. Execute an autonomous IT workflow
  const result = await executor.invoke({
    input: "Find the device belonging to 'sarah.connor', check its compliance status, and if it is non-compliant, initiate a remote lock."
  });
 
  console.log(result.output);
}
 
runAgent();

In this script, the TrutoToolManager queries Truto, retrieves the full JSON schema for every configured ManageEngine MDM method, wraps them in LangChain-compatible @tool objects, and binds them to the model. The agent can now orchestrate multi-step IT actions entirely on its own.

Hero Tools for ManageEngine MDM

While Truto exposes the entire API surface area, certain endpoints are disproportionately useful for agentic workflows. Here are the hero tools you should prioritize when building MDM agents.

1. list_all_manage_engine_mdm_devices

This is the foundational discovery tool. It allows the agent to search the managed device inventory by username, email, serial number, or platform to retrieve internal device IDs required for subsequent actions.

"Search our managed inventory for any iOS devices assigned to the engineering group and list their current OS versions and battery levels."

2. manage_engine_mdm_devices_perform_action

This tool executes high-stakes remote actions on a specific device, such as RemoteLock, CorporateWipe, CompleteWipe, or EnableLostMode. Agents use this heavily during offboarding or incident response scenarios.

"The MacBook with serial number C02X12345 has been reported stolen. Enable lost mode immediately and trigger a full remote wipe."

3. manage_engine_mdm_compliance_groups_associate

Instead of managing device compliance individually, this tool allows the agent to attach a pre-configured Fence Policy (compliance profile) to entire device groups simultaneously, ensuring bulk enforcement.

"Associate our 'Strict Geofence' compliance policy to the 'Contractors' device group."

4. manage_engine_mdm_devices_request_location

Triggering this tool requests the physical location of a managed device. Because of MDM constraints, this initiates the request to the device. The agent must use the resulting batch ID to poll for the final coordinate data.

"Ping the last known location for device ID 88392. Let me know when the coordinates are available."

5. manage_engine_mdm_blacklist_apps_blocklist_devices

Essential for automated Shadow IT mitigation. This tool allows the agent to apply specific blocklisted app groups directly to an array of non-compliant devices, forcing removal or restricting access.

"Find the app group ID for 'TikTok' and apply the blocklist command to all devices currently registered to the marketing team."

6. manage_engine_mdm_scheduled_actions_suspend

This tool allows the agent to halt a previously scheduled IT action (like a fleet-wide remote restart or shutdown). It acts as an emergency brake if an administrator flags an erroneous scheduled task.

"Suspend the scheduled action named 'Weekend Fleet Restart' immediately before it executes."

For the complete tool inventory, request schemas, and available parameters, view the ManageEngine MDM integration page.

Workflows in Action

When you combine these tools in an agentic loop, you move beyond simple API wrappers and unlock autonomous IT operations. Here is how specific personas use these workflows in production.

Scenario 1: Automated Stolen Device Mitigation

When a user reports a lost device, security teams need to act in seconds. An agent can completely automate the containment process.

"John Doe reported his iPad as stolen. Find his device, enable lost mode, request its current location, and lock it down."

Step-by-step execution:

1. The agent calls list_all_manage_engine_mdm_devices using the search filter email=john.doe@company.com to retrieve the exact device_id.
2. The agent calls manage_engine_mdm_devices_perform_action with action_name="EnableLostMode" for that device.
3. The agent calls manage_engine_mdm_devices_perform_action again with action_name="RemoteLock".
4. Finally, the agent calls manage_engine_mdm_devices_request_location and informs the security team that mitigation is complete and location tracking has been initiated.

Result: The device is secured instantly without a human needing to log into the MDM console, navigate to the user, and click through multiple warning modals.

Scenario 2: Shadow IT Elimination

Compliance platforms often detect unauthorized software. An AI agent can automatically enforce removal without raising manual IT tickets.

"Audit the executive group for the unauthorized app 'Dropbox'. If found, blocklist the app on those specific devices."

Step-by-step execution:

1. The agent calls list_all_manage_engine_mdm_groups to find the group_id for "Executives".
2. The agent calls manage_engine_mdm_groups_list_members to get all device_ids in that group.
3. The agent iterates through the devices, calling manage_engine_mdm_devices_list_apps to check installed software against the prohibited list.
4. If violations are found, the agent calls list_all_manage_engine_mdm_blacklist_apps to find the internal app group ID for Dropbox.
5. The agent calls manage_engine_mdm_blacklist_apps_blocklist_devices to forcibly restrict the app on the violating endpoints.

Result: Shadow IT is identified and remediated autonomously, maintaining strict SOC 2 or ISO 27001 compliance postures.

Scenario 3: Offboarding and Profile Cleanup

When an employee leaves, their device needs to be uncoupled from sensitive internal profiles and sanitized.

"Sarah is leaving the company today. Remove all associated MDM profiles from her MacBook, then wipe it."

Step-by-step execution:

1. The agent calls list_all_manage_engine_mdm_devices filtering by Sarah's details to get her MacBook's device_id.
2. The agent calls manage_engine_mdm_devices_disassociate_profiles to strip VPN, Wi-Fi, and email configurations.
3. The agent calls manage_engine_mdm_devices_perform_action passing action_name="CorporateWipe" to remove all corporate data while leaving personal data intact.

Result: The offboarding process is handled safely and programmatically, reducing the IT ops queue and ensuring no residual access remains.

Building Multi-Step Workflows and Handling Rate Limits

When an AI agent is orchestrating multi-step API calls across hundreds of devices, it is guaranteed to encounter rate limits. This is where naive integration code fails.

Factual note: Truto does not retry, throttle, or apply backoff on rate limit errors. If the underlying ManageEngine MDM API returns an HTTP 429 (Too Many Requests), Truto passes that 429 error directly back to the caller. However, Truto normalizes the disparate upstream rate limit information into standardized IETF headers: ratelimit-limit, ratelimit-remaining, and ratelimit-reset.

Because Truto exposes these headers cleanly, your agent infrastructure is responsible for implementing the retry and backoff logic. If your agent is running in a LangGraph loop or a while-loop, you must catch the 429, read the reset window, and pause execution.

sequenceDiagram
  participant Agent as AI Agent
  participant Truto as Truto Proxy
  participant MDM as ManageEngine API

  Agent->>Truto: Tool Call: get_certificates (Device 1)
  Truto->>MDM: GET /api/v1/mdm/devices/1/certificates
  MDM-->>Truto: 200 OK
  Truto-->>Agent: Certificates data
  
  Agent->>Truto: Tool Call: get_certificates (Device 2)
  Truto->>MDM: GET /api/v1/mdm/devices/2/certificates
  MDM-->>Truto: 429 Too Many Requests
  Truto-->>Agent: 429 Error (ratelimit-reset: 10)
  
  Note over Agent: Agent detects 429.<br>Sleeps for 10 seconds.
  
  Agent->>Truto: Tool Call: get_certificates (Device 2)
  Truto->>MDM: GET /api/v1/mdm/devices/2/certificates
  MDM-->>Truto: 200 OK
  Truto-->>Agent: Certificates data

When building custom agents in TypeScript, you wrap your tool executions or provide fallback behavior in your LLM framework to handle this graceful degradation.

For example, if you are using LangChain, you can implement a custom tool error handler that inspects the error object, checks for the ratelimit-reset header, and instructs the agent to wait before proceeding. This guarantees your autonomous fleet sweeps don't crash halfway through an audit.

Strategic Architecture for IT Agents

Connecting AI agents to systems like ManageEngine MDM fundamentally changes how IT Operations function. Instead of humans translating intent into clicks across complex UI dashboards, agents translate natural language intent into typed, validated API tool calls.

By leveraging Truto's /tools endpoint, you abstract away the authentication, the pagination, and the shifting schemas of the underlying vendor. Your agent only sees a reliable menu of actions, allowing your engineering team to focus on building better autonomous reasoning loops rather than debugging endpoint idiosyncrasies.