# Intune in Claude for help desk lookups only

> Intune in Claude for a help desk is one allow rule, not six blocks: the msintune connector carries 198 tools and only 69 of them read.

**TL;DR** Elaichi's msintune connector carries 198 tools, and only 69 of them read. Blocking the six obvious device actions leaves every other write reachable, so hold the help desk role with an allow rule naming the read tools it needs, plus allow rules for the other apps that role uses. Connect Intune with the narrowest Microsoft account that covers those reads, because msintune calls reach Microsoft Graph as the connecting account.

## What a help desk ticket actually needs from Intune

A technician picks up a ticket: this laptop never applied the new Wi-Fi profile. The answer sits in Microsoft Intune. Which devices does the person have, is each one compliant, which configuration profiles landed, what apps were detected. Five read calls and the ticket closes. Putting Intune in Claude is worth doing for exactly that loop. The risk is everything else that arrives with it.

[Elaichi's `msintune` connector](/connectors/msintune/) carries 198 tools. Sixty-nine have names starting with `list_` or `get_`, and they read, including `list_all_msintune_managed_devices`, `get_single_msintune_managed_device_by_id`, `list_all_msintune_device_compliance_policies`, `list_all_msintune_device_configurations` and `list_all_msintune_detected_apps`. Most of the other 129 create, update or delete records, or run actions on devices: wipe, retire, remote lock, script deployment and more.

Elaichi serves 600+ connectors through one organization-wide MCP endpoint. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. The design question for any connected app is the same: which of a connector's tools may a given role reach, and how is that decision enforced so it cannot quietly widen over time? For Intune specifically, that means deciding on the 69 read tools. Write the decision down once, rather than re-deciding it per technician or per incident.

## General principle: allowlists survive, denylists decay

Before the Intune specifics, the underlying rule generalizes to any tool-calling AI connector, not just MCP or Elaichi:

- **A denylist only covers what you named.** Every tool you didn't think to block on the day you wrote the rule stays reachable. Tools a connector gains later are reachable by default unless the denylist is re-audited on every connector update.
- **An allowlist is closed by construction.** Naming the tools a role *may* use means everything else is denied, including tools that don't exist yet. This is the standard [default-deny posture applied to tool calls](/blog/least-privilege-tool-calls-without-breaking-automation/).
- **The two produce different failure modes.** A denylist fails open (new or unnamed tools leak through). An allowlist fails closed (a technician hits a wall and has to file a request). Some workflows carry a high downside from an unreviewed write, such as device wipe, user deletion or remote lock. For those, fail-closed is the only defensible default.

This is a restatement of a well-known security principle (default-deny beats default-allow), not something specific to Elaichi.

## Why blocking wipe and retire is not read-only

Six blocks is the obvious move, and it does not produce a read-only role. A block rule covers only the tools it names.

The six that come to mind: `msintune_managed_devices_wipe`, `msintune_managed_devices_retire`, `msintune_managed_devices_remote_lock`, `msintune_managed_devices_reset_passcode`, `msintune_managed_devices_bypass_activation_lock` and `delete_a_msintune_managed_device_by_id`. Block all six and the role still holds `msintune_managed_devices_execute_action`. That tool runs a named remote action on one or more devices via two arguments, `actionName` and `deviceIds`. Blocks on the six named tools do not cover it. A block matches a tool's name or its pinned operation, and this is a different operation.

Still reachable after those six blocks:

| Tool | Effect |
|---|---|
| `msintune_managed_devices_clean_windows_device` | Cleans a Windows device, with a choice to keep or remove user data |
| `msintune_managed_devices_reboot_now` | Reboots the device |
| `msintune_managed_devices_shut_down` | Shuts the device down |
| `msintune_managed_devices_disable` | Disables a managed device |
| create/assign device management scripts | Creates scripts and assigns them to groups of devices |
| `delete_a_msintune_user_by_id` | Deletes a Microsoft Entra ID user, not just a device |

A denylist is a list of the writes somebody thought of on the day it was written. It is not, and cannot become, a complete inventory of what a connector can do. The wider trade-off between blocking individual tools and blocking an entire app is in [restricting one tool against the whole app](/blog/per-tool-vs-per-app-restrictions/).

## Writing the allow rule for Intune in Claude

Intune in Claude becomes a lookup tool when the help desk role holds an allow rule. That rule names the five read tools above, not a stack of blocks. A restriction in Elaichi states which connectors and tools a role or a user may reach. Name the five, and every other `msintune` tool is denied for that role by default.

One property catches people out: **an allow rule is the target's entire allowlist across every connector, not just the app it mentions.** Allow rules on the same role union together: the role's allowlist is the sum of every allow rule attached to it. If the help desk role also uses Slack and Jira, you must write a separate allow rule naming each of those connectors in full. Without them, the role loses Slack and Jira as soon as the Intune-only allow rule takes effect. The presence of any allow rule switches that role from default-allow to default-deny across the board.

Two mechanical details matter before you save the rule:

- **A withheld tool is invisible, not just blocked.** The tool index is filtered before search runs, so a denied tool's name reaches neither `tools/list` nor `search_tools`. The model never sees it exists, rather than seeing it and being refused.
- **A restriction change is not instant.** It takes effect within about two minutes. Blocks match a tool's name or its pinned operation; allows match the pinned operation only. That asymmetry is the subject of [why allows bind the operation](/blog/block-matches-name-allow-matches-operation/).

## Which Microsoft account should hold the Intune connection?

Connect with the narrowest Microsoft account that covers the required reads. The `msintune` connector signs in with OAuth as a person, so every call reaches [Microsoft Graph](https://learn.microsoft.com/en-us/intune/intune-service/developer/intune-graph-apis) as that account (checked October 2026). A shared connection runs on its owner's credential. Every technician's lookup reaches Graph as the connecting account, regardless of what Microsoft role that individual technician holds personally. The opposite shape, where [each person connects their own account](/blog/sales-team-chatgpt-salesforce-accounts/), is the right one when the app's own permissions should decide what each caller sees.

That account's Intune role is the outer limit; Elaichi's restrictions narrow access from there, never widen it. Compare the three systems that stack on top of each other:

| Layer | Narrowest safe option | What it permits | What it still permits beyond "read-only" |
|---|---|---|---|
| Microsoft built-in role | Read Only Operator | View devices, policies, configs | Retrieve a FileVault recovery key (a remote action) |
| Microsoft built-in role (common mistake) | Help Desk Operator | Wipe, retire, remote lock and reset passcode | Device actions; not read-only |
| Microsoft Graph permission | `DeviceManagementManagedDevices.Read.All` | Read device records | Nothing beyond reading device records |
| Microsoft Graph permission | `.ReadWrite.All` | Reads, plus delete device records, bypass Activation Lock | Deletion and lock bypass |
| Microsoft Graph permission | `.PrivilegedOperations.All` | Wipe, retire, remote lock, reset passcode, Lost Mode | All privileged device actions |
| Elaichi restriction | Allow rule naming 5 read tools | Exactly those 5 calls | Nothing, whatever Graph permissions the account holds |

Never connect as a Global Administrator, whose reach goes far beyond Intune.

The account you connect with is a ceiling the Elaichi allow rule sits under, never a floor it can raise. A delegated app cannot exceed the signed-in user's own permissions ([Graph permissions overview](https://learn.microsoft.com/en-us/graph/permissions-overview), checked October 2026). All three Graph permissions above need an administrator's consent whether the call is delegated or app-only ([Intune Graph APIs](https://learn.microsoft.com/en-us/intune/intune-service/developer/intune-graph-apis), checked October 2026; [built-in roles reference](https://learn.microsoft.com/en-us/intune/fundamentals/role-based-access-control/ref-built-in-roles), checked October 2026). Pairing Read Only Operator with the five-tool allow rule gives two independent layers that both have to agree before a write can happen.

## Multi Admin Approval as a second signature on device actions

Multi Admin Approval is Intune's own opt-in second-signature control. It applies to calls made through Graph, delegated and app-only alike, not just the Intune admin center UI. It is configured as an access policy scoped to a specific resource type. The device actions policy covers wipe, retire and delete only. It is a backstop against the three worst outcomes, not a general write gate across all 129 non-read tools ([Multi Admin Approval](https://learn.microsoft.com/en-us/intune/fundamentals/role-based-access-control/multi-admin-approval), checked October 2026). Separate access policies can protect scripts, apps, and compliance and configuration policies.

It applies to changes only, never to reads, so a help desk role doing lookups never triggers it. A protected call does not queue silently: it fails immediately and returns an approval request. The action runs only after a second administrator approves it in the Intune admin center and the original request is resubmitted with the approval code. Applications cannot approve their own requests. Changes to the access policies themselves always require a second administrator's sign-off, so one administrator cannot switch it off alone.

Multi Admin Approval and an Elaichi allow rule solve different problems. The allow rule stops a role from ever seeing the wipe tool. Multi Admin Approval adds a second human in the loop. It covers the rare case where a role that does have wipe access tries to use it.

## Adding the endpoint in Claude, and what consent decides

On Claude Team and Enterprise, an Owner or Primary Owner adds Elaichi once, at Organization settings, Connectors, Add, Custom, Web ([Anthropic's documentation](https://claude.com/docs/connectors/custom/add-unlisted), checked October 2026). The address is `https://api.elaichi.ai/mcp` for every organization. Members then connect it individually under Customize, Connectors, each with their own OAuth grant.

The consent screen is not where read-only access comes from. For a connected app's tools, the "Run your connected tools" checkbox enables reads and writes equally. Only a tool whose underlying method is a delete additionally requires the delete checkbox. "Create and change data" left unticked governs Elaichi's own internal operations, not Intune's write tools at all. Read-only Intune access comes from the allow rule, every time, not from any consent checkbox.

Claude's own per-tool permission settings don't substitute for this either ([connector tool permissions](https://claude.com/docs/connectors/custom/add-unlisted), checked October 2026). Elaichi's connected tools all route through a single `execute_tool` call on Claude's side. So a permission set at that layer covers every connected app at once, not Intune specifically.

## When a technician needs a tool the allow rule leaves out

Any member can file an access request with no permission of their own. Resolving a request requires `member:manage`, and an administrator cannot approve their own request. This is the designed path for the Tuesday when somebody genuinely needs a device action the allow rule withholds.

Approving a restriction-caused request is standing and narrow, not a blanket re-opening of the role. A requester restricted through their role gets an **`except` rule**. That named exception grants exactly the one tool requested, to that one person. Every other rule on their role continues to apply. A restriction request cannot be approved from inside Claude, any other MCP client or the Elaichi Agent, so no AI surface can widen a restriction. Denying a request can be done from either surface.

## What the audit trail shows after a device lookup

Elaichi writes one entry per tool-call attempt, succeeded or failed. Each entry names the account actually reached, not the one a user meant to reach. So after a lookup, the entry shows which technician called `get_single_msintune_managed_device_by_id`, the Intune connection it reached and the outcome. Argument names and counts are logged, never their values, so the device ID looked up is not in the log.

Each entry also records the calling surface and the OAuth client. A call from Claude is logged as a user action with surface `mcp`, with Claude named and marked verified, because its redirect URIs prove it. The approval field reads "Allowed by the access Claude was granted". Over MCP, the standing grant is the approval, and there is no separate per-call approval step. Log writes are eventually consistent, so a given row can take a short time to appear after the call completes. The full field-by-field schema is in [what an AI agent audit log must capture](/blog/what-an-ai-audit-log-must-capture/).

## Who owns the Intune connection when that admin leaves

Pick a connection owner who is staying, because the connection runs on that person's Microsoft sign-in, not an abstract service identity. Removing a member in Elaichi triggers an offboarding preflight, a check that lists every connection the departing member owns before the removal completes. The preflight lists private and shared connections alike. Only private ones can block the removal. A shared connection is deleted only if the admin explicitly asks; otherwise the admin transfers it to a member who is staying. Use the transfer action before the person leaves. Transferring sets a new owner on the connection. It leaves every existing grant on it exactly as it was, with no re-approval needed.

Transferring ownership in Elaichi does not change the credential underneath. The connection still runs on the departing person's Microsoft sign-in, and that account still has to be deprovisioned in Microsoft Entra ID. So before it is, have the staying owner connect Intune with their own narrow account and share that connection with the help desk. A SCIM deprovision suspends the member in Elaichi rather than removing them. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. [Offboarding when the agent holds access](/blog/offboarding-when-the-agent-holds-access/) covers the rest of the preflight.

## Microsoft ships no Intune MCP server, so what else is there?

There is no official Microsoft MCP server for an Intune tenant today. Microsoft's MCP Server for Enterprise is a read-only Microsoft Entra preview with no Intune scopes ([get-started page](https://learn.microsoft.com/en-us/graph/mcp-server/get-started), checked October 2026). The alternative to a vendor gateway is self-hosting: an Entra app registration plus a host somebody on your team maintains and patches. [The real cost of running your own MCP servers](/blog/self-hosted-mcp-servers-vs-control-plane/) sets out what that ongoing maintenance involves.

If the help desk works entirely inside the Intune admin center, nothing needs to leave it, and none of this applies. A team with no need to ask device questions from Claude, ChatGPT or Cursor does not need a gateway at all.

The case for doing this through a gateway like Elaichi rather than a one-off connector is narrow and specific. One endpoint serves Intune alongside the rest of the stack. One role carries the allowlist across all connected apps, rather than one config per app. One audit trail answers who ran what across every tool, not just Intune's. The full tool list for each connected app is in the [connector catalog](/connectors/). The [use cases page](/use-cases/) shows the same pattern for other teams.

## FAQ

### Does Microsoft ship an official MCP server for Intune?

No. There is no official Microsoft MCP server for an Intune tenant. Microsoft's MCP Server for Enterprise is a read-only Microsoft Entra preview with no Intune scopes ([learn.microsoft.com](https://learn.microsoft.com/en-us/graph/mcp-server/get-started), checked October 2026). Teams reaching Intune from Claude or ChatGPT today either run a server themselves or use a governed MCP control plane such as Elaichi, whose msintune connector carries 198 tools.

### Is blocking the Intune wipe and retire tools enough to make an AI assistant read-only?

No. Elaichi's msintune connector carries 198 tools, and only 69 of them read. Blocking wipe, retire, remote lock, reset passcode, bypass Activation Lock and delete device still leaves msintune_managed_devices_execute_action, which runs a named remote action on one or more devices, plus reboot, shut down, disable, clean Windows device, device management scripts and delete_a_msintune_user_by_id. A block rule covers only the tools it names. An allow rule naming the read tools you want is how a role is held to lookups.

### Which Microsoft account should connect Intune to an MCP client?

The narrowest account whose Intune role covers the reads the team needs. Calls through Elaichi's msintune connector are delegated, so they reach Microsoft Graph as the connecting account, and a shared connection runs on its owner's credential. Microsoft's built-in Help Desk Operator can wipe, retire, remote lock and reset passcodes, while Read Only Operator's only remote task is getting a FileVault key ([learn.microsoft.com](https://learn.microsoft.com/en-us/intune/fundamentals/role-based-access-control/ref-built-in-roles), checked October 2026). Never connect as a Global Administrator.

### How quickly does a restriction change on an Intune role take effect?

Within about two minutes. Role and restriction changes in Elaichi resolve through a short cache, so a new allow rule or block binds every surface shortly after you save it. Some changes are faster: revoking an OAuth grant, removing or suspending a member, revoking a share and disconnecting an account all take effect on the caller's next request.

### Does ticking "Run your connected tools" let Claude write to Intune?

Yes. On Elaichi's consent screen, that checkbox covers a connected app's reads and writes alike, and only a tool whose method is a delete needs the separate delete permission. Leaving "Create and change data" unticked governs Elaichi's own operations, not Intune's create and update tools. Read-only access to a connected app is a restriction written in Elaichi, never a consent checkbox.

## Read next

- [Jamf in Claude on a read-only API role](/blog/it-team-claude-jamf-devices/) — Jamf in Claude lets a help desk check a Mac's inventory mid-ticket. Build a read-only Jamf API role, then narrow it per person with Elaichi restrictions.
- [QuickBooks read-only for a finance team in Claude](/blog/finance-team-claude-quickbooks-read-only/) — QuickBooks has no read-only OAuth scope, so QuickBooks read-only has to be enforced by whatever calls the API. Here is how to do it with one restriction.
- [Let IT post to one Slack channel from Claude](/blog/it-team-claude-slack-messaging/) — IT can post to one Slack channel from Claude when Elaichi freezes the channel argument. Channel reads stay open, and opening DMs is blocked for the role.