The Three Layers of Stacked Zero Trust
Stacked Zero Trust: Post 3 of 13
The last two posts did the groundwork.
The first made the claim: Zero Trust didn’t fail; the subject model did. The second followed that through and showed why, by unpacking the assumptions the trust algorithm makes about the thing making the request — that the subject is stable, identifiable, and operates in discrete units — and how those assumptions stop holding once the subject is an agent.
This post builds on that.
It’s the structural point in the series — the one everything else refers back to — though the structure itself isn’t the interesting part. Once people see the layers, they tend to recognise them fairly quickly. What takes longer to land, and what matters more, is the relationship between two of those layers, and the fact that it isn’t a simple stacking. That’s where the architecture sits.
So it’s worth keeping the layers in mind, but not over-focusing on them in isolation.
The picture in one paragraph
At a high level, what I’m calling Stacked Zero Trust is the existing Zero Trust substrate with two AI-related layers sitting over it.
The substrate continues to do what it was always intended to do, governing the subjects it was designed around — human users and workloads — using identity, device, and policy as its primary controls.
Above that sits a layer where AI is applied inside the trust decision itself. Rather than being something secured, it is something doing the securing — handling correlation, scoring, and response at a scale and speed that are difficult to manage manually.
Above that again is a third layer, where AI emerges as a subject in its own right. Agents making requests, taking actions, and requiring governance in the same structural sense that users and workloads do, but without behaving like either.
If those layers were independent, this would be a fairly straightforward extension.
They aren’t.
The mediator observes and governs the subject, while the subject’s behaviour produces the signal the mediator depends on. The relationship between them runs both ways, and once you see that, it becomes clear that the architecture isn’t really about three layers at all — it’s about the loop that connects two of them.
Layer one: the Zero Trust substrate
The first layer is simply what Zero Trust already means in practice.
Identity, access control, device posture, segmentation, application and data policies, along with the policy engines and enforcement points that tie them together. All of the mechanisms used to decide whether access should be granted, and under what conditions, applied to subjects the model understands reasonably well.
There’s a tendency, particularly in discussions that introduce AI, to treat this as established ground and move past it. In most environments that isn’t really accurate.
Zero Trust maturity tends to be uneven. Some parts are well implemented, others less so, usually reflecting where effort has been concentrated rather than any overall design. That’s not unusual, but it does mean the substrate is often less complete than it appears in diagrams.
More importantly, whatever sits above it depends on it behaving properly. The additional layers don’t compensate for weaknesses here so much as expose them.
An agent operating inside an environment with loose identity controls or partial segmentation isn’t made safer by adding better monitoring. It becomes harder to reason about, because the subject itself is more complex while the controls around it are still inconsistent.
The substrate hasn’t changed its role. It’s still the foundation. What has changed is the kind of load being placed on it.
Layer two: AI as mediator
The second layer introduces AI into the trust algorithm itself.
Not as something that needs to be governed, but as part of the mechanism doing the governing.
In practical terms, that means continuous behavioural assessment, correlation across different classes of signal, and response that begins to close the gap between detection and action. These aren’t entirely new capabilities — parts of them have been present in various forms for some time — but the way they are being combined and extended is changing.
Some of what is described in this layer is already real and in active use. Behavioural analytics, anomaly detection, and automated response have moved beyond early experimentation in many environments.
Other aspects, particularly around policy generation and self-adjusting control, are less mature. They exist, but often in a more constrained or guided form than the language used to describe them would suggest.
So the layer isn’t hypothetical, but it isn’t uniform either.
What matters for the model is less the exact capability at any given moment and more the role it plays. This is the layer that is trying to reason about trust continuously, rather than at discrete points, and to do so at a scale that wouldn’t be practical without machine assistance.
Layer three: AI as subject
The third layer follows directly from the problems described in the previous post.
If agents are subjects — and structurally they are — then they need to be treated as part of the trust model, rather than something outside it.
That sounds straightforward, but it changes the nature of the questions that need to be asked.
Identity, for an agent, isn’t just a matter of issuing a credential. It has to mean something that can be tied to behaviour and authority in a way that holds over time.
Posture is no longer about the state of a device, but about the behaviour of a system that isn’t deterministic.
Least privilege becomes harder to define when the full set of actions isn’t known in advance.
And invocation patterns — agents calling other agents, accessing tools, working across systems — don’t map cleanly onto the request models the substrate was built to evaluate.
None of this is theoretical. It emerges as soon as agents move from controlled demonstrations into real environments.
There aren’t settled answers yet, and pretending otherwise isn’t helpful. What the architecture requires, at this stage, is that the problem is framed correctly — that the agent is understood as a subject, and that the model is expected to account for behaviour it wasn’t originally shaped around.
The part that matters: the loop
If you stop at the layers themselves, the picture looks reasonably tidy.
The complication comes from how the second and third layers interact.
The mediator exists, in part, because the subject is difficult to reason about using static controls. Agents behave in ways that shift over time and operate across chains of activity, which means that understanding what is happening requires continuous observation and adaptation.
At the same time, the mediator depends on the subject. The only way it can become effective is by observing what agents actually do — how they behave, how that behaviour varies, and where the boundaries sit in practice rather than in design.
So the relationship runs in both directions.
The mediator governs the subject, but it also learns from it, and that learning shapes how it governs in future.
Once that loop is visible, the architecture stops looking like a hierarchy of capabilities and starts to look more like a system with feedback at its centre.
That, in turn, brings its own set of questions. If governance is adaptive, then it needs to be understood as something that evolves, not something fixed. And if it evolves based on the behaviour it observes, then the integrity of that behaviour matters in a different way.
Those questions don’t sit cleanly in any one layer. They exist because of the relationship between them.
How to use the model
The layers aren’t intended as a product breakdown. They’re a way of locating questions more precisely.
Questions about identity maturity, device posture, or segmentation sit in the substrate.
Questions about detection, correlation, and response at scale sit in the mediator layer.
Questions about agents — how they are identified, how they behave, how they are governed — sit in the subject layer.
And questions about how adaptive control interacts with adaptive behaviour sit in the loop.
A lot of the confusion in current discussions comes from moving between those without noticing. Treating a problem in one layer as if it can be solved entirely in another, or assuming that strength in one area compensates for weakness in another.
The model doesn’t answer those questions directly.
It makes it clearer which questions you’re actually asking.
One thing to take from this
The structure here is straightforward enough: a substrate, a mediating layer, and a new class of subject.
What makes it an architecture rather than a diagram is the fact that the mediator and the subject are not independent.
The system that governs is learning from the behaviour it governs, and adjusting accordingly.
Once you see that, it becomes clearer why this is not just an incremental change to Zero Trust, but a shift in how the trust model has to operate.
Post 3 of 13 in Stacked Zero Trust.
Previously: Post 2 - What Is a Subject, Actually?
Next: Post 4 - Layer One: The Substrate Still Matters - why the classical Zero Trust foundation is both more unfinished and more important than the AI conversation wants to admit.
The full architecture - including detailed layer diagrams and the complete subject taxonomy - will be published in the reference document at the end of the series.
References drawn on in this post: NIST Special Publication 800-207, Zero Trust Architecture (August 2020); the CISA Zero Trust Maturity Model, the DoD Zero Trust Reference Architecture, and the Forrester ZTX framework as the converged body of classical Zero Trust thinking; industry Zero Trust maturity survey data referenced in general terms (specific sources to be cited in the reference document).