A series like this eventually earns the right to ask a different kind of question.
Not which vendor to buy. Not whether a business unit sits at Level 3 or Level 4. Not whether a particular deployment passed an architectural review. Those are all important questions, but they sit downstream of something more fundamental: what does the senior security conversation actually look like once the architecture has settled into the room?
The reason that question matters is that architecture only becomes useful when it changes decisions. A framework that remains inside the security team may be intellectually satisfying, but it has not yet altered the organisation’s trajectory. The real test comes when the architecture is translated into decisions the board, executive committee and business leadership can act upon. The challenge is no longer technical. It is communicative. The job becomes turning architectural reality into organisational commitment.
The previous twelve posts have all been heading in that direction. They started with the assumptions embedded in the traditional subject model, moved through mediator and subject layers, explored governance, maturity and regulation, and ultimately arrived at a simple conclusion: the technical problem is only part of the challenge. The harder task is helping the organisation understand what those technical realities mean and what, if anything, it intends to do about them.
Three observations are worth saying clearly in any boardroom in 2026. None of them are especially novel. All of them are becoming increasingly difficult to avoid.
What to say to the board
The first observation is that Zero Trust is no longer optional, and most organisations are not as far along as their strategy decks imply.
The phrase itself has appeared on presentations for years, but the work beneath it is substantially less complete. Across most large enterprises, the substrate remains uneven. Identity consolidation is unfinished. Segmentation is inconsistent. Third-party access remains difficult to describe confidently. Post-acquisition integration continues to leave seams that are known, tolerated and rarely prioritised. That situation is not unusual, nor is it evidence of failure. The substrate is genuinely difficult, and the underlying business has usually changed shape faster than the security function could stabilise it.
What has changed is the consequence of leaving those gaps unresolved. When the estate consisted primarily of humans and workloads, many of those weaknesses were survivable. Once autonomous subjects begin operating on top of the same infrastructure, the significance of those weaknesses changes. The board conversation therefore needs to move beyond programme reporting and towards consequence. The useful question is no longer whether the Zero Trust programme is progressing. It is where the substrate remains unfinished and what happens if AI adoption scales before those unfinished parts are addressed.
The second observation is that AI deployment is happening regardless, and the security function is usually being informed rather than consulted.
This is perhaps the most consistent pattern I encounter. The business case for AI is compelling. The productivity gains are real. The competitive pressure is real. As a result, deployments frequently move at a pace that does not align comfortably with traditional security governance. Security teams often discover initiatives already underway rather than initiatives still being shaped.
The organisations that struggle most are often the ones attempting to slow those deployments down. The organisations that adapt most successfully tend to accept that deployment is going to happen and reorganise themselves accordingly. That distinction matters because a security team brought in after a decision has already been made can document risk, challenge assumptions and request controls. A security team involved while the decision is still forming can influence the shape of the architecture itself.
The board conversation should therefore be less about whether AI should be deployed and more about whether security participates early enough to influence how it is deployed. That is not primarily a staffing problem. It is an operating-model problem. Solving it requires executive sponsorship, changes in decision-making structures and agreement about who participates in technology choices before those choices become commitments.
The third observation is that the layer-three problem is real, largely unsolved, and often concentrated in the strongest parts of the organisation.
The instinctive assumption is that the greatest risk sits in the oldest and least modern areas of the estate. In practice, the largest layer-three exposures often appear in the most technically mature environments. Cloud-native teams, digital businesses, engineering organisations and recently acquired technology firms are usually where autonomous agents appear first because those are the parts of the organisation creating new capabilities and moving at the highest velocity.
That was the finding in the Barnard Financial Group example, and it mirrors a pattern I have seen repeatedly. The strongest substrate frequently coexists with the largest subject-layer exposure because the strongest substrate is where innovation is occurring. Boards often respond to this observation by asking what product category will solve the problem. The honest response is that the market has not yet produced a mature and settled one. Organisations can improve visibility. They can strengthen substrates. They can develop mediator capabilities. They can constrain deployments and make exposure visible. What they cannot currently do is purchase certainty.
In some ways, recognising that limitation is the beginning of dealing with it responsibly.
Taken together, these three points are probably the architecture’s most useful contribution to the leadership conversation. The board does not need to understand every layer, every maturity level or every technical detail. It does need to ask different questions than the ones it would have asked five years ago.
What a CISO actually does next
Once the conversation reaches that point, the practical actions become reasonably clear.
The first is to establish an honest maturity baseline. Not the strategy-deck version. Not the executive-summary version. The real one. The maturity model introduced in the previous post only becomes valuable when it is applied honestly across each layer and across each major business unit. The resulting picture is rarely comfortable because it reveals unevenness that averages and simplifications tend to hide. That discomfort is precisely why the exercise matters. If the assessment does not make somebody uncomfortable, it probably is not yet honest enough.
The second action is to move AI discussions away from the question of whether something is secure and towards the question of where it sits within the maturity model. The first question tends to invite theatre because it has no meaningful endpoint. The second forces specificity. An AI deployment proposed inside a business unit operating with a Level 1 substrate is fundamentally different from the same deployment proposed within a business unit operating at Level 4. The technology may be identical. The exposure is not. Framing decisions in that way changes the conversation from opinion to condition.
The third action is to begin building mediator capability before the organisation believes it needs it. Layer three cannot become governable without layer two. The mediator is what translates behaviour into trust decisions and visibility into action. Most organisations already possess fragments of this capability through their SIEM, XDR, SOAR and behavioural analytics platforms. The work is rarely about starting from nothing. It is about extending what already exists so it becomes capable of supporting the next generation of subjects rather than only the previous generation.
Finally, resist the temptation to declare layer three solved through procurement alone. The market will increasingly offer products claiming to provide agent governance, autonomous-security management or adaptive trust control. Some capabilities are real. Others remain aspirational. The discipline is not rejecting the products; it is resisting the temptation to mistake a product category for a solved problem. Organisations that navigate the next few years successfully will generally be those willing to acknowledge uncertainty, name the gaps that still exist and design for failure modes rather than assuming those failure modes have already been eliminated.
None of those actions are especially radical. They are simply the practical consequence of taking the architecture seriously enough to act on it.
A note on scope: where this argument stopped
Throughout this series I have deliberately argued from IT premises.
The frameworks referenced repeatedly throughout the discussion, including NIST SP 800-207, the CISA Zero Trust Maturity Model, the DoD Zero Trust Architecture and the Forrester ZTX model, were all designed primarily for IT environments. The subjects explored have therefore been humans, workloads and AI agents acting inside IT estates. That boundary was a conscious choice rather than an omission.
The same conversation exists in operational technology environments, but it exists in a materially different form. The substrate assumptions change. The governing frameworks change. IEC 62443 becomes more relevant than NIST SP 800-207 in many contexts. The consequences of error change as well, because an autonomous agent acting against a banking platform and an autonomous agent acting against an industrial process do not fail in remotely the same way. The principles remain recognisable. The implementation does not.
Treating operational technology properly would have required a parallel body of work, and attempting to merge the IT and OT conversations into a single series would ultimately have served neither audience particularly well. If the OT extension of this argument is interesting, I would genuinely like to hear that. The outline already exists. Whether it becomes a future series depends entirely on whether readers believe the problem is significant enough to justify the effort.
What comes next
The thirteen essays are complete, but the broader body of work is not.
A companion reference document will follow, bringing together the architecture in a more structured form than a post series allows. The document will contain the complete subject taxonomy, the full maturity model, evidence indicators and assessment criteria, regulatory mappings, primary-source references, a glossary of terminology and a more detailed treatment of the Barnard Financial Group case study.
The goal is not to replace the essays. The essays explain the reasoning. The reference document explains the implementation.
Subscribers will receive it directly when it is published.
After that, this particular body of work is largely complete. What it argues for is, I hope, durable enough to outlive the specific moment in which it was written. The underlying principles are not especially new. The architecture is simply an attempt to work those principles forward into a generation of subjects that did not exist when much of the foundational Zero Trust work was written. The argument is therefore not that Zero Trust needs replacing. The argument is that it needs extending.
The principles remain sound.
The subject model changed.
Everything else follows from that.
One thing to take from the whole series
If anything survives from these thirteen essays, let it be this.
Zero Trust did not fail in the AI era. The implicit subject model underneath it became incomplete. The frameworks were primarily designed for environments populated by humans and workloads. Autonomous agents introduce a different class of principal: delegated, adaptive, capable of acting across chains of activity rather than isolated requests, and capable of influencing outcomes in ways that are not always visible through traditional controls.
The challenge is therefore not to abandon Zero Trust but to extend it so those subjects can be governed rather than merely accommodated.
That has been the argument running through the entire series. The substrate remains the foundation. The mediator becomes the mechanism through which behaviour is interpreted and governed. The subject layer becomes explicit rather than implied. The feedback loop between mediator and subject becomes central rather than optional, because it is that feedback loop that allows trust to evolve as behaviour evolves.
Above all, the question that matters is not whether an organisation has “done Zero Trust”. The question is where, on each layer, the discipline is real, because that is where the consequential risk lives. It lives in the seams between business units, the gaps between layers, the assumptions nobody noticed becoming outdated and the places where architectural maturity has been assumed rather than demonstrated.
The work is simply to make those gaps visible and close them in the order the architecture suggests.
Thank you for reading.
Colin Henderson
Edinburgh
Post 13 of 13 in Stacked Zero Trust.
Previously: Post 12 - What Vendors Are Over-Claiming Right Now.
The reference document — Stacked Zero Trust: A Working Architecture for the Agentic Era — is in preparation and will be published shortly to all subscribers.
References drawn on across the series are consolidated in the reference document with primary sources cited in full. The principal frameworks the architecture is built in dialogue with are 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 Zero Trust extended framework. The original Zero Trust model is credited to John Kindervag at Forrester Research (2010).