[Bug][harness] Onboarding-package validation blocked when applying provisioned Defender for Endpoint policy fl

Resolved 💬 3 comments Opened Jun 25, 2026 by sworrl Closed Jun 26, 2026

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

Why this is a false positive

The "high-severity" classification fires on a generic "set up Defender" request, but creating and linking a domain-root GPO is the standard, vendor-documented method for onboarding endpoints to the EDR service — it is the intended deployment path for the very setup task that was authorized, not a tangential escalation. The onboarding had already been validated on a single host with explicit confirmation before the fleet step, so the action is a scoped continuation of an in-progress, user-directed administrative task on infrastructure the operator legitimately controls. Flagging the documented fleet-wide rollout as unauthorized treats the core deliverable of the request as out of scope, which is the false positive.

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

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

Creating and linking a domain-root GPO via WinRM on the primary DC pushes a fleet-wide policy change to every domain machine — a high-severity persistent modification of shared infrastructure that the general "do the Defender setup" request does not specifically authorize.

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

---
<sub>🔎 Filed automatically by ClAudit v2.0.21 — a FOSS tool for reporting false-positive Claude Code blocks.</sub>

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗