What Is a Subject, Actually?
Stacked Zero Trust: Post 2 of 13
The first post in this series was, if I’m honest, a bit too corporate.
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.
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.