You verify every user. Do you verify every executable?

Most organisations running a zero trust programme can describe their identity controls in detail. Conditional access, multi factor, privileged access reviews, session policy. Ask the same organisation how they verify code, and the answer is usually antivirus.

That is not a criticism of the programme. It is where the maturity actually is, and it is worth looking at plainly.

The pillar nobody has finished #

Zero trust is usually assessed across six pillars: identity, endpoints, applications, data, network and infrastructure. In most assessments the shape is consistent.

The applications pillar tends to mean single sign on and conditional access in front of SaaS, which is identity work wearing a different hat. What it rarely means is deciding which code is allowed to execute on the endpoint.

So an organisation can hold a credible zero trust position on who its users are, and have no position at all on what its machines are permitted to run.

The same three principles, applied to code #

The useful thing about this gap is that closing it does not need a new framework. The three principles already in use translate directly.

Verify explicitly. Every executable, library, script and driver is checked against a policy before it is allowed to start. Checked, not scanned, and the distinction is the whole point: verification asks whether this code is approved, while scanning asks whether it looks bad. One of those requires having seen something before.

Least privilege. An endpoint runs only the software the organisation has approved for that endpoint, rather than everything a local administrator was able to install and nobody got round to removing. Least privilege applied to identity limits what an account can do. Applied to execution it limits what a machine can run.

Assume breach. When credentials are compromised and an attacker reaches the device, the payload they brought with them still does not execute, because it was never on the list. This is the principle application control serves best, and the one identity controls cannot serve at all: once an attacker holds valid credentials, identity has already made its decision.

Verification is not scanning, and the difference decides outcomes #

It is worth dwelling on the second word, because the two get treated as interchangeable.

Antivirus makes a prediction about a file, often one it has never seen. Modern engines are good at it and it still fails against novel malware, against signed tooling being abused, and against a legitimate binary doing something it was never intended to do. Microsoft is direct about the limit in its own documentation, which we quote in App Control vs antivirus vs XDR.

Application control does not predict. It compares the code against a decision somebody already made. Nothing has to be recognised, which is why it holds against things nobody has catalogued yet.

AI agents are now part of who executes code #

There is a newer reason this pillar matters, and it changes the shape of the problem rather than adding to it.

An agent given a tool has everything that tool can do. On Windows that routinely includes launching processes, loading modules and running scripts. Grant an agent the ability to run a command and you have granted it the ability to run commands, which is a broader permission than it looks.

So the set of things that can start code on an endpoint is no longer just your users and the software you deployed. Identity controls answer who the agent is acting for. They do not answer what it is allowed to execute.

An allowlist answers that, and it answers it the same way regardless of who or what asked. That property is worth more now than it was two years ago.

Where to start #

If your zero trust assessment says applications are planned rather than implemented, the first move is not a policy. It is finding out what your fleet actually runs, because you cannot decide what belongs until you know what is there, and an inventory assembled from what procurement bought is not the estate.

The platform sets out the sequence from there: plan the profiles, author a base policy and deploy it in audit, tune it into a circle of trust, then enforce ring by ring.

The point of doing it is not the maturity score. It is that the pillar you have not started is the one that decides whether an attacker who gets past the pillars you have finished can actually do anything.

Applying this principle to execution is the easy part to agree with and the hard part to run. PoliEze is the operating layer for it: what is running, who owns each trust decision, which exceptions are live and when they expire, and evidence that the control is working rather than merely deployed. The platform sets out the sequence.