Layer Two: AI as Mediator
Stacked Zero Trust: Post 5 of 13
The second layer of Stacked Zero Trust is the one the market talks about most, and defines least clearly.
This is AI as mediator — intelligence sitting inside the trust algorithm itself, shaping decisions and responses rather than being something secured. It’s also the layer where “AI-powered security” gets applied to almost everything, which makes being precise about what it actually does matter more here than it does elsewhere.
The role, stripped back, is fairly specific.
At its simplest, the mediator is machine intelligence applied to the act of deciding trust. Where the classical substrate works through rules, signals, and human judgement, the mediator exists to do something those approaches struggle with — making sense of more signal, more quickly, and adjusting as that signal changes.
Everything that sits under the label either contributes to that job, or borrows the language without quite doing the work.
This post is about separating the two. What the mediator actually does in practice, and where that work is genuinely established versus where it’s still being described a bit ahead of reality.
What the mediator actually does
Once you move past the language, what the mediator is doing becomes reasonably familiar. What’s different is the scale and continuity.
The trust algorithm has always wanted to weigh context — whether something looks normal for a given subject at a given moment, across location, behaviour, and access patterns. Doing that continuously, across an entire estate, quickly moves beyond what can be handled manually.
That’s where most implementations start: building a picture of normal behaviour and measuring deviation from it in real time. In environments where behaviour is relatively stable — human users and workloads — it works well enough, and it’s one of the more mature parts of this layer.
From there, the problem shifts from individual signals to how they relate.
Modern environments generate a large volume of telemetry across identity, endpoint, network, and application layers. The useful patterns aren’t usually in any single stream; they emerge when multiple weak signals are considered together. You can’t do that by hand at scale, not reliably.
This is where the mediator earns its place — spotting combinations that aren’t visible in any single signal.
From observation and correlation, things start to nudge into decision-making.
In its more modest form, that shows up as suggestion: pointing out unused permissions, patterns that could be tightened without much impact. In its more ambitious form, it becomes systems adjusting policy on their own, based on what they’ve observed.
That’s where the conversation becomes less settled.
The final step is closing the loop between detection and action. Once something has been identified, the system can respond immediately — isolating a device, challenging a session, terminating access — without waiting for manual intervention.
That capability exists, and it works. The question is less whether it can be done, and more how much of it organisations are comfortable allowing.
None of this is new in concept. What’s changed is the continuity — doing these things across more signal, more often, and with less dependence on human intervention than before.
What is real today
Some of it works. Some of it doesn’t. The honest position is that it depends on which bit you’re looking at.
The parts that deal with behaviour and correlation are well established. In the stronger platforms, the ability to process and relate large volumes of signal, and to surface patterns that would otherwise go unnoticed, is demonstrably real. It has moved past the hype phase into something that earns its place operationally.
Not every product delivers it equally well. But as a capability, it exists and can be evaluated.
Where response is concerned, the mechanics are also sound. Systems can act quickly and effectively once a condition is met. The limiting factor tends to be trust rather than capability — organisations are understandably cautious about allowing fully autonomous actions where a false positive could cause the outage it was meant to prevent.
So the capability is there, but it tends to be used within boundaries. That’s a reflection of operational reality, not a shortcoming.
Policy is where things become less stable.
There’s clear value in systems that suggest improvements based on observed behaviour. That’s widely used and generally beneficial. The idea that systems are routinely generating and applying policy independently, at scale, without human involvement, is less well supported in practice.
Some of that exists in constrained forms. Much of it is still described in terms that are slightly ahead of what most environments are actually running.
Taken together, the layer is real, uneven, and moving quickly enough that it doesn’t stay still for long. Blanket judgements are less useful than understanding specific capabilities.
How to tell the work from the theatre
In practice, the gap tends to show up early in vendor conversations.
The product is described as AI-powered. The demonstration looks convincing. What you see — behavioural scoring, anomaly detection, useful correlation — is often genuinely valuable.
What it isn’t, in many cases, is mediation.
The system is doing analytics. It scores, it correlates, it surfaces patterns. An analyst then reviews that output and decides what happens next. That’s a strong capability, often a meaningful improvement over what was there before.
It isn’t sitting inside the trust algorithm, changing decisions or applying responses. It’s informing a human who does that work. The distinction is small in words and large in architecture.
That gap is rarely deliberate. More often it’s the result of language flattening — “AI-powered” used to describe both the mediator and the tool that informs a human mediator, without separating the two.
The simplest way to surface the difference is to ask what actually changes inside the trust decision when the product is deployed. That question tends to cut through most of the positioning quite quickly.
From there, it’s worth understanding what the system has learned. A system that’s genuinely modelling behaviour should be able to describe, at least in general terms, how it defines normal and how that picture evolves.
The question of where the human sits matters just as much. Knowing which decisions are automated, which are guided, and which remain manual is how you understand how the system really operates, rather than how it’s described.
And finally, it’s worth being explicit about failure. Every system will be wrong sometimes. What matters is whether that’s understood and managed, particularly when actions happen at machine speed.
None of these questions are complicated. They’re just direct.
Why this layer doesn’t stand alone
On its own, the mediator improves how the existing model operates. Applied to human users and workloads, it gives the trust algorithm more signal, broader context, and faster response. That’s already useful, and in some environments, significant.
It matters most in relation to the next layer.
When the subject no longer behaves in stable, predictable ways — when it varies, delegates, and operates in chains — static controls and periodic decisions stop being sufficient. That’s where the mediator becomes necessary rather than just beneficial.
This is the relationship described earlier in the series. The mediator isn’t just another layer of capability; it’s what allows the model to operate against subjects it wasn’t originally designed for.
On its own, it improves what already exists.
In combination, it enables something different.
One thing to take from this
AI as mediator is machine intelligence applied to the act of deciding trust.
Parts of that are well established — particularly around behavioural understanding and signal correlation. Some are deliberately constrained, especially where automated action is involved. Others, particularly around autonomous policy, are still emerging.
The useful skill isn’t deciding whether the category works.
It’s understanding what a system actually changes inside the trust decision, what it has learned, how it behaves when it’s wrong, and where responsibility still sits with a human.
That distinction becomes more important as the subject itself becomes less predictable. Which is where the next piece turns.
Post 5 of 13 in Stacked Zero Trust.
Previously: Post 4 - Layer One: The Substrate Still Matters.
Next: Post 6 - Layer Three: AI as Subject.
The reference document at the end of the series includes a buyer’s question set for assessing layer-two capabilities, expanded from the four questions above.
References drawn on in this post: NIST Special Publication 800-207, Zero Trust Architecture (August 2020), for the trust-algorithm and policy-decision-point model; user and entity behaviour analytics as the established antecedent of machine-speed behavioural scoring. Specific platform capabilities are described in general terms rather than attributed, and the layer’s vendor landscape is examined directly in Post 12.