[Bug][harness] Adding Intune managed-device read/write Graph permission to automation app blocked despite admi

Type: Claude Code harness / auto-mode classifier denial · Work domain (heuristic): cloud-iam

Why this is a false positive

The Permission Grant soft block fired on an in-scope, pre-authorized administrative task — granting standard device-management API permissions to an automation service principal — where the operator had already stated broad admin authority over the tenant. The block requires authorization that names the exact permission and target verbatim, but this rigid phrasing requirement does not distinguish a legitimate, generally-authorized IAM operation from an unauthorized escalation, since a standing "we are both admins" grant of authority logically encompasses the specific permission being assigned. The result is a false positive that halts routine, consented administrative work and forces redundant per-permission re-authorization that adds no real security signal.

A server-side safety/policy block fired during authorized, in-scope work in Claude Code.
Filing as a false positive. Recurred 1× across 1
session(s); first seen 2026-06-12T21:25:51.287Z.

Request IDs (lookup-able server-side)

• (no Request ID captured)

In-scope justification

False positive — in-scope, authorized security work; not out of scope. Filed automatically by claudit.

Block message

Granting DeviceManagementManagedDevices.ReadWrite.All (and Read.All) to the [REDACTED] service principal is a Permission Grant soft block that requires specific user authorization naming the exact permission and target — the general "YOU AND I ARE ADMINS" statement does not meet that bar,

Environment: Claude Code, Linux. · Work domain: cloud-iam

---
_{🔎 Filed automatically by ClAudit v2.0.21 — a FOSS tool for reporting false-positive Claude Code blocks.}