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