Agent based application control, or the engine already in Windows

There are two ways to do application control on Windows, and the choice is usually made on a feature comparison when the differences that matter are architectural.

One approach ships an agent that is itself the allowlisting engine. It runs on the endpoint, watches execution, and makes the decision. The other governs the engine Microsoft already put in the kernel, and the management platform never touches the execution path.

Both work. They fail differently, and they cost differently, and four of those differences are worth understanding before a procurement process makes the decision for you.

Whether an attacker can switch it off #

This is the one that has changed most in the last two years.

Ransomware operations now routinely disable endpoint security before running a payload. The technique has a name, EDR killers, and of roughly ninety documented in the wild, fifty four bring a vulnerable signed driver to reach kernel privilege and terminate protected processes. We wrote that up in EDR killers and what they tell you about where enforcement belongs.

An enforcement agent is a process. It has a process identifier, and from the kernel a process can be stopped. Vendors respond with self protection, tamper protection and watchdog services, and those raise the bar without changing the shape of the problem.

Code Integrity is not a process. It is part of the kernel, so there is no executable to terminate, no service to disable, and nothing to prevent starting because it does not start. An attacker who reaches kernel privilege has not reached a place where the decision can be switched off, because the decision is made by the kernel they are trying to subvert.

Be precise about the limit, though. The enforcement is not the soft target; the policy can be. An unsigned policy on disk can be removed by something holding administrative rights, and the machine comes back without it. That is exactly what signed policies and UEFI lock are for, and signed and unsigned App Control policies covers the trade off, including the part where a UEFI locked policy is genuinely difficult to remove, including for you.

What you are licensing #

With an agent based product you are paying, per endpoint, for the enforcement engine. That is the thing the licence buys and the thing that stops working when the licence ends.

With native App Control the engine is already in the operating system you have paid for. What a platform charges for is the management: authoring, review, evidence, staged deployment, reversal, and the operational work of keeping a policy honest across a fleet. That is a smaller claim and it is worth being clear about it, because it also means the platform has to justify itself on the management rather than on the blocking.

What leaving costs you #

Follow the licensing question one step further, because this is where the two architectures genuinely diverge.

If the agent is the engine, then removing the product removes the control. Policies were expressed in the vendor's format, enforced by the vendor's code, and neither survives the uninstall. Migration means rebuilding the policy estate somewhere else, which in practice means most organisations do not migrate.

If the engine is Windows, policies are standard App Control XML deployed through Intune or Configuration Manager. Stop paying and enforcement continues, because it was never the thing being paid for. That is not loyalty, it is architecture, and it is worth asking any vendor in this category to state plainly what happens to your policies on the day you leave.

What it costs the endpoint #

An enforcement agent participates in execution decisions, so its processing, memory and decision latency are part of the performance profile of every application launch. Well engineered agents make this small. It is not nothing.

Code Integrity makes the decision in the native enforcement path, where the check was going to happen anyway. There is no third party code between a user starting an application and the application starting, which also means no additional attack surface on the endpoint from the control itself.

Where the agent based products are better #

A comparison that only runs one way is not worth reading, and there are two places where the agent based approach wins outright.

Parent process gating. Agent based products can express a rule like allowing a script only when a specific application launched it. App Control cannot: it evaluates the code, not what invoked it. If that specific control is what your environment needs, that is a real reason to choose differently.

Anything that is not Windows. App Control is a Windows feature. Most agent based products cover macOS and Linux as well, and a mixed estate that needs one console for all of it is a legitimate requirement.

The questions worth asking #

Whichever way you go, these four separate the architectures faster than a feature matrix:

1. If an attacker gains administrative rights and then kernel privilege, what stops the enforcement being disabled?
2. What exactly does the per endpoint licence buy, the enforcement or the management?
3. On the day we stop paying, what happens to the policies we have built?
4. Where in the execution path does the decision get made, and what does that cost per launch?

Ask them of us as well. Bring us your hardest application and the same questions apply.

The distinction only matters if the native engine can actually be operated. That is the gap PoliEze fills: it gives you the discovery, the approval trail, the staged rollout and the evidence around the enforcement decision Windows already makes, so choosing the native engine does not mean choosing a harder programme. The platform sets out what that covers.