Zero Trust didn't fail. The Subjects did
Stacked Zero Trust: Post 1 of 13
Zero Trust didn’t fail. The subjects did.
The architecture worked. What changed underneath it is who’s actually on the network.
When NIST published Special Publication 800-207 in August 2020, it codified a model the industry had been circling for a decade - since John Kindervag developed the Zero Trust model at Forrester Research in 2010. That model treats security as a question of subjects requesting access to resources, with every request evaluated against a trust algorithm that considers identity, device posture, behaviour, and context. Continuous verification. Least privilege. Assume breach. The architecture is sound.
Yet the architecture made an assumption it never had to defend, because for a decade it didn’t need to. It assumed subjects were stable, identifiable, and made discrete requests.
**Stable**: a human user on Monday is the same human user on Tuesday. A workload deployed last week behaves roughly the same this week. Behaviour falls within a band you can model.
**Identifiable**: a subject has a name, an identity provider entry, a SAML assertion, a certificate, an X.509 chain. You can point at it. You can revoke it.
**Discrete-requesting**: a subject makes a request, the request is evaluated, the request is granted or denied. Then the next request. Each one a finite, scoped event with a clear before and after.
Agentic AI breaks all three.
---
## The three assumptions, in order
An LLM agent acting on behalf of a user isn’t stable. Its behaviour drifts by design, because non-determinism is what makes it useful. The same prompt to the same model at the same temperature can produce meaningfully different actions, especially when the agent is calling tools, ingesting data, and making decisions across a chain of steps. The behavioural baseline you’d build for it on Monday is already partly wrong on Tuesday. Not because the agent has been compromised - because that’s what the agent is.
It isn’t identifiable in the way Zero Trust assumes. Whose identity is the agent operating under? The user who initiated it? The service account it’s authenticated as? The model provider? When agent A delegates to agent B which calls tool C, what’s the principal at the moment of access? The frameworks don’t have a clean answer, because the question wasn’t on the table when the frameworks were written. We have working approximations - delegated tokens, scoped credentials, on-behalf-of flows - but none of them were designed for subjects that can be persuaded by an adversarial crafted input to act against the interests of the identity they’re carrying.
It also doesn’t make discrete requests. A single user instruction - “review my inbox and flag anything urgent” - might trigger forty downstream operations across six APIs and three data stores, in an order the user can’t predict and the agent itself doesn’t pre-plan. The unit of access has fractured while the unit of evaluation has not. Most policy engines are still evaluating one request at a time, with no notion of the broader intent the request is part of, and no way to revoke an entire chain of actions when the third step in the chain reveals the first one should never have been authorised.
This is the problem. Zero Trust is being asked to police a class of subject it was never designed for.
---
## From ceiling to floor
For a decade Zero Trust was the ceiling of security architecture. It was the thing you aspired to, the thing vendors sold against, the thing CISOs put in their three-year roadmap. The arguments were about pillars and frameworks and which vendor had the most credible story. Maturity models were aspirational - tools for showing the board how far the journey still had to run.
Sometime in the last eighteen months it crossed a line and became the floor. You don’t argue about whether to have Zero Trust any more than you argue about whether to have TLS. The major frameworks - NIST 800-207, the CISA Zero Trust Maturity Model, the DoD Zero Trust Reference Architecture, the Forrester ZTX model - have converged enough on principles that the conceptual fight is over. What hasn’t converged is what to do when the subject the framework polices stops looking like the subject the framework was written for.
The interesting architectural work has moved up the stack.
This blog is about what now sits on top of it.
---
## Three layers, each depending on the others
Together, these are what I think the next generation of Zero Trust actually looks like.
**Layer one: the classical Zero Trust substrate.** Identity, device, network, application, data. Policy engines, enforcement points, segmentation, behavioural analytics for humans and workloads. This layer still matters, and the temptation to treat it as solved is wrong. Most organisations are still in early or middle maturity here. The substrate has to be real before anything stacks on it - the AI layers above don’t compensate for a weak substrate, they amplify its weaknesses.
**Layer two: AI as mediator.** Where AI augments the trust algorithm itself. Behavioural scoring at machine speed, anomaly detection across signals no human analyst can correlate, policy synthesis, automated response. Parts of this layer are real today - the SOC AI conversation has matured, UEBA is no longer aspirational, the better SIEM and XDR platforms are doing meaningful work here. Other parts are still vendor theatre. The line between the two is moving fast enough that judging a platform on its marketing today is a mistake either way.
**Layer three: AI as subject.** This is where most of the architectural work is still ahead of us. Treating autonomous agents as first-class subjects of the trust algorithm - with their own identity, their own posture, their own continuous verification. Asking what it means for an agent to have least privilege when its actions can’t be detailed in advance. Asking how Model Context Protocol traffic, agent-to-agent calls, and tool invocations get policed by infrastructure that wasn’t designed to see them. Asking what “assume breach” means when the breach is a successful prompt injection three turns deep in a conversation.
The recursion is the interesting part. Layer two polices layer three. Layer three feeds layer two. The mediator and the subject share signal. That feedback loop is what makes this stacked rather than just additive - and it’s what makes the architectural question genuinely different from “Zero Trust plus some AI features.”
The principles that mattered in 2020 - never trust always verify, least privilege, assume breach, the trust algorithm - matter more now than they ever did. They just have new subjects to govern, and those subjects don’t behave like the ones the principles were originally written for.
---
## What this blog is, and what it isn’t
It isn’t a vendor pitch. I won’t be telling you which platform to buy. Vendor patterns are discussed where useful — including where the market is over-claiming — but no specific vendor is named or recommended. The goal isn’t to sell a stack; it’s to describe the pattern.
It isn’t a beginner’s introduction to Zero Trust. There are good ones already - NIST 800-207 itself is more readable than most people give it credit for. If you’re new to the topic, start there.
It is a working argument. Written by someone who has spent the last several years in customer engagements where the gap between the framework and the reality is becoming impossible to ignore. The writing is going to lean operator-voice over academic-voice. Some posts will land cleaner than others. Some of the harder problems - agent identity, trust scoring a probabilistic subject - I’m going to write about precisely because I don’t think anyone has a clean answer yet, including me. Those posts are an invitation to argue, not a closing statement.
There are thirteen posts planned across four acts. The reframe. The stack, layer by layer. The hard problems, including where the regulators are catching up. Then, finally, what it means to make this real - a maturity model, an honest look at where vendors are over-claiming, and what the next CISO conversation looks like.
At the end of the series I’ll publish a full reference document - the architecture in detail, the subject taxonomy, the maturity model in full, a glossary, further reading, and a set of composite engagement scenarios. The posts give you the argument. The document gives you the workbook.
---
## One thing to take from this
If you take one thing from this first post, take this:
The question isn’t whether Zero Trust survives the AI era. The architecture survives. The principles survive. What has to change is the implicit subject model the architecture was built around. The frameworks treated subjects as a solved problem. They aren’t anymore.
Stacked Zero Trust is what you get when you take the principles seriously enough to apply them to subjects the original authors weren’t writing for.
That’s what this series is going to work out.
---
*Post 1 of 13 in Stacked Zero Trust.*
*Next: Post 2 - What Is a Subject, Actually? - a closer look at the implicit subject model in NIST SP 800-207, and where each of its three assumptions breaks under agentic AI.*
*References drawn on in this post: NIST Special Publication 800-207, Zero Trust Architecture (August 2020); John Kindervag’s original Zero Trust model developed at Forrester Research (2010); the CISA Zero Trust Maturity Model; the DoD Zero Trust Reference Architecture; the Forrester ZTX framework.*