Windows for defenders: services, the registry, Group Policy, AppLocker, WDAC

How privileged software runs on Windows: services

Start with the question Chapter 14 left implicit. A security agent has to run with privilege to be useful, but how does it come to be running at all, before anyone has logged in, and how does it keep running regardless of who is at the keyboard?

The answer on Windows is the service. A service is a program that runs in the background, started and managed by the operating system itself rather than launched by a user opening it. Services start as the machine boots, often before any human has signed in, and they keep running across logins and logouts. Most of them run not as the logged-in person but as a dedicated high-privilege system account, the most powerful of which is LocalSystem. A service running as LocalSystem has the run of the machine.

This is the shape every endpoint agent takes. The Microsoft Defender sensor is a service. The Intune management component is a service. A third-party data loss prevention agent is a service. When the device-state report and Chapter 14 talk about 'onboarding a device', the concrete meaning on Windows is this: a privileged service belonging to the security tooling has been installed and is running as a system account. That is what places the organisation on the privileged side of the boundary. Everything the agent can later do, reading the clipboard, watching syscalls, blocking a network connection, follows from its being a service running with system privilege.

The personal laptop on the desk has none of these services. Nobody installed them, because installing a system-level service is something you do to a machine you administer, and the staff member administers their own. The entire bring-your-own-device blind spot, restated in Windows terms, is the absence of these services. There is no agent because no agent was ever placed there.

The registry: the machine's settings, and who is allowed to change them

A service is software the organisation runs. The next mechanism is about settings the organisation imposes, and on Windows almost every setting of consequence lives in the registry.

The registry is a single hierarchical database of key/value pairs that the operating system and applications read their configuration from. It is divided into top-level sections called hives, and for a defender the division that matters is between two of them. HKEY_LOCAL_MACHINE, universally abbreviated HKLM, holds machine-wide settings and can be written only by an administrator. HKEY_CURRENT_USER, HKCU, holds settings for the person currently signed in, and that person can write to it freely.

That asymmetry is the whole point. A setting placed in HKLM is one an ordinary user cannot change. A setting in HKCU is one the user owns. So when an organisation wants to enforce something a user must not be able to undo, it writes a value into HKLM, where the user lacks the privilege to touch it. This is why so many enforced controls reduce, underneath, to 'set a particular value under HKLM'. The browser controls that matter most for shadow AI are exactly this kind of setting: forcing the user into the Edge for Business work profile, constraining or blocking other browsers, controlling which extensions are installed and which cannot be removed. These are registry values written under HKLM, and on a managed device the user cannot reach them.

Recall Chapter 14's hard limit: on a personal machine the user is the administrator. That sentence now has teeth. An administrator can write anywhere in the registry, HKLM included. Every machine-wide control an organisation might wish for is, on a personal device, a value the device's owner can simply set back. The control is not weak on the personal laptop; it is absent, and even if it were somehow present the owner could remove it.

Group Policy and Intune: settings at scale

An organisation does not have hundreds of staff, walk to each laptop, and edit the registry by hand. It defines policy once, centrally, and the machines apply it. The two mechanisms for this are worth naming because a defender will hear both constantly.

Group Policy is the older mechanism, tied to on-premises Active Directory. An administrator defines policy objects on a domain controller, and domain-joined machines pull and apply them, mostly by writing the corresponding values into the registry. The acronym GPO, for Group Policy Object, is the unit of that configuration. Intune is the cloud-era equivalent, introduced in Part Two's Conditional Access material and threaded through the device-state report. For devices joined to Microsoft Entra and enrolled in Intune, policy is defined in the cloud and the device pulls and applies it through its management agent.

The detail of Active Directory versus Intune is Chapter 20's subject, and the full taxonomy of join and enrolment states belongs there. The conceptual content here is narrower and more important: central enforcement works only because the device has joined a management authority and agreed to obey it. A laptop applies the organisation's Group Policy because it is domain-joined. It applies Intune policy because it is Entra-joined and enrolled. Joining is itself the act of placing the organisation on the privileged side of the device, the same act in a different costume. The retail laptop on the desk has joined nothing, so there is no authority whose policy it would pull, and the central machinery has no purchase on it at all.

Application control: AppLocker and App Control for Business

The last mechanism decides not what runs in the background or what settings hold, but which programs the machine will agree to launch in the first place. Chapter 14 framed launching a program as the operating system being asked, through the system-call interface, to start a new process. Application control is the privileged gatekeeper that can answer no.

Windows has two such gatekeepers, and the difference between them is the kind of thing a defender is expected to know. AppLocker is the older one. It works from rules an administrator writes: allow programs from this publisher, in this path, with this file hash, and block the rest. It is enforced by a service, and it is bypassable in ways that are publicly documented. AppLocker still receives security fixes but no new features, and Microsoft now steers organisations toward the newer technology where they can use it. (high) It remains the better fit in some cases, notably mixed estates that still include older Windows versions, or shared machines that need different policies for different users. (high)

The newer technology is App Control for Business, which is the current name for what was for years called Windows Defender Application Control, or WDAC, and before that was part of a feature called Device Guard. The branding has changed more than once, and Microsoft's own documentation still uses both 'App Control for Business' and 'WDAC', so a defender reading around the topic should treat the two as the same thing. (high) The substance is that App Control policies are a stronger form of allowlisting: they can be enforced close to the kernel and anchored to a hardware root of trust, which makes them far harder to step around than AppLocker rules. If AppLocker is a fence a determined person can sometimes climb, App Control in enforced mode is closer to a wall.

Both are controls of the standard operating environment and nowhere else. (high; device-state report section 12) They are configured centrally and applied to managed, joined machines. Their relevance to a manual about shadow AI is direct, and it is the bridge to the next section: these are the mechanisms that decide whether a desktop AI client, or a model run locally on the machine, is allowed to execute at all.

Reading shadow AI controls down the Windows stack

With the four mechanisms in hand, the Windows shadow AI controls stop being a list of product features and become a walk down from the network into the operating system, reusing the three places from Chapter 14.

The outermost control blocks the consumer AI site from the device itself. Microsoft Defender for Endpoint's network protection and custom indicators run as part of the privileged Defender service and can refuse a connection to chat.openai.com whether the laptop is on the corporate network or at home. (high; device-state report section 1) This is the strongest-sounding control, and a manual owes the reader its real texture rather than the brochure version. Full URL-path blocking works only in Microsoft's own browsers, Edge and Internet Explorer; for a third-party browser the agent can block the fully qualified domain name but not specific paths within it. (high) There can be up to two hours of latency between setting a block and the endpoint enforcing it. (medium) And Chrome's use of the QUIC protocol can intermittently slip past the block unless QUIC is disabled, a point that rests on independent testing rather than Microsoft documentation. (medium) So 'we block AI sites at the endpoint' is true, and also leakier than it sounds, and the leaks are predictable from the protocols Part One described.

The next control forces the user onto the inspectable path. The browser-resident controls from Chapter 14, Edge for Business inline DLP and the Purview extension, only bite when the user is actually inside the Edge work profile or a managed browser. The Windows machinery that herds them there is exactly the registry-backed browser policy of the earlier sections: force the work profile, constrain or block other browsers, force-install the extension and forbid its removal. On the standard operating environment these are values under HKLM, written by Group Policy or Intune, that the user cannot reach. The reader who absorbed the foundations now sees this for what it is, a policy value in a protected hive, rather than a proprietary Microsoft trick.

The innermost control stops the local AI client, and this is where application control earns its place in a shadow AI manual. A desktop ChatGPT application, or a tool like Ollama or LM Studio that runs a model on the machine itself, is in Chapter 14's terms just another userland process asking the operating system to launch it. App Control for Business in enforced mode can refuse that launch, and the refusal is a genuine block; AppLocker can refuse it less reliably; on the personal laptop neither exists. (high; device-state report section 12)

The locally run model deserves its own sentence because it inverts everything else in the manual so far. When the model runs on the machine, the prompt never leaves it. There is no network connection for network protection to block, no browser session for inline DLP to inspect, no cloud service for the identity layer to police. Every control discussed up to this point is irrelevant by construction, and application control is the only lever left. Application control is a standard-operating-environment control, which means the one lever that works against a local model is absent on exactly the unmanaged personal device where a privacy-minded or determined staff member is most likely to run one. That is not a gap a vendor can close with a feature; it is a consequence of where the boundary falls.

Step back and the Windows picture reduces to something a defender can hold in one sentence. Every shadow AI control on Windows is one of three privileged acts performed on a managed device: run a privileged service, which is the agent; write a machine-wide registry value the user cannot change, which is the browser and DLP policy; or interpose application control at the moment a program tries to launch. All three depend on the device having joined a management authority. That dependency is the Windows-specific restatement of Chapter 14's thesis. The controls live on the privileged side of the boundary, and on a personal device nobody put them there.

Last updated 9 August 2026