メインコンテンツへスキップ

126: Compliance Policies (Client-Driven Evaluation & AI Agent Checks)

Implementation Effort: Medium – Requires defining platform compliance baselines, conditional access integration, and remediation notifications.

User Impact: Medium – Noncompliant devices are restricted from accessing organizational resources via Microsoft Entra Conditional Access until remediated.

Overview​

Windows Compliance Policies in Microsoft Intune define the security posture rules and conditions that managed devices must meet before Microsoft Entra Conditional Access grants access to organizational resources.

Recent 2026 enhancements significantly strengthen Zero Trust posture evaluation:

  • Client-Driven Compliance Evaluation for Windows (September 2026): Supported Windows devices now proactively detect local changes to critical security signals—including Firewall, Antivirus, BitLocker, Microsoft Defender status, OS build, Real-time protection, and Secure Boot—and immediately request compliance re-evaluation rather than waiting for a scheduled 8-hour check-in. This drastically reduces the window of exposure when a security control is disabled or remediated.
  • Mark Devices Noncompliant When Prohibited AI Agents Are Discovered: Admins can configure a list of prohibited local AI agents (such as OpenClaw) in a Windows compliance policy. When an unsanctioned local agent is detected on the endpoint, the device is automatically marked noncompliant and blocked by Conditional Access until the agent is removed.
  • Device-Reported Values Guidance: Compliance reports include device-reported setting values for rapid triage while maintaining server-side verification for access decisions.

This directly supports Verify explicitly by continuously validating real-time endpoint security posture and Assume breach by immediately revoking access via Conditional Access when local security controls or prohibited AI agent rules are violated.

Implementation Guidance​

  1. Start with a small, high-value compliance baseline. Typical examples include encryption, minimum OS version, password or PIN requirements where applicable, threat or risk signal, and whether the device is marked compliant.
  2. Keep configuration and compliance separate. Use configuration profiles, endpoint security, and baselines to set the desired state; use compliance to evaluate whether the state is acceptable for access.
  3. Use separate policies where necessary by platform or risk profile, but avoid creating many nearly identical policies unless there is a clear governance reason.
  4. Plan user remediation clearly. Noncompliance should produce understandable user messaging, realistic grace periods, and help-desk runbooks so access blocks are supportable.
  5. Integrate the compliance result with Conditional Access rather than duplicating device-evaluation logic across multiple policies. This simplifies audit and troubleshooting.
  6. Review noncompliance data regularly. A compliance policy is only effective if administrators can tell which settings fail most often and whether the failures represent real risk.

Reference​