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

Subscribe now

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).

The obvious way to write about vendor over-claiming is not to name anyone. That’s what I’ve done. The alternative is to pretend this isn’t happening. It is.

If you’re buying in this space just now, you’ll have noticed the shift. Everything is AI-powered, agent-aware, autonomous, or adaptive. Some of that is fair. Some of it is a bit ahead of the product. Some of it is, bluntly, a plan described as if it already exists.

The difficulty isn’t that any single claim is wildly wrong. It’s that they’re just accurate enough to be plausible, and just vague enough to be hard to pin down.

If you can’t tell the difference, you won’t notice immediately. You notice later — when the thing you thought you’d bought doesn’t quite behave the way you expected.

This is written for the buyer trying to avoid that.

There is good work in the market. Some of it is genuinely very good. The problem is sorting that out without sitting through the same conversation repeatedly.

What the market actually does

It’s worth being clear about the baseline before getting into the patterns.

Behavioural analytics is real. It works, and it’s better than it was. Most of the leading SIEM and XDR platforms can do something sensible here once they’re properly integrated, even if getting there still takes more effort than tends to get mentioned.

Correlation across multiple signals is also real, though uneven. Some vendors genuinely bring identity, endpoint, network, and cloud data together in a useful way. Others are still, in practice, centred on one domain with additional feeds attached.

Automated response exists, but tends to be bounded. The more credible vendors are quite clear about where automation stops. The ones who aren’t tend to leave that line deliberately vague.

Where the market is much less settled is around agent identity as a proper subject. There are attempts — some of them credible — but this isn’t a mature category. There’s no consistent model, and no product that joins all the pieces up end-to-end.

That matters, because quite a lot of the current positioning assumes that layer already exists.

Pattern one: new language on old capability

The most common pattern is also the easiest to miss at first.

A product that already does competent behavioural analytics or anomaly detection gets described using the vocabulary of something more advanced — agent-aware, AI identity, agent governance. The capability underneath hasn’t materially changed, but the framing has.

You can usually test this quite quickly. Ask whether the system treats an agent as a distinct subject — its own identity, its own posture, continuously assessed. This is the layer-three question from earlier in the series, asked commercially. If the answer comes back to the agent inheriting the identity of a user or service account, then you’re looking at the existing model described differently.

That isn’t inherently a problem. It becomes one when you assume you’ve moved further up the stack than you actually have.

Pattern two: fast presented as intelligent

A second pattern shows up in how “intelligence” is described.

A lot of systems positioned as AI-driven are, in practice, executing predefined logic at speed. That’s useful — speed matters — but it isn’t the same thing as a model that adapts or learns from new conditions.

The distinction becomes clearer if you ask what the system has learned. A model-based system should be able to describe, in general terms, how it adapts. A rules-based system generally can’t, because it isn’t adapting — it’s applying what it was given.

The difference tends to show up most clearly when something new appears. A model will usually degrade or flag uncertainty. A rule-based approach just won’t match, and often won’t say so.

Again, this isn’t about one approach being good and the other bad. It’s about them being described as interchangeable when they’re not.

Pattern three: the autonomous policy mirage

The more ambitious claims tend to sit around policy.

There’s a recurring narrative that systems can generate and apply access policy autonomously — learning from behaviour and adjusting continuously without human input. In practice, what exists in most cases is recommendation: the system suggests, and a human decides.

That distinction matters operationally.

The simplest way to get at it is to ask what actually changes without a human decision. If the answer is “not much,” then the system isn’t autonomous, regardless of how it’s described. If changes do happen automatically, then you need to understand how, on what basis, and what happens when something goes wrong — because at scale, it will.

Where this tends to cause problems isn’t technical. It’s when teams start assuming the system is handling policy hygiene and ease off the manual work that was doing most of the job.

Pattern four: the demo that doesn’t carry into production

A more subtle pattern sits around how products are demonstrated versus how they behave in practice.

Most platforms demo well and they’re shown against clean data, predictable scenarios, and with the right level of support. That’s normal. Production environments are less cooperative with Data being noisier, behaviour is less predictable, and edge cases show up quickly.

Some gap is expected. The question is how much, and whether it’s been represented honestly. The only reliable way to get a sense of that is to speak to people running the product at scale, against real workloads. Not just the reference case provided, but a range.

If that’s difficult to arrange, or tightly controlled, that’s usually informative in itself.

Pattern five: AI-washed platforms

The final pattern is less about capability and more about positioning.

An existing platform, often perfectly capable in its own right, has AI features added and is then presented as fundamentally redefined by them. In many cases, most of the underlying value remains where it always was.

There’s nothing inherently wrong with that. The issue is when the framing shifts in a way that suggests the value comes primarily from the newer addition.

The simplest check is to ask what capabilities exist only because of AI, and which were already present. If the answer isn’t clear, the distinction probably isn’t either.

What to do with it

You don’t need a large framework to navigate this, but you do need to be a bit more deliberate in how you run vendor conversations.

A consistent set of questions, asked every time, does most of the work:

- What actually changes in a trust decision when this is deployed? Where does its output really land?

- What, specifically, has the system learned? Not in general terms, but in a way that can be explained

- What happens when it encounters something it hasn’t seen before?

- Which decisions are made without a human, and where exactly is that boundary?

- What does failure look like outside a controlled demo?

- Who is running this in production at the sort of scale we care about, and can we speak to them?

None of these questions are particularly complicated. That’s the point and you’re not looking for perfect answers. You’re looking for answers that are consistent, direct, and hold up when you come back to them later.

In practice, how those questions are answered — or avoided — usually tells you as much as the content itself.

A word for the vendors

For anyone on the vendor side reading this and feeling slightly pointed at — it isn’t intended as a broadside.

The pressure to over-claim at the moment is real, and not all of it is cynical. The technology is moving quickly, and in quite a few cases the implementation is ahead of what can be neatly explained or documented.

Most vendors will admit that, if you get into a more direct conversation.

From a buyer’s point of view, the issue isn’t that things are evolving — that’s expected. It’s when positioning runs materially ahead of what can be relied on in production.

The vendors who are clear about where the edges are tend to stand out fairly quickly. The ones who aren’t tend to create more work for everyone involved.

If anything, buyers who ask sharper questions are usually easier to work with, not harder. There’s less to untangle later.

One thing to take from this

None of these patterns are new. Versions of them have shown up in earlier cycles.

What’s different now is the pace, and the fact that genuinely useful capability is evolving alongside a fair amount of loose positioning.

That makes it harder to separate signal from noise.

It gets easier once you know what to look for — and what to ask.

Subscribe now

Post 12 of 13 in Stacked Zero Trust.

Previously: Post 11 - A Maturity Model for Stacked Zero Trust.

Next: Post 13 - The Next-Generation CISO Conversation.*

The reference document at the end of the series includes a longer buyer’s question set and a worked-through example of how the five patterns presented above appear in real product literature, anonymised.

References drawn on in this post: the buyer’s question framing introduced in Post 5 (Layer Two: AI as Mediator) is extended here. No specific vendor is named or referenced. The market description reflects publicly observable product positioning across the major Zero Trust and security analytics categories in mid-2026.

Where, specifically, is the organisation in front of me on this journey?

Not in the abstract. Not in terms of aspiration. At what level, across which layer, with which gaps that matter and which gaps that do not? Without an answer to that question, an architecture may be interesting, but it is not yet actionable. Once that answer exists, the architecture becomes a diagnostic tool, and a diagnostic tool is something a CISO can actually use when deciding where to spend the next quarter’s effort.

This post introduces a maturity model for Stacked Zero Trust, the framework the series has been moving toward from the beginning. It uses five levels, assessed separately across the three layers, while acknowledging a reality that most maturity models struggle to accommodate: real organisations rarely sit at a single level. They are mature in some places, immature in others, and the distance between those places often represents the greatest source of risk.

The model is deliberately not aligned slavishly to the CISA Zero Trust Maturity Model or the DoD Zero Trust Reference Architecture. Both were developed for environments dominated by humans and workloads. Where the substrate layer of this model resembles them, that resemblance is intentional. Where the mediator and subject layers diverge, the divergence is largely the point.

To make the discussion concrete rather than theoretical, the model will be applied to a composite organisation.

Barnard Financial Group is a fictional UK-headquartered financial-services group with approximately 14,000 employees, assembled over fifteen years from four separate entities: Barnard, the original retail bank; Finchale Wealth, acquired in 2014; Usworth Insurance, acquired in 2019; and Auckl, a fintech acqui-hire completed in 2023. Barnard Financial Group is not a real institution, and any resemblance to one is coincidental, but it is constructed from patterns that appear repeatedly across enterprise assessments and customer engagements. Anyone who has spent time inside a multi-entity organisation will probably recognise parts of it.

The composite matters because organisations are rarely at a single maturity level. They are at one level in one business unit, another somewhere else, and frequently at a third where acquisitions, legacy systems or newer technologies have changed the shape of the estate. The gaps between those levels often become more important than the levels themselves, because that is where assumptions begin to break down.

The five levels

The levels need to be memorable enough to survive a meeting and specific enough to support a decision. Five levels have proved sufficient.

Level 1, Ad Hoc, describes an environment where controls exist, sometimes even strong controls, but their existence is largely accidental. Coverage depends on history, individual effort or local priorities rather than a coherent architectural approach. Different parts of the estate often solve the same problem in different ways and, while pockets of excellence may exist, they are not yet part of a repeatable pattern.

Level 2, Defined, is the point at which intent becomes visible. The organisation has articulated an approach, documented expectations and established a framework within which improvement can occur. Coverage may remain uneven, and implementation may lag behind ambition, but there is now a basis for measuring progress because the destination has been described.

Level 3, Managed, is where the architecture moves from paper into operation. Controls are being applied consistently across the relevant estate, evidence exists that they are functioning, and the organisation can demonstrate that the practices it describes are actually being performed. This is often the point at which Zero Trust stops being a programme and starts becoming part of normal operations.

Level 4, Measured, is characterised by visibility rather than implementation. The organisation is no longer asking whether a control exists. It is asking whether that control is effective. Telemetry is available. Gaps can be quantified. Trends become visible. Conversations increasingly shift away from deployment and towards outcomes.

Level 5, Self-Correcting, represents an architecture that learns from its own operation. Evidence produced by the controls influences the design of the controls. In Stacked Zero Trust terms, this is the mediator-subject loop from Post 3 becoming self-tuning: the mediator observes the subject, the subject’s behaviour reshapes what the mediator learns, and the resulting adjustments feed back into policy and configuration without waiting for a manual review cycle. This level is uncommon, and it is worth recognising just how uncommon it is.

These levels are deliberately descriptive rather than judgemental. A Level 2 organisation tackling a genuinely difficult problem may be making excellent progress, while a Level 4 organisation operating in a relatively straightforward environment may have achieved maturity with far less effort. The purpose of the model is not to award grades. It is to describe reality honestly enough that useful decisions can be made.

Applying the levels across the three layers

A single maturity score collapses precisely the distinctions the architecture has spent ten posts establishing. The model therefore applies the levels independently across the three layers, because maturity in one layer tells us surprisingly little about maturity in the others.

For the substrate, Level 3 typically looks like consistent identity hygiene, reliable segmentation, mature data classification and a control environment broadly aligned with the expectations of NIST SP 800-207 and the CISA Zero Trust Maturity Model. By Level 4, the organisation has moved beyond implementation and into measurement. Privilege exposure, federation friction, third-party access pathways and policy exceptions are no longer anecdotal observations but measurable characteristics of the environment. Level 5 appears when those measurements begin driving architectural change and the substrate evolves in response to what operational evidence reveals.

The mediator follows a slightly different path. Reaching Level 3 means the core mediator functions are operating on real estate rather than living inside demonstrations, pilots or presentations. Behavioural scoring, anomaly detection, policy synthesis and automated response are all participating meaningfully in operational decision-making. By Level 4, the effectiveness of those functions is itself being measured. False-positive rates are understood. Response actions are reviewed. Blind spots are visible. Level 5 arrives when the mediator begins improving through the evidence it produces, with buyers able to answer the questions from Post 5 using operational data rather than vendor claims.

The subject layer remains the least mature area for most organisations. A genuine Level 3 position requires agents to be governed as first-class subjects with their own identities, continuously assessed posture, intent-bounded privileges and task-relative behavioural baselines. Very few organisations operate at that level today. Level 4 assumes those controls can be measured and assessed systematically. Level 5, self-correcting subject governance, remains largely theoretical territory as of 2026. It exists in the model because the destination is visible, not because many organisations have arrived there.

The honest picture for most large organisations today is therefore uneven. The substrate is often operating somewhere between Level 2 and Level 3. The mediator is frequently sitting between Level 1 and Level 2, with isolated islands of greater maturity inside security operations. The subject layer remains predominantly Level 1, accompanied by a widespread belief that the subject layer is still somebody else’s problem. One of the model’s purposes is to make that reality difficult to ignore.

The composite: Barnard Financial Group

What does Barnard look like when assessed honestly?

The answer is uneven, which is exactly what makes it useful. Real organisations rarely exhibit a smooth maturity profile. They accumulate history, acquisitions, exceptions, compensating controls and locally optimised decisions. Maturity therefore tends to appear as a patchwork rather than a progression, and Barnard reflects that reality.

The substrate inside the original retail bank, the Barnard portion of the group, sits at approximately Level 3. Identity has been consolidated around a Microsoft estate for more than a decade. MFA enforcement is strong, conditional access is reasonably mature, segmentation exists across much of the banking infrastructure, and regulated data is handled within a mature classification framework. The remaining issues are largely understood: a collection of legacy systems that never fully entered the programme and a number of service accounts retaining broader privileges than their roles strictly require.

The picture changes as soon as the architecture crosses into Finchale Wealth. Here the substrate drops toward Level 1 or, viewed generously, low Level 2. The 2014 acquisition included plans to consolidate identity into the Barnard estate, but the integration stalled. Finchale still operates a separate identity provider federated into the wider environment. The federation functions adequately most of the time, which is often enough to discourage further investment, but it remains a classic break-of-gauge problem from Post 4. The seam exists, the organisation depends upon it, and very few people fully understand it. Privilege boundaries across that seam are blurred in places and difficult to assess confidently.

The Usworth Insurance estate presents a different challenge. The organisation inherited a complex web of managed-service arrangements and third-party access relationships that were never fully mapped during integration. There are controls. There are contracts. There are governance processes. What is missing is complete visibility. Assigning a precise maturity level is therefore difficult because part of the challenge is uncertainty itself. In practice, this is one of those situations where the organisation does not yet know enough about the environment to assess it honestly.

The situation changes again within Auckl. The fintech acquisition enters the model at approximately Level 3 and, in places, approaches Level 4. Identity hygiene was strong from the beginning. Cloud-native platforms dominate the estate. Access management is comparatively disciplined, and API-centric design has avoided many of the historical problems carried by the older businesses. Ironically, that strength is precisely why some of the largest layer-three risks are concentrated there.

The mediator layer across Barnard Financial Group places the organisation at roughly Level 2. Commercial SIEM, XDR and behavioural-analysis platforms are in production. Anomaly detection exists. Behavioural scoring exists. Automated response exists within carefully defined limits. What does not yet exist is a coherent mediator operating across all three layers. The mediator is performing meaningful work, but much of that work remains focused on the traditional subjects rather than the new ones.

The subject layer remains largely Level 1, although the reason deserves attention. The organisation is not lacking AI deployments. Quite the opposite. Auckl has deployed multiple autonomous agents into production, including an underwriting assistant capable of gathering information from systems across the wider group, generating recommendations and publishing outputs into shared repositories. The agents inherit service accounts carrying privileges that would be considered excessive by the standards applied elsewhere in the estate. None of this happened maliciously. The deployments occurred because the organisation treated AI as a feature of an application rather than as a subject within the trust algorithm.

Security architecture was not formally involved because the deployment velocity of the fintech business was fundamentally different from that of the parent organisation.

That is the most consequential finding in the assessment.

It is also remarkably common.

The largest layer-three exposure is concentrated in the technically strongest part of the group, because the technically strongest part of the group is where innovation is occurring. The legacy businesses carry substantial substrate debt, but they carry relatively little layer-three risk simply because they have not yet deployed autonomous subjects at meaningful scale.

The lesson is not that maturity and risk are inversely related. It is that different kinds of maturity expose different kinds of risk, and the architecture has to recognise the distinction.

What the model is for

The maturity model is not intended to be a grading exercise. Its real purpose is to give organisations a vocabulary for discussing Stacked Zero Trust readiness without collapsing the three layers into a single number, and to make visible the unevenness that characterises almost every large estate.

The first discipline is to assess by layer rather than by organisation. A single maturity score is neat, but it is usually misleading. Three scores tell a more complicated story, which is precisely why they are more useful.

The second discipline is to assess by business unit whenever the estate is heterogeneous. Barnard, Finchale, Usworth and Auckl are all part of the same group, yet their maturity characteristics are materially different. The overall picture emerges from understanding those differences rather than averaging them away.

The third discipline is simple but frequently uncomfortable: be honest about Level 1 on the subject layer. Most organisations are still there, and many of them are deploying agents anyway. In practice, the first step towards Level 2 is rarely a technology purchase. It is recognising that agents are subjects and accepting that the existing identity and posture mechanisms were never designed to govern them.

Finally, resist the temptation to chase Level 5 before earning Level 4. Self-correcting controls require measurement. Measurement requires operation. Operation requires implementation. Every vendor promising to shortcut that sequence is, consciously or otherwise, attempting to sell the future before the prerequisites exist. The journey through the levels is cumulative. It cannot be skipped.

The model in its full form, with assessment criteria, evidence indicators and common failure patterns for each layer and each maturity level, sits within the reference document that accompanies this series. The purpose of this post is simply to establish the framework, because the remaining posts depend on a common understanding of what maturity actually means.

One thing to take from this

A maturity model for Stacked Zero Trust only becomes useful when it treats the three layers independently. Real organisations are rarely mature everywhere at once. They are usually strong in one area, developing in another and largely unaware of a third, which means the gaps between layers often matter more than the average maturity level itself.

The Barnard Financial Group case illustrates that unevenness deliberately. Its strongest substrate exists alongside its most significant layer-three exposure, while the parts of the organisation carrying the greatest integration debt create a different class of risk altogether. That pattern is not unusual. If anything, it is one of the most common findings in large, acquisition-driven enterprises.

The purpose of the model is therefore not to assign a score. It is to make unevenness visible, to show where effort should go next, and to give organisations a way of discussing readiness that does not conceal their most important risks behind a single number.

The next post moves from internal assessment to the external market and, in doing so, tackles what is probably the most uncomfortable subject in the series: where vendors are over-claiming, where buyers are over-trusting, and how to distinguish genuine capability from well-marketed aspiration.

Subscribe now

Post 11 of 13 in Stacked Zero Trust.

Previously: Post 10 - Shadow AI Is the New Shadow IT, Only Faster.

*Next: Post 12 - What Vendors Are Over-Claiming Right Now.*

The reference document at the end of the series includes the full maturity model with assessment criteria, evidence indicators, and common failure patterns per level per layer, plus a more detailed treatment of the Barnard Financial Group composite.

References drawn on in this post: NIST Special Publication 800-207, Zero Trust Architecture (August 2020); the CISA Zero Trust Maturity Model and the DoD Zero Trust Reference Architecture as the two reference maturity frameworks that the substrate layer of this model is informed by but deliberately distinct from. Barnard Financial Group is a fictional composite; any resemblance to a real institution is coincidental.

This is shadow AI, and it occupies much the same place in Stacked Zero Trust that shadow IT occupied in the older perimeter model. It is the part of the estate the architecture cannot see, and therefore cannot meaningfully govern.

The similarity is real, but it only goes so far.

The shadow IT problem unfolded over years. SaaS adoption spread at a pace that allowed discovery tools, governance programmes and security teams to adapt alongside it. Shadow AI is moving on a fundamentally different timescale. Capabilities that were research previews eighteen months ago are now being used daily by a large majority of employees, often through personal accounts and often with sensitive corporate information. The discovery problem, the data-exfiltration problem and the governance problem all look familiar, but the velocity does not, and that difference in velocity changes what an effective response looks like.

What the numbers actually say

Before getting into the architecture, it is worth spending a moment on the scale of the problem, because this is where many strategy discussions still understate what is happening.

The industry surveys vary in methodology, but they increasingly converge around numbers that would have sounded alarmist only a few years ago. Roughly 80 percent of workers report using unapproved AI tools in some form. Around 45 percent of US workers admit to using AI at work without disclosing it, while public AI traffic inside enterprises continues to grow at extraordinary rates. Significant proportions of users report entering company information into public AI tools, and many acknowledge doing so without formal approval. At the same time, governance remains immature, with a minority of organisations having comprehensive AI-governance frameworks in place.

The most important number, however, is not necessarily the most dramatic one.

By 2026, the majority of employee interactions with AI are expected to occur through capabilities embedded within existing business applications rather than through standalone AI products. That changes the nature of the discovery challenge. Most shadow AI is no longer someone deliberately bypassing policy to use a prohibited tool. Increasingly it is someone using a sanctioned application that quietly acquired AI functionality after the security review was completed.

The “shadow” is no longer necessarily outside the estate. It is increasingly hidden inside it.

That distinction matters because the controls developed to manage shadow IT were largely built around identifying unsanctioned applications. The harder problem now is identifying sanctioned applications whose capabilities have changed since they were approved.

There is another finding that deserves attention. Organisations that attempt outright prohibition generally discover that prohibition and adoption are not inversely related. Employees continue using the tools because the underlying need does not disappear. The effect is often to push usage further away from visibility rather than eliminate it altogether, making the problem harder to observe and therefore harder to govern.

Why it isn’t quite the same problem as shadow IT

The instinctive response is to treat shadow AI as shadow IT version two, apply the traditional playbook, and expect broadly similar results. Discover what exists. Categorise it. Approve some of it. Block the rest. Educate users and repeat.

That instinct is half-right. The discovery challenge is familiar. The governance challenge is familiar. Even the user behaviour has echoes of the same pattern security teams have dealt with for years. The danger lies in assuming that familiarity means equivalence, because the characteristics that made shadow IT difficult have all returned in altered form.

The first difference is the rate at which the landscape changes. Shadow IT grew on the cadence of SaaS launches and adoption cycles. New services appeared, users found them useful, and organisations gradually became aware of their existence. Shadow AI operates on a different timetable altogether. Model releases arrive continuously. Plugin ecosystems evolve weekly. AI capabilities appear inside applications that have already passed procurement and security review. A CASB designed to discover previously unknown applications does not automatically tell you when an approved platform quietly acquires generative-AI functionality in its next release. The problem is no longer confined to discovering products. Increasingly it is about discovering capabilities inside products whose risk profile has changed since they were last assessed.

The second difference is the nature of the data-exfiltration path. With shadow IT, information was often moving somewhere it should not have gone, but the destination was usually a storage platform of some sort. The data might have been exposed, copied or retained, yet it still existed within a relatively familiar model of movement and retention. Shadow AI changes that picture. Information entered into an AI platform may be retained, processed, incorporated into training pipelines, used for model improvement or used to influence future outputs in ways the user neither understands nor intends. The concern is no longer simply where the data went. It is what the receiving system may subsequently do with it.

The third difference is arguably the most difficult because it sits with the user rather than the technology. Shadow IT was often driven by frustration. Employees adopted unsanctioned tools because approved ones were slow, cumbersome or lacked features they genuinely needed. Shadow AI inherits some of that motivation, but it also benefits from something shadow IT rarely possessed to the same degree: visible and immediate productivity gains. The employee who pastes a confidential document into a public AI service in order to summarise it, rewrite it or analyse it is often doing so because the tool genuinely helps them perform their work more efficiently.

That does not make the behaviour acceptable, but it does make it understandable. Security teams therefore find themselves facing a problem that is harder to argue against than traditional shadow IT. The user is not just bypassing a policy. They are often experiencing a measurable improvement in productivity, quality or speed. Any governance approach that ignores that reality usually discovers that users ignore the governance approach in return.

Taken together, those differences explain why shadow AI feels familiar and unfamiliar at the same time. The shape of the problem resembles shadow IT closely enough that many of the lessons still apply. The pace of change, the nature of the data flows and the strength of the user incentives ensure that applying the old playbook unchanged is unlikely to produce the same results. The organisations handling the problem most effectively are generally not the ones treating shadow AI as a simple compliance issue. They are the ones recognising that the demand is genuine, the technology is moving faster than previous adoption cycles, and the challenge is therefore as much about channelling behaviour as suppressing it.

The architectural reading

Stacked Zero Trust gives shadow AI a place to sit within the architecture rather than treating it as a separate category of disaster.

The substrate carries the discovery problem because shadow AI cannot be governed until it can be seen, and seeing it requires familiar layer-one disciplines applied with a degree of rigour most organisations have not previously needed. Visibility into AI-bound traffic, identity controls capable of distinguishing sanctioned from personal accounts, and data-classification mechanisms that recognise sensitive information leaving the boundary regardless of destination are all substrate functions. None of those ideas are particularly new. What is new is the scale and rate of change involved when there may be thousands of relevant services, many of which either did not exist a year ago or have acquired AI capabilities since they were last assessed. This is really the substrate-amplification argument from Post 4 appearing in a different form. The layer-one work was never fully finished, and the agentic generation of tooling has a habit of exposing unfinished work with very little sympathy.

The mediator carries the behavioural dimension of the problem. Recognising that a user has developed a pattern of AI-tool engagement that warrants intervention is fundamentally a behavioural exercise, requiring conclusions to be drawn from large volumes of telemetry, contextual information and historical activity. That is exactly the sort of problem layer two was introduced to solve. What is interesting is that the more mature implementations increasingly focus on routing rather than blocking. A user attempting to use a personal AI account is redirected towards a sanctioned enterprise equivalent, while substrate controls enforce the distinction if the guidance is ignored. Organisations that immediately block often discover they lose visibility along with control; organisations that successfully redirect usage towards approved options frequently retain both, which means governance remains possible because observation remains possible.

The conversation becomes considerably more interesting once autonomous agents start appearing inside the estate. Today, much of shadow AI still consists of humans using AI tools, but that distinction is becoming less useful as browser extensions, workflow automations, embedded copilot’s and autonomous agents begin acting on behalf of users. At that point the problem stops being solely about people interacting with AI and starts becoming a layer-three problem. These agents inherit privileges, perform actions, and increasingly exercise judgement inside processes that were originally designed for human participants. In many cases no one formally approved their existence because they arrived as features, plugins or convenience tooling rather than as consciously deployed systems.

The shadow-AI conversation is therefore evolving from a discussion about data leaving the organisation into a discussion about autonomous subjects operating inside it. Those subjects may never have been risk-assessed, may not appear in any architecture diagram, and may be carrying privileges inherited from the users who installed them. That is where shadow AI begins to intersect directly with the problems explored in Posts 6, 7 and 8. The challenge is no longer simply discovering tools. It is discovering subjects, understanding how they behave, and governing them as members of the trust algorithm whether they arrived through the front door or not.

What a working approach actually looks like

The practices that appear repeatedly in successful programmes are remarkably consistent.

Discovery starts at the network and identity layers rather than at the application inventory. Looking for a definitive list of AI tools is increasingly an exercise in chasing a moving target. Looking instead for AI-bound traffic patterns, unusual authentication behaviours and personal-account usage provides a much more durable signal. The tooling required is often already present in the form of CASB, SASE and related visibility platforms. The difference is that these tools have to be configured to discover AI usage rather than simply SaaS sprawl.

A second pattern is that organisations provide sanctioned alternatives that are genuinely competitive. Bans fail because users are solving real problems. The most successful programmes tend to offer enterprise-approved alternatives that are integrated cleanly enough into daily workflows that the approved path becomes the convenient path. That requires cooperation between security, technology and business teams in ways that are not always natural but are increasingly necessary.

A third pattern is treating sanctioned SaaS as a moving target rather than a static inventory. The security assessment carried out during procurement becomes progressively less valuable if the platform has subsequently acquired AI capabilities that did not exist when the review was completed. Mature organisations increasingly incorporate AI-capability reviews into vendor lifecycle management rather than treating approval as a one-time event.

The routing principle appears again as well. Where possible, mature implementations redirect rather than immediately deny. The difference between a user employing a personal AI account and the same user employing a sanctioned enterprise account may be no more than a single click, yet that click often determines whether visibility and governance are maintained or lost.

Finally, organisations increasingly need to look explicitly for autonomous agents that no one approved. Browser extensions acting on behalf of users, workflow platforms embedding autonomous decision-making, and copilot’s operating across multiple systems are all examples of layer-three subjects entering the environment through routes that traditional governance rarely anticipated. Identifying those agents and governing them as subjects rather than software is the next stage of the shadow-AI problem, and it is precisely the scenario the preceding posts have been preparing us for.

A line to sit with

The most useful framing I have found for shadow AI is also the simplest.

It is shadow IT with the rate of change increased dramatically, the data-exfiltration path made more consequential, and the user motivation made harder to argue against.

Any one of those differences would require a meaningful response. Taken together, they demand a different posture. The objective is no longer eradication in the way many organisations approached shadow IT. It is channelisation. The underlying demand is real. People are trying to work more effectively, and the architectural challenge is to convert ungoverned use into governed use without losing the people in the process.

The architecture does not solve shadow AI on its own, but it does give the problem somewhere to sit. Discovery belongs in the substrate. Behavioural detection and routing belong in the mediator. The autonomous agents arriving without an invitation belong in the subject layer. Holding all three perspectives in view simultaneously is the change in mindset the agentic generation demands.

One thing to take from this

Shadow AI is shadow IT moving faster, sending data into systems that may incorporate it rather than merely store it, and driven by productivity gains that prohibition alone cannot realistically overcome.

The three-layer architecture maps the problem surprisingly cleanly. Discovery remains layer-one work. Behavioural detection, visibility and routing sit naturally in layer two. The autonomous agents appearing throughout the estate without assessment or approval become layer-three subjects, whether the organisation recognises them as such or not.

The organisations handling this best are rarely the ones trying hardest to eliminate AI usage. They are usually the ones creating approved paths that are good enough to compete with the unapproved alternatives, maintaining visibility into how AI is actually being used, and continuously reassessing both their applications and their assumptions as new capabilities appear.

That closes Act III. The next post moves into the operational payoff of the series: a maturity model for Stacked Zero Trust, and the first appearance of the composite case study that carries through the remainder of Act IV.

Subscribe now

Post 10 of 13 in Stacked Zero Trust.

Previously: Post 9 - Stacked Zero Trust Meets the Regulators.

*Next: Post 11 - A Maturity Model for Stacked Zero Trust.

The reference document at the end of the series includes a fuller treatment of shadow AI discovery patterns and a checklist for assessing the AI capability drift of sanctioned SaaS estates.

References drawn on in this post: industry surveys on shadow AI adoption from 2025-2026 including JumpCloud, Microsoft & LinkedIn Work Trend Index, Awareways Trend Report, Netskope, IBM, McKinsey, Gartner, and others; specific figures cited are from publicly available sources and are summary rather than precise (precise citations appear in the reference document). The “70% of AI interactions through sanctioned SaaS by 2026” projection appears in multiple analyst sources during 2025-2026.

That raises a different question. What happens when regulators begin forming expectations around systems whose architecture is still evolving?

The answer, at least in 2026, is that regulators and architects are often examining the same problem from opposite directions. Regulators describe outcomes: governance, accountability, monitoring, evidence and control. Architects describe mechanisms: identity, trust algorithms, mediators and subjects. Most of the time those perspectives meet somewhere in the middle. Sometimes they do not, and that is what makes the current regulatory landscape interesting.

Across the EU, the UK, the US and the Five Eyes community, regulators have become considerably more sophisticated in what they expect organisations to do with AI systems. In some areas they are arguably ahead of the architecture. In others they are still reasoning about AI as though it were an artefact to be governed rather than a subject capable of acting. The distinction matters because compliance and architecture are ultimately solving different parts of the same problem. Compliance tells an organisation what it must achieve and what evidence it must be able to produce. Architecture determines whether those outcomes can be achieved consistently in the first place.

Viewed through the lens of Stacked Zero Trust, the most useful question is not whether a regulation applies. It is what that regulation is assuming about the thing being regulated, and whether those assumptions continue to hold once the subject becomes agentic.

Four perspectives, then the architectural read.

The EU: ahead on governance

The EU AI Act remains the most consequential piece of AI legislation in the world, partly because of its substance and partly because of its reach. Organisations do not need to be headquartered inside the European Union to find themselves within scope; serving EU users is often enough, which means its influence now extends well beyond the Union itself.

The implementation timetable has been the source of considerable manoeuvring throughout 2025 and 2026, although what has moved is mostly the timing rather than the substance. Certain deadlines have shifted, particularly around parts of the high-risk-system regime, but the underlying obligations remain largely intact. For many organisations the practical challenge is no longer deciding whether the Act matters but determining how quickly they can prepare for requirements whose supporting standards and guidance may arrive much later than they would like.

What is striking, viewed through the lens of Stacked Zero Trust, is how much of the Act is really layer-one and layer-two thinking expressed in regulatory language. Risk management systems, continuous monitoring, governance processes, technical documentation, conformity assessments and incident reporting all point towards the same underlying concern: establish confidence in a system that may behave badly, maintain evidence that confidence is justified, and continue validating that assumption throughout the system’s operational life.

Read through the architecture, most of that maps reasonably cleanly onto the substrate and the mediator. Identity, governance, documentation and control belong comfortably within layer one, while continuous observation, monitoring and response are recognisably layer-two functions. The architecture already has somewhere to place most of what the Act is asking for, which is one reason the alignment feels stronger than people sometimes assume.

The alignment becomes less comfortable once we reach layer three, because the Act still tends to reason about high-risk AI systems as things that can be characterised, documented and governed as identifiable artefacts. That assumption becomes progressively harder to sustain once the subject is an autonomous agent operating through chains of action, delegated authority and continuously changing context. This is one of the places where the architecture is arguably further ahead than the law, not because the law is wrong but because the nature of the subject has changed more quickly than the regulatory model built around it.

The UK: governance through regulators

The UK has chosen a deliberately different path, one that relies on existing regulators extending established frameworks into AI rather than creating a dedicated AI statute. There is no UK AI Act, and there is little indication that one is imminent. Responsibility instead sits with bodies such as the ICO, FCA and Ofcom, each applying AI expectations within its own domain through powers and obligations that already exist.

That distinction matters because the UK’s approach is often described as lighter-touch, when in practice it can feel considerably denser. Instead of dealing with a single AI regulator, organisations frequently find themselves satisfying several regulators at once, each examining the same system through a different lens. A financial-services deployment, for example, may trigger UK GDPR obligations, Consumer Duty requirements, SMCR accountability expectations and, where EU operations are involved, parts of the EU AI Act as well. The result is less a unified AI regime than a collection of overlapping perspectives on the same problem.

The ICO has moved furthest. Its strategy, Preventing Harm, Promoting Trust, increasingly frames AI as a cybersecurity issue as much as a privacy issue. By 2026 its guidance explicitly addresses AI-enhanced phishing, deepfake social engineering, automated vulnerability discovery, AI-assisted malware, credential attacks, data poisoning and indirect prompt injection.

What is interesting is how familiar the recommendations sound once they are read through an architectural lens. The ICO points organisations towards the NCSC Cyber Assessment Framework, Cyber Essentials, the Cyber Governance Code of Practice and the government’s AI Cyber Security Code of Practice. These are recognisably substrate controls reinforced by mediator-style monitoring and governance capabilities. The regulators have, in effect, codified the layer-one position.

For UK organisations the architectural interpretation is therefore relatively straightforward. Most current guidance maps cleanly onto layers one and two. Questions of governance, accountability, monitoring and control are increasingly well served. Layer three remains the gap, because the guidance increasingly acknowledges AI systems as sources of risk while still tending to treat them as things an organisation deploys rather than subjects capable of acting on its behalf. The architecture has already crossed that line. The regulatory guidance is still making its way towards it.

The US: governance through frameworks

The US is harder to describe because there is no single regime to describe. What exists instead is an ongoing contest between state-level regulation and federal attempts to establish a uniform position, with organisations caught somewhere in the middle. While federal policy has moved towards deregulation and pre-emption, states have continued building their own approaches, producing a landscape that remains fragmented and actively contested.

Colorado’s AI Act is the clearest example, creating obligations for developers and deployers while recognising frameworks such as NIST AI RMF and ISO/IEC 42001 as evidence of reasonable care. California and Texas have pursued their own paths, while the broader federal-state pre-emption debate remains unresolved.

Whatever happens politically, the practical response has been surprisingly consistent. Organisations looking for a defensible position have tended to align themselves with NIST AI RMF and ISO/IEC 42001, not because either framework answers every question, but because they provide a common language that regulators, auditors and legal teams increasingly recognise.

Viewed through Stacked Zero Trust, that places most of the US conversation firmly in layer one, with some extension into layer two. The emphasis remains governance, controls, accountability, documentation and risk management. Continuous monitoring appears largely in support of those governance objectives rather than as a separate architectural capability in its own right.

The same layer-three gap appears here as well, because the frameworks largely continue to reason about AI as something to be governed rather than something acting as a subject in its own right. Even where ideas such as identity resolution start to emerge, the harder questions around delegated authority, behavioural trust and autonomous action remain only partially addressed, leaving the architecture asking questions that the framework literature has only recently begun to explore.

The Five Eyes: closest to the architecture

The single most consequential piece of agentic-AI guidance issued in 2026 does not belong to any one jurisdiction.

*Careful Adoption of Agentic AI Services*, published on 1 May 2026 by ASD ACSC, CISA, NSA, the Canadian Centre for Cyber Security, NCSC New Zealand and NCSC UK, is the first coordinated Five Eyes guidance focused specifically on autonomous AI agents. More importantly, it is the first major document that begins approaching the problem in a way that looks recognisably architectural.

The guidance groups risk into five categories: privilege risk, design and configuration risk, behavioural risk, structural risk and accountability risk. It goes on to recommend concrete controls including cryptographically anchored identities, short-lived credentials, mutual-authentication mechanisms, behavioural monitoring, incremental rollout practices and human approval workflows for higher-risk actions.

What makes the document particularly interesting is not simply the controls themselves but the assumptions underneath them. The guidance implicitly accepts that agents need distinct identities. It assumes behaviour must be monitored as behaviour rather than inferred from static state. It recognises that chains of activity can create risks not visible within individual actions. In other words, it starts from assumptions that look remarkably similar to those explored throughout this series.

A note on parallel work is owed here, and I would rather make it openly than leave it implicit.

*Careful Adoption of Agentic AI Services* was published while posts 6, 7 and 8 of this series were being drafted, and a careful reader will notice a degree of convergence between the two. The document’s treatment of agent identity aligns naturally with the argument that agents should be understood as first-class subjects. Its discussion of behavioural risk aligns closely with the trust-scoring discussion from Post 8. Its treatment of structural risk maps directly onto the chains-and-cascades argument running through the series.

That convergence should not be surprising. When multiple practitioners examine the same emerging technology seriously and reason from first principles, they often arrive in similar places. Both bodies of work are describing the same underlying problem from different directions.

The Five Eyes guidance and Stacked Zero Trust are solving related but different problems. The guidance provides a detailed control catalogue covering identity, behaviour, privilege, structure and accountability. What it does not attempt to provide is an architectural model showing how those controls interact or depend on one another. That is where the layering becomes useful, because it provides a coordinate system within which the controls can be located and understood rather than simply listed.

For any organisation taking agentic AI seriously, the Five Eyes guidance is now required reading.

Where the architecture is still ahead

Step back from the jurisdictional detail and something more interesting begins to appear.

The regulators have become considerably more sophisticated in what they expect. The Five Eyes guidance demonstrates that particularly clearly. Identity, governance, monitoring, accountability and control of privileged actions are no longer theoretical concerns. They are increasingly explicit expectations.

What remains largely absent is a connective layer.

The Five Eyes guidance tells organisations what to do about agent identity, behaviour, structure and accountability in considerable detail. The EU AI Act describes governance and risk-management obligations. NIST AI RMF provides categories, principles and controls. All of them are useful, and none of them are wrong.

What none of them are trying to answer is a slightly different question: how do these controls fit together inside a functioning trust model?

This is not a criticism of those documents. They are doing precisely the jobs they were written to do. It is, however, the gap an architectural framework is supposed to fill.

The architecture tells us which controls depend on which others. It reveals where governance without visibility becomes ineffective, where monitoring without identity loses context, and where behavioural controls become difficult to operate in the absence of a coherent trust model. It does not replace the controls. It explains how they cohere.

That distinction becomes more important as organisations move from experimentation into operational deployment. The requirements themselves are demanding enough. The deadlines are real. The audit conversations are already happening. Yet meeting the compliance requirement and answering the architectural question are not quite the same thing, because the former is increasingly expected while the latter remains unevenly understood.

A note on the moving target

A final point is worth being explicit about.

The regulatory positions described above are accurate as of mid-2026. They will not remain unchanged. EU deadlines may move again. The US pre-emption debate may resolve in several different ways. UK regulators will continue publishing guidance that subtly shifts expectations over time.

Anyone treating this post as a definitive compliance reference is using it incorrectly. Treat it as a snapshot of the landscape at the moment the series is being written, and treat the architectural interpretation as the durable part.

The reference document at the end of the series will provide a more complete regulatory treatment with primary sources cited directly. The architecture itself, by contrast, is less dependent on political outcomes. Whatever happens to specific deadlines, enforcement dates or jurisdictional disputes, the underlying architectural questions remain largely the same.

One thing to take from this

The most interesting thing about the regulatory landscape in 2026 is not that the EU, UK, US and Five Eyes communities have adopted identical approaches. They clearly have not. What is striking, however, is how often they arrive at remarkably similar concerns despite taking different routes.

Identity. Governance. Monitoring. Accountability. Control of privileged actions. Confidence that systems behave within acceptable bounds and that organisations can demonstrate that confidence when challenged.

Those concerns map surprisingly well onto the three layers of Stacked Zero Trust.

What remains largely unresolved is how the controls fit together architecturally. Regulations and guidance documents are increasingly good at describing what organisations should do. They are generally less concerned with describing how those controls cohere inside a working trust model, and that is the gap architecture exists to fill.

Compliance remains necessary. The deadlines are real. The Five Eyes guidance in particular is likely to influence procurement, governance and audit conversations for years to come. Compliance alone, however, is not the same thing as architectural adequacy. The organisations that do best in the next phase will be the ones that treat regulatory compliance as an input into the architecture rather than a substitute for it.

The next post turns to a different but related problem: how organisations are expected to govern AI systems they often do not even know they have, as shadow AI begins to follow the same path shadow IT took before it.

Subscribe now

Post 9 of 13 in Stacked Zero Trust.

Previously: Post 8 - Trust Scoring a Probabilistic Subject.

Next: Post 10 - Shadow AI Is the New Shadow IT, Only Faster.

The reference document at the end of the series includes a fuller treatment of the regulatory landscape with primary sources, and the OT/IEC 62443 dimension that this series otherwise treats as out of scope.

References drawn on in this post: **Careful Adoption of Agentic AI Services**, joint guidance co-authored by ASD ACSC, CISA, NSA, the Canadian Centre for Cyber Security, NCSC New Zealand, and NCSC-UK, published 1 May 2026 (Five Eyes); EU AI Act (Regulation (EU) 2024/1689) and the European Commission’s November 2025 Digital Omnibus proposals; UK ICO AI and biometrics strategy and May 2026 cyber-threat guidance; UK NCSC Cyber Assessment Framework and Cyber Essentials; UK government AI Cyber Security Code of Practice; FCA AI update and the joint Bank of England / PRA approach to AI in financial services; UK Data (Use and Access) Act 2025; the US Executive Order of December 11, 2025 (”Ensuring a National Policy Framework for Artificial Intelligence”); NIST AI Risk Management Framework and NIST Cybersecurity Framework Profile for AI; ISO/IEC 42001; Colorado AI Act (SB 24-205); California TFAIA; Texas RAIGA; US Treasury Department AI framework (February 2026). The Five Eyes guidance was published as this series was being drafted; convergent observations between the two bodies of work were arrived at independently.

An agent can have a perfectly valid identity and still be in a state that warrants less trust at the moment it makes a request. It may have drifted from its intended task, be operating on poor information, or be halfway through an injection attempt that has not yet produced an obviously bad outcome. The trust algorithm has always wanted to account for that kind of uncertainty. For human users and workloads it has developed a reasonably workable set of tools for doing so. Agents create a different problem, because many of those tools are not merely imperfect in this context but built around assumptions the subject no longer satisfies.

This post is really about those assumptions, how they fail, and what has to change once the subject becomes probabilistic.

What trust scoring quietly assumes

A risk score, in the trust algorithm’s traditional shape, expresses how much the system currently trusts a subject. It folds together identity confidence, device posture, behavioural baseline, contextual factors such as time and location, and threat intelligence into a number, or more often a band, that the policy engine consults when deciding whether to grant access, require step-up authentication, or block.

Traditional trust scoring assumes there is a meaningful baseline of normal against which deviation can be measured. For users that baseline comes from history. For workloads it comes from deterministic function. In both cases deviation matters because normality itself is relatively stable. It also assumes the subject’s current condition is broadly knowable. Identity, posture, recent behaviour and context provide a picture that, while incomplete, is usually sufficient to support a decision.

Beneath both of those sits a third assumption that often goes unnoticed. The score is expected to be calculated at discrete moments, attached to a request, and treated as sufficient for the policy decision that follows.

Agents challenge all three assumptions simultaneously, and the effect is cumulative rather than independent.

The baseline problem

An agent doesn’t have a stable baseline in the sense the older subjects do — Post 2 made that argument, so I won’t repeat it here. What matters is what the absence of that baseline does to the score itself.

If the legitimate behavioural envelope of an agent is wide and shifting, deviation becomes a weak signal. Tighten the envelope and the score trips constantly on legitimate behaviour, generating noise until operators either stop trusting it or disable it altogether. Widen it enough to accommodate legitimate variance and the opposite problem appears, because subtle influence remains comfortably within the boundary the score was designed to monitor. Either way, the value of the score begins to erode.

The instinct is often to abandon baselining altogether and fall back to static rules. The better move is to recognise that the wrong thing is being baselined.

Baselining the agent’s outputs is largely hopeless. Baselining the task the agent is performing is much more tractable. A “review supplier contracts” task has a structure, a sequence of activities, and an expected range of outcomes that can be observed across many executions. The useful comparison is not whether a particular agent is behaving like itself, but whether a particular task execution resembles other healthy examples of the same task.

That shifts what the score is even measuring. The traditional score asks whether a subject is behaving like itself, while the agentic score increasingly asks whether a task is behaving like a healthy member of its class. Those are different questions, built around different assumptions, and they produce different signals. The important thing is that tasks possess a degree of structure that agents often do not, which makes the second question considerably more achievable than the first.

The current-state problem

The difficulty begins with something that sounds deceptively simple: what exactly is the agent’s current state?

The model weights are largely static. The conversation history is not, and may contain everything the agent has processed so far, including adversarial input. There are tool calls, intermediate outputs, external data sources, and whatever interpretation the agent has placed on them along the way. None of that resembles the posture data the substrate is comfortable consuming, and very little of it fits neatly into a conventional trust-scoring model.

The older score can often be computed from a relatively small amount of state: who you are, where you are, what device you are using, and what you have done recently. The agent’s state is both richer and harder to access. Some of it is observable. Much of it is not.

That does not mean it is impossible to reason about. Recent tool calls are visible. Patterns in those calls can be analysed. Sudden divergence, unusual query sequences, unexpected resource access, or behaviour that no longer aligns with the task can all provide useful signals. The score has to become comfortable drawing inferences from behaviour because there is no posture API that exposes the underlying state in any complete way.

The consequence is that an agentic trust score is far more inferential than the substrate’s score ever needed to be. That sounds like a subtle distinction, but it changes the nature of the evidence being used and, with it, the kinds of mistakes the system will make. False positives look different. False negatives look different. Operators who have spent years learning how to interpret conventional trust scores will need to develop a different intuition for the agentic version. The transition is not free.

The discreteness problem

The third assumption, that scoring can happen per request, is probably the one that breaks most dramatically, and it has received surprisingly little serious attention.

A single agent task is typically a chain of operations. Scoring each one independently creates exactly the failure mode described earlier in the series: forty entirely plausible requests that, when viewed collectively, constitute a problem no individual request reveals.

The score has to become a property of the task in progress rather than a property of the current request. It needs to evolve as the task unfolds. It needs to rise or fall as more evidence becomes available. Most importantly, it needs to respond to the direction the task is taking rather than the isolated action currently in flight.

That is not a trivial engineering problem. Most policy engines are designed around discrete evaluations. Maintaining a continuous score for a task, updating it as activity accumulates, and allowing action to be taken mid-task, whether slowing the agent down, escalating to a human, or terminating execution altogether, requires infrastructure most environments do not yet possess.

Some vendors are building that capability now. Others are attaching the word agent to existing per-request scoring and hoping nobody looks too closely.

This is also where the buyer’s question becomes fairly straightforward. The issue is not whether a platform can generate a score but what unit the score is attached to. Can the platform maintain and evaluate trust continuously across a task in progress, or is it still evaluating isolated calls one at a time? A vendor that cannot answer those questions clearly is usually selling traditional trust scoring to a problem it was never designed to solve.

What a working agentic trust score looks like

By this point the shape of an agentic trust score starts to emerge.

It is no longer really about the agent as an isolated subject. The meaningful baseline sits at the task level, because tasks exhibit a degree of structure that agents themselves often do not. Equally, the score is built less from explicit state and more from inference. It draws conclusions from behaviour, tool usage, sequencing and context because the posture-style signals the substrate expects do not meaningfully exist.

Most importantly, it stops being something calculated per request. The score persists for the duration of the task and evolves with it, rising or falling as the overall trajectory becomes clearer. Whether the underlying platforms can actually deliver that capability is a separate question, and one where the reality remains uneven.

The purpose of defining the shape is not to claim implementation has caught up. It is to provide a way of evaluating products that claim to govern agents. The question organisations should be asking is therefore a simple one: does the platform’s trust-scoring model match the shape of the problem, or is it simply the older model with newer terminology wrapped around it?

What this means for the architecture

If all of that is true, the implications for the architecture are reasonably direct.

The mediator in layer two has to become something more capable than the substrate ever required. A trust score built around tasks rather than requests depends on maintaining context across the life of a piece of work, which means the mediator has to understand more than the action immediately in front of it. It has to maintain state across an agent’s working session, recognise changes in direction as they emerge, and intervene while the task is still unfolding rather than after the fact. Those are not optimisations or future enhancements. They are the conditions that make agentic trust scoring possible at all.

Following that through leads to a second consequence, which is that the cost of being wrong changes shape as well. Under the older model, a false positive often meant a request was challenged or denied. Annoying, certainly, but usually recoverable. Once the thing being scored is a multi-step task, an intervention that arrives at the wrong moment can have a much larger impact. The task may not resume cleanly. Context may be lost. Work that took minutes or hours to accumulate may disappear with it.

That makes the traditional allow-or-deny mindset look surprisingly brittle. Where the architecture permits it, graceful slowdown, increased scrutiny, or escalation to a human are often better responses than immediate termination, not because the score matters less but because the consequences of acting on it are no longer confined to a single request.

There is a third implication that is easier to overlook because the score itself becomes part of the attack surface. A scoring model built from observable behaviour can be studied, and a determined adversary will eventually start asking the same question defenders do: what behaviours attract attention, and which ones do not? Once that happens, influence does not have to bypass the score. It only has to remain within whatever tolerance the score allows while steering the agent towards a different outcome.

Trust scoring, in other words, becomes something that can itself be manipulated. That does not make the score useless any more than phishing made identity useless. It does mean mature implementations will need to treat aspects of the scoring model as sensitive, vary signals over time, and avoid exposing every decision factor to the thing being evaluated. The substrate rarely had to concern itself with subjects actively studying the scoring engine. Agentic systems almost certainly will.

One thing to take from this

Trust scoring a probabilistic subject is not a matter of taking the substrate’s model and adjusting a few thresholds.

The baseline moves from the agent to the task being performed. The evidence moves away from posture and towards behavioural inference. The score itself stops being a discrete judgement attached to a request and becomes a continuous assessment of where a piece of work is heading and whether it is still behaving as expected.

None of those changes exist because the substrate was poorly designed. They exist because the substrate was designed for subjects with properties that agents simply do not possess. The result is that trust scoring becomes a different kind of problem, one that depends as much on understanding tasks, trajectories and influence as it does on identity, posture or access rights.

That leaves an obvious question. If identity, trust scoring and governance all have to change to accommodate agentic subjects, what happens when regulators begin forming expectations around systems whose architecture is still evolving?

The next post turns to exactly that question, because in several places the regulatory conversation is now moving faster than the architectural one.

Subscribe now

Post 8 of 13 in Stacked Zero Trust.

Previously: Post 7 - Identity for Agents Is Genuinely Unsolved.

Next: Post 9 - Stacked Zero Trust Meets the Regulators.

The reference document at the end of the series includes a fuller treatment of the agentic trust score, including the signal categories the mediator should be drawing on.

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 in which scoring sits; user and entity behaviour analytics as the established antecedent of behavioural risk scoring; the concept of task-relative baselining draws on principles from model monitoring and observability, where population comparison is standard practice.

In May 2026, the Five Eyes agencies — ASD ACSC, CISA, NSA, the Canadian Centre for Cyber Security, NCSC New Zealand, and NCSC-UK — published *Careful Adoption of Agentic AI Services*. It’s the first coordinated guidance from that group on autonomous AI agents, and it’s a serious piece of work.

At the centre of it is a clear architectural position: agents should be treated as proper principals, with distinct, cryptographically anchored identities.

That direction is right. The difficulty is what that actually depends on, and how much of that infrastructure most organisations don’t have yet.

The rest of this post is about that gap, because taken at face value the guidance reads like a design choice — represent agents correctly and proceed — when in practice it assumes an identity model that most environments simply aren’t in a position to support.

This is the point in the series where things stop behaving cleanly. Of the properties that start to break once the subject is an autonomous agent, identity is the one I find hardest to make sit still. The others — posture, least privilege, breach — are difficult, but you can at least see the outline of a workable answer. Identity doesn’t behave like that; the more closely you look at it, the less clear it becomes what is actually being managed.

This post doesn’t try to resolve that. It stays with the problem.

There are three parts to it: what identity is quietly doing for the older subjects, where that starts to fracture once the subject is an agent, and what a serious response looks like — not a solution, but a way of working that holds together well enough for now. There isn’t a clean conclusion at the end, and that’s the honest state of it.

What identity quietly does

For human users and workloads, identity is doing more than one job at once.

It names an actor — a person or a service. It ties that actor to a credential — the thing used to prove identity. And it anchors authority — permissions and accountability — to that combination. We tend to treat those as one thing because, in practice, they line up closely enough for the model to hold.

Authentication checks the credential, authorisation determines what that identity can do, and audit ties activity back to it afterwards. It works because the mapping broadly holds: one actor, one identity, one authority model.

When that mapping starts to loosen, the rest of the model follows it. Agents loosen it quickly.

Fracture one: delegation

The first break appears as soon as an agent acts on behalf of a user.

There’s now a human with their own authority, and an agent doing work in their name. The question sounds simple — whose identity is actually on the request — but it doesn’t resolve cleanly in practice.

One option is to run the agent as the user. That’s still more common than anyone admits, and it’s also the weakest model: a non-deterministic process operating with full human authority and very little constraint.

A second approach is to give the agent its own identity, with an “on behalf of” link back to the user. That’s cleaner, and broadly where things have landed, but the link itself is blunt. The user authorised an intent; the agent is now executing a sequence of actions the user never actually specified.

A third approach is to issue short-lived, task-scoped credentials. That gets closer to what you would want, but it depends on infrastructure and policy models that most environments don’t yet have.

Even then, the underlying question doesn’t go away. If something fails mid-task, the chain of responsibility is real but not well defined — the user’s intent, the agent’s decisions, and the system’s permissions all played a role. The clean mapping the older model relies on simply isn’t there anymore.

Fracture two: agents calling agents

It gets harder again once delegation isn’t a single step.

Agent A calls agent B. B calls C. C calls something else. Each step makes sense locally, but by the time an action is taken you’re several steps removed from where it started, and it becomes much harder to say what identity you’re actually dealing with.

Is it the originating user, the immediate caller, or the agent currently holding the credential? There isn’t a stable answer.

Most of what exists here borrows from human delegation models — propagated tokens, chained claims — but those weren’t designed for systems where each step is making its own decisions. Delegation stops being an edge case and becomes the default, and once it nests, the identity model you started with doesn’t quite match the structure you’re operating.

Fracture three: identity by influence

This is the one the model doesn’t really recognise at all.

In a recent engagement designing a multi-MSSP MXDR integration framework — built so providers could be swapped without locking the customer in — the question came up of introducing an agent under one of the existing service accounts.

The account itself was well controlled: read-only network admin role, token rotation, all the expected discipline. The logic was straightforward — AI already works well in analytics, so extend it into operations.

That assumption collapses two different problems into one. AI analysing data and AI acting on systems are not the same thing.

The controls in place were doing exactly what they were designed to do. They protected against the credential being stolen. They did nothing about the credential being used correctly by an agent that had been influenced into doing the wrong thing.

That’s the distinction that matters. Prompt injection isn’t credential theft; the credential is valid, properly issued, and correctly used. The system sees a legitimate subject behaving within its permissions. What changes is the behaviour, not the identity.

There’s an added wrinkle in architectures like this. The framework was deliberately built for portability — credentials and playbooks were designed to move cleanly between providers. That works when the operator is human or deterministic. It becomes much harder to reason about when the operator is an agent whose behaviour is shaped by what it processes.

You end up with valid identity attached to behaviour you no longer trust, and nothing in the model that explicitly recognises that gap.

Fracture four: revocation in a chain

Revocation is the control most identity systems fall back on.

In the older model, it works well enough — revoke the credential and the actor stops. With agents, that assumption doesn’t hold.

By the time you revoke, the agent may already be mid-task, operating across multiple systems with actions underway or queued. Some will already have completed; others will trigger downstream effects later. Revocation stops what happens next, but it doesn’t unwind what’s already in motion.

At that point, authority isn’t a simple switch. It’s distributed across a chain of activity that can’t be cleanly pulled back, and the problem shifts from prevention to containment.

What a serious response looks like

There isn’t a clean answer to this.

What does hold up in practice is a shift in how identity is treated — less as something you establish once, and more as something you observe over time. The question becomes not just whether the identity is valid, but whether the behaviour attached to it still aligns with what that identity is meant to represent.

Permissions on their own aren’t enough. They describe what is possible, not what should actually happen, and that gap becomes more significant once actions are being decided dynamically.

Revocation also has to be treated differently. It doesn’t reset the system; it just limits what happens next. The system still has to deal with actions already in flight.

None of this resolves the underlying problem. It just makes it manageable.

What to do with it

You don’t solve this neatly at design time, so it shows up in how systems are evaluated and run.

The questions are practical ones: what is actually acting here — the user, the agent, or something in between; where delegated authority really stops; how far a chain can extend before it stops being understandable; what influence would look like in that system and whether you would recognise it; and what revocation actually stops versus what continues anyway.

You won’t get perfect answers, but you do need answers that are consistent enough to work with.

One thing to take from this

Identity for agents isn’t just a more difficult version of an existing problem. It’s a different problem expressed using the same vocabulary.

The older model assumes identity, credential, and authority line up. Agents separate them. Delegation becomes continuous, chains become normal, behaviour can shift without identity changing, and revocation only goes so far.

That is the gap the Five Eyes guidance is pointing at, even if it doesn’t spell it out directly. Treating agents as proper principals is the right direction. The difficulty is that, in most environments, the model those identities would sit inside isn’t ready for the kind of subject they represent.

The risk isn’t that the guidance is wrong — it’s assuming the infrastructure behind it already exists.

Subscribe now

Post 7 of 13 in Stacked Zero Trust.

Previously: Post 6 - Layer Three: AI as Subject.

Next: Post 8 - Trust Scoring a Probabilistic Subject.

The reference document at the end of the series sets out a fuller subject taxonomy, including the identity, delegation, and revocation characteristics specific to each subject type.

References drawn on in this post: NIST Special Publication 800-207, Zero Trust Architecture (August 2020), for the subject and authentication model; OAuth 2.0 delegated authorisation flows (RFC 6749) and the on-behalf-of pattern (token exchange, RFC 8693) as the standard delegated-identity primitives; SPIFFE/SPIRE as an example of workload identity issuance relevant to agent-as-service-identity approaches. Prompt injection as a category is discussed in line with the OWASP Top 10 for Large Language Model Applications.

Post 2 argued that agentic AI is a new kind of subject, one that breaks several of the assumptions the trust algorithm quietly relies on. Post 3 placed that subject inside the architecture as layer three, while the intervening posts dealt with the substrate beneath it and the mediator above it.

Now we get to the subject itself.

The central idea is easy enough to state. Treat the autonomous agent as a first-class subject of the trust algorithm. Not as a feature of an application, not as an unusually active service account, and not as a workload with eccentric behaviour. Treat it as its own kind of principal, making requests, receiving authority, taking actions, and requiring governance in exactly the same structural sense as any other subject.

Stated like that, the idea sounds almost ordinary. Most architectural changes do when they’re reduced to a sentence or two.

The difficulty appears when you try to honour that decision in practice, because nearly every tool the substrate uses to govern subjects was built around properties that agents don’t reliably possess. The further you follow the implication, the more things that once felt settled begin to move under your feet.

Identity is one example. Posture is another. Least privilege changes shape entirely. Even breach, which feels like one of the more stable concepts in security, starts to mean something slightly different once the subject is capable of reasoning, delegation, and autonomous action.

This post takes those four properties in turn. It doesn’t offer finished answers, because most of those answers don’t exist yet. What it does offer is a clearer description of where the model begins to strain, because understanding the shape of the problem is ultimately more useful than pretending the problem has already been solved.

Identity, when the subject can be talked into things

For a human or a workload, identity is relatively settled territory. There is a credential, an entry in a directory, a means to authenticate, and a means to revoke. Privilege attaches to the identity, and the identity is stable enough that the attachment means something.

Agents make that picture harder surprisingly quickly.

The mechanical part is awkward enough on its own. Agents frequently operate under delegated authority, which means questions of provenance and accountability become difficult once you step beyond the simplest examples. An agent may be acting on behalf of a user while invoking another agent, which then calls a tool or a service on its behalf. By the time an action is taken, it can be far from obvious whose authority is actually being exercised, or where responsibility should sit if something goes wrong.

That is a difficult engineering problem, but it is at least recognisable as one.

The deeper challenge sits elsewhere.

An agent’s effective behaviour is partly shaped by the information it processes. That isn’t unusual in itself; humans are influenced by information too. The consequence is different. A subject can remain correctly authenticated, continue using its legitimate credentials, and still be persuaded into acting against the interests of the identity it carries.

Prompt injection is the clearest example. The credential hasn’t been stolen. The authentication process hasn’t failed. The agent is doing exactly what it has been allowed to do, while being influenced into doing something it shouldn’t.

That leaves us in an uncomfortable position. Our identity systems are built around the idea that an authenticated subject acts either on its own behalf or on behalf of a legitimate principal. Agents introduce a third possibility: an authenticated subject acting on behalf of whoever most recently influenced its reasoning.

The frameworks don’t really have a place for that.

Identity for agents is not just difficult. It is genuinely unsolved, and unsolved enough to deserve a post of its own later in the series.

Posture, when there is no device to inspect

The substrate has a mature idea of posture.

A device reports its patch level, configuration state, compliance status, and a range of other signals that help establish whether it is fit to be trusted. The trust algorithm folds those signals into its decisions because they provide a reasonably reliable picture of the subject’s health.

The difficulty appears as soon as you ask what posture means for an agent.

There is no operating system to inspect, no familiar compliance baseline to measure against, and no straightforward equivalent of device health. The thing you are trying to assess is a reasoning process, which means the question shifts from configuration to behaviour.

You stop asking whether the subject is patched and start asking whether it is operating within its intended scope. You stop asking whether the configuration has drifted and start asking whether the behaviour has drifted. The focus moves away from state and towards conduct.

That is a different kind of assessment entirely.

The nearest equivalents come from model monitoring rather than device management. Is the agent behaving consistently with its stated purpose? Is it operating within expected bounds? Is there evidence that it has been diverted from the task it was originally given?

Those questions are real, and they matter. They are also questions about a process in motion rather than a static condition.

The trust algorithm has never been especially comfortable dealing with posture as a behavioural judgement, particularly when the behaviour itself is probabilistic and continuously changing. Assessing the health of a subject whose health is itself a behavioural question turns out to be a different problem entirely, which is why posture deserves its own treatment later in the series.

Least privilege, when actions cannot be detailed

Least privilege has always depended on being able to predict, at least broadly, what a subject needs in order to do its job.

For humans and workloads, that is often difficult but still achievable. Roles can be defined. Permissions can be scoped. Access can be limited to what a function requires.

Agents complicate that because the very thing that makes them valuable is their ability to work out the steps for themselves.

A request like “review the supplier contracts and flag anything unusual” doesn’t naturally decompose into a fixed list of actions that can be scoped in advance. The agent may need to access three systems or seven. It may need to revisit information it didn’t expect to use. It may discover a path through the task that wasn’t obvious when the instruction was first issued.

The more successful the agent is at reasoning, the less predictable the exact sequence becomes.

That creates a tension at the heart of least privilege. Scope access too tightly and the agent cannot complete the task. Scope it broadly enough to accommodate uncertainty and you end up granting substantial authority to a fast, autonomous, and highly adaptable subject.

That is exactly the situation least privilege was intended to avoid.

The direction that seems to hold up is to stop treating privilege as something fixed at the start of a task and instead treat it as something granted and withdrawn as the task unfolds. In that model, authority follows demonstrated need within an authorised intent and disappears once the need disappears.

That approach is coherent in principle, but still immature in practice. More importantly, it depends almost entirely on the mediator being capable of making those decisions continuously and at machine speed.

None of that makes least privilege impossible.

It does mean that the shape of the problem no longer resembles the static scoping model the substrate is comfortable with, and we’re still working out what the replacement looks like.

Breach, when the credentials were used correctly

Assume breach is one of the foundations of Zero Trust, and for the older subjects it has a reasonably recognisable shape.

Someone steals a credential. Anomalous behaviour appears. A workload starts doing things it has never done before. The details vary, but there is usually some observable sign that a compromise has occurred.

The agentic version is stranger.

When an agent is successfully influenced partway through a task, every action that follows may still be formally legitimate. The credentials remain valid. The authentication remains correct. Every request may appear authorised when viewed individually.

Nothing has been stolen.

Nothing has been broken.

The subject has simply been persuaded.

That distinction matters because many of the signals the substrate relies on are signals of compromise. The agentic failure mode is often a failure of influence rather than compromise, which means the behaviour can remain superficially legitimate even while the outcome becomes increasingly harmful.

In practice, this changes what assume breach means.

For agents, it increasingly becomes the assumption that a correctly authenticated, properly credentialled subject may nonetheless be acting against your interests. The subject may not be hijacked in the traditional sense. It may simply be influenced.

That is a much stranger thing to design against than a stolen password, and it pulls us back towards the loop introduced earlier in the series.

Ultimately, the only realistic prospect of detecting this kind of failure is a mediator capable of observing behaviour rather than simply verifying credentials.

Why this matters now

At this point it would be reasonable to look at all four areas and conclude that layer three is simply too early; that the problems are interesting, but not yet operational.

The difficulty with that conclusion is that the agents are arriving anyway.

Organisations are already introducing autonomous agents into production environments, often because the commercial pressure to realise value from AI arrives long before the governance catches up. In practice, the decision is rarely whether to deploy agents or not. More often, the decision is whether to understand the gaps before deployment or discover them afterwards.

That changes the value of the model.

The purpose of layer three isn’t to provide finished answers. If those answers existed, this would be a considerably shorter series. Its purpose is to make the unresolved visible, because an organisation that can identify where a particular deployment depends on agent identity, behavioural posture, dynamic privilege, or influence-resistant trust is already in a better position than one that assumes those problems were solved elsewhere.

That may not sound dramatic, but it matters.

A surprising amount of the current conversation assumes that agents can simply inherit the governance models built for users and workloads. Sometimes that assumption is explicit. More often it isn’t stated at all. The model continues to work until the point where it doesn’t, and that point usually arrives in production rather than in design.

Seen that way, the value of naming the gaps becomes fairly practical.

It tells you where to be cautious. It gives you better questions for vendors. It tells you which capabilities in the mediator layer matter most, because the mediator is carrying much of the burden that the substrate can no longer carry on its own.

Most importantly, it stops you mistaking an unsolved problem for a solved one.

One thing to take from this

Treating the autonomous agent as a first-class subject sounds straightforward until you follow the implications.

Identity becomes vulnerable to influence in ways the existing model doesn’t understand. Posture turns into a behavioural assessment rather than a device assessment. Least privilege can no longer rely entirely on permissions defined in advance, and breach begins to include situations where the credentials were used correctly all along.

None of those problems is fully solved.

What matters, for now, is knowing where they sit, understanding which of your deployments depend on assumptions that no longer hold, and resisting the temptation to treat unresolved questions as if they were settled simply because the technology is already being deployed.

That closes the central act of the series.

The next three posts move into the hardest problems in their own right, beginning with the one this post could only touch briefly: identity for agents, and why it is genuinely unsolved.

Subscribe now

Post 6 of 13 in Stacked Zero Trust.

Previously: Post 5 - Layer Two: AI as Mediator.

Next: Post 7 - Identity for Agents Is Genuinely Unsolved.

The reference document at the end of the series includes the full subject taxonomy, setting out how agents, agentic chains, and model-as-tool subjects differ from humans and workloads across identity, posture, and verification.

References drawn on in this post: NIST Special Publication 800-207, Zero Trust Architecture (August 2020), for the subject, posture, least-privilege, and assume-breach principles; the practice of model monitoring as the nearest analogue for agent posture; Model Context Protocol as an example of agent-to-tool interaction relevant to agent governance. The argument that autonomous agents should be treated as distinct principals with their own identity also appears, in different form, in **Careful Adoption of Agentic AI Services** (joint Five Eyes guidance, May 2026), which Post 9 engages with in detail; the two bodies of work were developed independently and the convergence is discussed there.

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.

Subscribe now

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.

Layer one is the substrate: identity, device posture, segmentation, application and data controls, policy engines, enforcement points — all applied to the subjects Zero Trust has traditionally handled well: humans and workloads. Everyone recognises it, and most assume it’s broadly in hand. In most organisations, it isn’t — and that gap starts to matter a lot more once AI enters the picture.

Boiled down, it comes to two things. The substrate is more unfinished than we tend to admit, and under AI those weaknesses don’t just sit there anymore — they get exercised.

The substrate isn’t finished

Zero Trust has been around long enough that people assume the foundations are largely solved. The maturity data consistently says otherwise — most organisations are still uneven, strong in some areas and noticeably thin in others. That’s not really a capability problem. It’s structural.

Identity is the obvious example. Most large environments run multiple identity providers — the residue of acquisitions, partial transformations, and programmes that never fully landed. What you end up with isn’t a single identity plane, it’s a set of federated seams that work well enough most of the time, but were never designed to behave as one system.

There’s a useful parallel in the early railways. Different companies laid track to different gauges — Brunel’s broad gauge versus what became the standard elsewhere. On a map, it looked like a connected network. In reality, it wasn’t. Where lines met, trains couldn’t pass through. Everything had to stop, unload, and transfer across the gap — creating delay, cost, and failure points that were never fully engineered out. The Gauge Act came later, but by then the fragmentation was already embedded.

Enterprise identity looks much the same. It presents as one organisation, but underneath it’s multiple systems meeting at seams where federation, translation, and trust relationships paper over the differences. On paper, unified. In practice, loosely stitched together.

Those seams — trust relationships, service accounts, third-party access — are rarely understood end to end, and almost never tested under stress. What you have isn’t a clean foundation, it’s a position that holds, until it’s pushed.

And that’s the point. This is the normal state, not an exception. The business keeps moving, and the control layers never quite catch up before the next change lands.

AI doesn’t inherit weakness — it accelerates it

If the substrate were just incomplete, this would be a familiar problem. The issue is what happens when you introduce autonomous agents into that environment.

Agents don’t sit neatly on top of those weaknesses — they run straight through them.

They operate under delegated authority in estates where privilege boundaries are already blurred. The difference is pace and behaviour. Humans are slow, predictable, and naturally bounded. Agents aren’t. They operate at machine speed, follow chains of action the user never explicitly defined, and adapt to whatever they encounter.

That changes things quickly.

The federation path no one ever crossed becomes something an agent moves through in milliseconds. The over-privileged service account that was tolerable in a deterministic world becomes a problem the moment a non-deterministic actor inherits it. The third-party access that sat there untouched for years suddenly becomes reachable.

None of these are new vulnerabilities. They were always there. The difference is you don’t get away with them anymore.

What “good enough” actually looks like

This isn’t an argument for waiting until the substrate is perfect — that’s never going to happen. The shift is toward clarity: knowing where it’s weak, and factoring that directly into what you allow on top of it.

In practical terms, that means knowing how many identity providers you actually have — not what the diagram says — and where the seams really sit. Knowing which service accounts carry more privilege than they should, because those are the ones you least want anything autonomous touching. Knowing where third-party and managed access actually reaches, particularly where it extends further than people think it does.

None of this is new work. It just moves from “good hygiene” to “non-negotiable,” because the cost of not knowing is no longer measured at human pace.

The point

The substrate is less complete than most organisations assume, and under agentic AI those gaps get exercised quickly and at scale. You can’t stack a governed AI layer onto an ungoverned foundation and expect it to hold.

Most environments aren’t built on rock — they’re built on a mix of solid ground and sand, with more seams than anyone is fully comfortable with. The first step is being honest about where those seams are, and letting that shape what you build next.

Subscribe now

Post 4 of 13 in Stacked Zero Trust.

Previously: Post 3 - The Three Layers of Stacked Zero Trust.

Next: Post 5 - Layer Two: AI as Mediator — the decision layer, and the gap between what it can actually do today and what’s being claimed.

The reference document at the end of the series includes a substrate-readiness assessment as part of the full maturity model.

References drawn on in this post: NIST Special Publication 800-207, Zero Trust Architecture (August 2020); the CISA Zero Trust Maturity Model as the standard reference for substrate maturity banding; industry Zero Trust maturity survey data referenced in general terms, with specific sources cited in the reference document; SPIFFE/SPIRE as an example of workload identity. The break-of-gauge reference draws on the British railway gauge incompatibilities resolved in large part by the Gauge Act 1846.

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).

Subscribe now

It read like something written to persuade. That wasn’t really the intent. I’m not pitching anything here, and I’m not trying to sell a position. What follows is closer to a set of essays — an attempt to think something through properly and see where it leads, in the company of people dealing with the same problems.

So this one takes a slightly different approach.

In the first post I made a claim and left it largely unproven: that Zero Trust didn’t fail, the subjects did. That the architecture is sound, but the implicit model of who it polices has quietly become incomplete.

This post does the work of proving it.

To get there, you have to ask a question the frameworks don’t ask directly. Not what is Zero Trust — that has been answered often enough. The question is narrower, and a bit more awkward:

what, exactly, is a subject?

Every access-control model has one, whether it names it explicitly or not. The subject is the thing that makes a request. In NIST SP 800-207, it’s one half of the central transaction: a subject requests access to a resource, and the policy decision point evaluates whether to allow it. Everything else — identity, device posture, risk scoring — feeds into that decision.

In other words, the trust algorithm exists to answer a very specific question about the subject: should this requester, in this context, be granted access to this resource, right now?

NIST is explicit that subjects include more than human users. It talks about users and devices, and the broader Zero Trust literature has long included workloads, services, and machine identities. Machine-to-machine traffic has been in scope from early on.

So the simple objection — “Zero Trust has always handled non-human subjects” — is true, but it misses the point.

The question isn’t whether the subject can be non-human. It’s whether the subject behaves in a way the model depends on.

What the frameworks never needed to say, because it was simply true at the time, is that subjects were assumed to have a particular shape. They were stable enough to model, identifiable enough to bind to credentials and privileges, and they made requests in discrete units.

Those properties sit underneath most of the machinery.

Once you pull on them, the model starts to behave differently.

Agentic AI pulls on all three at once.

Assumption one: subjects are stable

Stability, in this context, doesn’t mean immutability. It means behaviour falls within a range you can characterise.

A human user has patterns — where they log in from, what they access, how they tend to move data. A workload is more predictable still; it tends to execute the same function in roughly the same way each time.

A large part of modern control depends on that being true. Behavioural analytics, anomaly detection, risk scoring — all of them rely on being able to establish some notion of “normal” and then measure deviation from it.

The assumption is rarely stated outright, but it sits behind the control. If behaviour is stable enough, deviation carries meaning.

Agents don’t behave like that, and that isn’t something you patch around. It’s what they are.

Their behaviour is non-deterministic by design. The same instruction can produce different reasoning and different outcomes. Once you give an agent tools and some autonomy, the variation increases further, because the path it takes depends on what it encounters, and what it encounters changes.

An agent that handled something conservatively yesterday may take a more active approach today — not because anything is wrong, but because both behaviours sit within its legitimate range.

From the perspective of the control, that creates an awkward trade-off.

You can widen the baseline far enough to accommodate the variation, at which point very little is flagged. Or you can tighten it and watch the agent trigger it constantly. Either way, the signal degrades.

The baseline-and-deviation model still works well for human and workload subjects.

It’s much less clear what role it plays here.

Assumption two: subjects are identifiable

Identifiability is about being able to say, with confidence, what is acting and to tie that to authority.

For human users, the model is well understood: an identity in a directory, a credential, increasingly stronger forms of authentication. For workloads, it’s service identities, certificates, workload identity systems. In both cases, you can point at the subject, you can scope its permissions, and you can revoke it.

Agents complicate this, and they don’t do it all at once.

At the simplest level, there’s the familiar pattern of an agent acting on behalf of a user. Even here, things don’t resolve cleanly. If the agent runs as the user, you’ve effectively handed a non-deterministic process full user authority. If it runs as its own identity, you’ve separated the actions from the user whose intent is supposed to be driving them.

Most real implementations land somewhere in between — delegated tokens, on-behalf-of flows, scoped credentials. That model works tolerably well when software is calling software in predictable ways. It is less obviously suited to a system that decides for itself how to break a task down.

Then delegation starts to chain.

Agent A calls agent B. B calls C. By the time C makes a call, you may be several steps removed from the original request. The chain is real, but the model for reasoning about it is underdeveloped.

On top of that, there’s a failure mode that doesn’t quite fit anywhere in the existing model.

Prompt injection is often described as an input problem, but its effect is on the subject. An agent whose behaviour is shaped by the content it processes can be influenced into acting against the interests of the identity it carries. The credential hasn’t been compromised. It’s being used exactly as intended.

What has changed is the agent’s behaviour.

The system has no way to express or detect that shift in terms of identity.

Assumption three: subjects make discrete requests

The third assumption is quieter, but it shapes how everything operates.

The model treats the request as the unit of control. A subject asks for access, a decision is made, and access is granted or denied. Each request is evaluated in isolation.

That works when requests are naturally bounded.

Agents don’t produce bounded requests. They produce sequences.

A single instruction — review contracts, analyse data, investigate an issue — expands into a chain of actions across multiple systems. The user expresses intent, and the agent determines how that intent is carried out.

Those steps aren’t always predictable in advance. Often they only become clear as the process unfolds.

From the point of view of the policy engine, this appears as a series of individual requests, each plausible on its own and each evaluated accordingly.

What it doesn’t represent is the relationship between them.

There’s no concept of the intent tying the steps together, no way of evaluating the behaviour as a whole, and no mechanism to revisit earlier decisions once a later step reveals a problem.

By the time something looks wrong, the earlier steps have already happened.

The unit of behaviour has shifted to the chain.

The unit of control has not.

That gap is where a significant portion of the risk sits.

Why this is a subject problem, not an AI problem

It would be easy to read all of this as “AI is difficult to secure” and look for AI-specific controls.

That’s not quite the right framing.

The frameworks didn’t get AI wrong. They modelled the subjects they had, and those subjects behaved in ways that made the assumptions reasonable. Humans and workloads are stable enough, identifiable enough, and discrete enough for the model to hold.

Those weren’t arbitrary choices. They were accurate generalisations.

The issue is that those properties were treated as inherent to what a subject is, rather than incidental to the kinds of subjects that existed at the time.

Agents are the first broadly relevant subject that break those assumptions while still clearly being subjects. They make requests, they need access, and they have to be governed.

The trust algorithm still applies.

It’s the model of the requester that no longer fits cleanly.

One thing to take from this

A subject is whatever your access-control model treats as the thing making requests.

For a long time, subjects shared properties that made them relatively straightforward to reason about: their behaviour was stable enough to model, their identity was clear enough to bind to authority, and their requests could be evaluated individually.

Those properties were effectively taken for granted.

They aren’t anymore.

Before changing architecture or tooling, it’s worth stepping back and looking directly at those assumptions, and asking which of your current controls depend on them. Most do, and often more heavily than it first appears.

That’s where the work starts.

In the next post I’ll lay out the structure that sits over this — the layers in Stacked Zero Trust, how they relate to each other, and why the boundary between them matters more than the layers themselves.

Subscribe now

Post 2 of 13 in Stacked Zero Trust.

Previously: Post 1 - Zero Trust Didn’t Fail. The Subjects Did.

Next: Post 3 - The Three Layers of Stacked Zero Trust - the architectural overview that the rest of the series builds on.

The full subject taxonomy - a complete reference table of subject types and their identity, posture, and verification characteristics - 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), for the subject/resource/policy-decision-point model; SPIFFE/SPIRE as an example of workload identity issuance.

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.*