Intune STIG baselines & shadow-AI control (June 2026)

Microsoft Intune shipped three things in June 2026 that matter to regulated mid-market IT, and it shipped them the way Microsoft usually ships things that matter: quietly, in the "What's new" changelog, without a keynote. None of the three got a launch event. All three change what a small IT team can actually do about compliance posture and shadow AI on a managed Windows fleet.

Here is the short version. Intune added a way to prove Windows 11 posture against Department of Defense STIGs — audit-only, GCC High, maps straight to compliance evidence. It added a first-class control to see and block shadow AI on managed endpoints, which is the governance problem nearly every shop already has and until now had no native lever for. And it made an agent that helps close vulnerabilities broadly available in preview, now running under its own machine identity. This is the Field Notes read on what each one is, where the boundaries are, and what a mid-market shop should actually do about it.

Be warned up front, because Microsoft's own docs make this easy to misread: one of these three is GCC High only and needs a specific add-on license. The other two work in the commercial cloud in preview — though even there the licensing is not uniform, because one shadow-AI piece (fleet-wide Device Query) is itself a paid Intune add-on. We will be plain about which is which, because a commercial-cloud reader who plans around the STIG baseline is planning around something they cannot use yet.

1. STIG audit baselines: proof, not enforcement (and GCC High only)

Announced the week of June 15, 2026, Intune's new STIG audit baseline assesses Windows devices against the DISA Security Technical Implementation Guides. The initial baseline is the Microsoft Windows 11 STIG SCAP Benchmark, Version 2, Release 7, with a benchmark date of January 5, 2026. For any shop that has ever assembled a STIG compliance package by hand, the appeal is obvious: a native engine that scores your Windows fleet against the benchmark and produces the evidence.

The audit-only distinction is not a footnote — it is the whole design. A traditional Intune security baseline (the MDM security baseline, the Defender for Endpoint baseline) is a configuration profile: deploy it and it sets values on the device. The STIG SCAP Benchmark baseline is the opposite. It reads the device, compares it to the benchmark, and tells you where you comply and where you fail. Remediation is a separate motion. You close the gaps with the Settings Catalog, the MDM security baseline, compliance policies, or Group Policy for hybrid-joined devices — and then you re-run the audit to show the delta.

That separation is exactly what a compliance program wants. Audit results map to NIST XCCDF categories, which is the structured format DISA compliance reporting expects, and the whole thing is reachable through the Graph API. So the evidence is not a screenshot in a binder; it is queryable data you can pull on a schedule, diff over time, and hand to an assessor. That is the difference between "we think we are compliant" and "here is the machine-read posture across the fleet, dated, mapped to the categories you audit against."

Now the honest boundary. Advanced Analytics licensing plus GCC High means this is a defense-industrial-base and government feature, full stop. If you are a commercial-cloud mid-market shop, you cannot turn this on today. That is not a knock on the feature; it is a scoping fact. GovCon shops chasing CMMC Level 2 should absolutely care — this is a real evidence engine that shortens the STIG package grind. Everyone else should file it under "know it exists, watch for a commercial release," and turn their attention to the next two features, which they can actually use.

2. Shadow AI on managed endpoints: the sequel to oversharing

A year ago the governance story was Copilot making SharePoint oversharing legible — we wrote about that in Copilot Governance, One Year On and about the permission rot underneath it in the 12,000-permission problem. Shadow AI on the endpoint is the sequel. The oversharing story was about what your sanctioned AI could reach. The shadow-AI story is about the AI you never sanctioned running on the laptop already.

Local AI coding agents, IDE extensions, and desktop assistants have quietly landed on managed Windows fleets. A developer installs a local coding agent that reads the repo, runs commands, and edits files. A knowledge worker installs a desktop assistant that watches the screen. None of it went through change control. Until June 2026, Intune gave you no native way to even see it, let alone stop it.

In Service release 2605, the week of June 8, 2026, Intune added exactly that, in public preview, in three parts:

• A Properties catalog policy that collects the Local AI Agent entity from enrolled Windows devices — the data-collection layer that makes local AI agents a thing Intune knows about at all.
• Device Query support to view the devices where a local AI agent is present — the "show me who has one" lens, on demand, across the fleet. One caveat that matters: Device Query is an Intune add-on — it needs Advanced Analytics, Intune Plan 2, or the Intune Suite. Without it you can still read the collected data per device under Device Inventory; you just don't get the fleet-wide KQL query.
• A "Local AI Agent Baseline" security baseline (preview) that blocks use of the agent — the lever, and it is base Intune, no add-on. Microsoft's baseline is literally named "Local AI Agent Baseline - OpenClaw" after the local AI coding agent its docs use as the worked example. Know how it works before you deploy it: it blocks by restricting common runtime paths — firewall rules on outbound Node.js traffic, plus Windows Subsystem for Linux — so Microsoft warns it "might block other processes in addition to OpenClaw." Test it on a ring first.

Read those together and you have a real control loop: collect the entity, query which devices have it, block it where policy says so. That is the difference between knowing you have a shadow-AI problem in the abstract and being able to name the machines and act.

Defender for Endpoint adds the discovery lens

Intune is not the only place this showed up. Microsoft Defender for Endpoint added Local AI agent discovery (preview, June 2026) that inventories local AI coding agents, IDE extensions, desktop assistants, and local AI runtimes across onboarded Windows and macOS devices. The discovery list is broad and specific: Microsoft names CLI agents (Claude Code, Codex CLI, Gemini CLI, GitHub Copilot CLI), agentic IDEs (Cursor and others), and a family of "Claw-based" agents that includes OpenClaw. That is the breadth lens — it tells you the full spread of what is installed across the estate. Intune is narrower and sharper: its properties catalog collects the Local AI Agent entity, and the block baseline is specifically the Local AI Agent Baseline - OpenClaw. So Defender shows you every agent on the fleet; Intune's baseline blocks the named one. Defender also ships a companion runtime-protection preview that inspects the agent's prompt-and-tool loop and can stop risky actions — like prompt injection — before they execute. Run discovery and policy together and you get visibility plus a lever from the same signal class rather than two disconnected tools.

A note on scope discipline, because "block all AI" is the wrong instinct. The goal is not to ban local AI agents outright — plenty of them are sanctioned, licensed, and productive. The goal is to make their presence visible and governed: know which devices have which agents, decide deliberately which are approved, and block the rest. That is the same move we made for SharePoint sprawl — targeted governance, not a blanket kill switch.

3. Vulnerability Remediation Agent: now in public preview, with its own identity

The third June 2026 item is the Vulnerability Remediation Agent — a Security Copilot agent in Intune — which under Service release 2605 opened to all customers in public preview. It helps close vulnerabilities across the fleet — useful on its own, but the detail worth flagging is the identity change. The agent now runs under a Microsoft Entra agentic identity rather than a human user identity. And there is a clock on it: if you already run this agent under a human user identity, Microsoft gives you 90 days from the release to transition it to an agentic identity, after which an un-migrated agent stops running until you switch it over.

That is the right direction and it is worth saying why. An autonomous agent acting on your endpoints should not borrow a person's credentials to do it. It should have its own identity, its own scoped permissions, and its own audit trail. When an assessor asks "who changed this," the answer for an autonomous action should be the agent's machine identity, not "well, it ran as Jane because that is whose token it grabbed." Running the remediation agent under an Entra agentic identity is the kind of plumbing decision that looks minor in a changelog and matters a lot the first time you have to reconstruct what happened during an audit or an incident.

Like the shadow-AI controls, this is a preview, and previews are previews: they move, they change shape, and they are not where you park a control you are betting a compliance deadline on. Pilot it, watch the identity model, and keep your human-driven remediation path warm until it graduates.

The three at a glance

What this means for regulated mid-market IT

Two different readers should take two different things from June 2026.

If you are a GovCon / GCC High shop

The STIG audit baseline is a genuine gift to the compliance grind. STIG evidence has historically been a manual, per-host, screenshot-and-spreadsheet exercise. A native engine that scores the fleet against V2R7, maps to XCCDF, and exposes results over Graph turns that grind into a data pull. It does not remediate — you still need the Settings Catalog, MDM baseline, compliance policies, and Group Policy to actually close findings — but it gives you the measurement layer that a Level 2 program needs. It slots naturally next to a GCC High tenant move before CMMC Phase 2 and a documented remediation workstream. Treat it as the evidence engine inside the program, not the program itself.

If you are a commercial-cloud shop

The STIG baseline is not for you yet — say it plainly and move on. Your June 2026 story is shadow AI. The Properties catalog collection and the Local AI Agent Baseline are base Intune and available in preview in the commercial cloud, and the exposure they address is already on your fleet. Start with discovery: turn on collection and find out how many machines are running local AI coding agents nobody approved. You will almost certainly be surprised. Then decide, deliberately, which agents are sanctioned and block the rest. The one caveat is the fleet-wide Device Query lens — it needs Advanced Analytics, Intune Plan 2, or the Intune Suite; if you don't have that add-on, you still see the collected data per device in Device Inventory, you just query one device at a time. This is the same targeted-governance posture we brought to Copilot oversharing, applied one layer down at the endpoint.

Everyone: the identity lesson

The Vulnerability Remediation Agent running under an Entra agentic identity is a small signal of a large trend. Autonomous agents are going to act on your environment, and the ones worth trusting will have their own scoped identities and their own trails. That is not a new problem — it is the machine-account and least-privilege discipline you already know, extended to agents. Shops that keep their identity foundation clean, in the spirit of the Tier 0 hardening work, will absorb agentic identities without drama. Shops that never got their service-account hygiene right will inherit that mess a second time, now with autonomous actors in the mix.

A directional project: the endpoint-governance assessment

The way we would frame this as a piece of work — vendor-neutral, labor-only, no license resale — is a short endpoint-governance assessment with two tracks that share a spine.

• Shadow-AI track (everyone). Turn on the Properties catalog collection and Defender discovery, inventory local AI agents across the managed Windows fleet, and produce a sanctioned-vs-unsanctioned list. Draft a Local AI Agent policy: which agents are approved, which get blocked by the baseline, and how new ones get reviewed. This is the broadly available, do-it-now half.
• STIG-posture track (GovCon / GCC High). Stand up the Windows 11 STIG SCAP Benchmark audit baseline, capture the baseline posture against V2R7, and map the failing categories to a remediation plan using Settings Catalog, the MDM baseline, compliance policies, and Group Policy for hybrid devices. Wire the Graph API pull into a repeatable evidence export. This is the GovCon-only half, and it dovetails with a CMMC Level 2 pre-assessment.

The shared spine is identity and endpoint hygiene: clean enrollment, clean baselines, clean agent identities. Both tracks are stronger when the foundation underneath them is sound, which is why we tend to sequence a Tier 0 pass ahead of or alongside this work rather than after.

What not to read into this

Three quick corrections to the over-enthusiastic reading.

The STIG baseline does not harden anything. It is a report card, not a teacher. If you deploy it and change nothing else, your devices are exactly as (in)secure as they were — you just have documentation of it now. The value is the evidence and the remediation roadmap it enables, not any change to the device.

Blocking one named agent is not a shadow-AI strategy. Microsoft's initial Local AI Agent Baseline uses a specific coding agent (the docs' "OpenClaw" example) to demonstrate the mechanism. The strategy is the loop — collect, query, decide, block — applied across whatever agents show up, not a one-time block of a single name.

Preview is not GA. The shadow-AI controls and the Vulnerability Remediation Agent are previews. Pilot them on a ring, watch how they behave, and do not retire your existing controls until the features graduate and prove out. Field Notes exists partly to keep the line between "shipped" and "shipped in preview" bright.

Related reading

• The oversharing prequel: Copilot Governance, One Year On: a Tenant-Sprawl Reckoning.
• Where the permission rot starts: Copilot Readiness: the 12,000-permission problem.
• Defense-contractor tenant move: GCC High before CMMC Phase 2.
• CMMC economics: The CMMC Level 2 pre-assessment, and why it costs $15K.
• The identity foundation underneath all of it: Active Directory Tier 0 in 90 days for mid-market.

Sources and further reading

• Microsoft Learn — What's new in Microsoft Intune
• Microsoft Learn — Use security baselines to configure Windows devices in Intune (overview, incl. STIG audit baselines)
• Microsoft Learn — Use the settings catalog to configure settings (remediation)
• Microsoft Learn — What's new in Microsoft Defender for Endpoint

Pro IT NW does senior-led Microsoft project work. Vendor-neutral. Labor-only. The endpoint-governance assessment is a fixed-scope engagement — shadow-AI discovery and policy for any managed Windows fleet, STIG posture and remediation mapping for GovCon and GCC High tenants.