Identity for Agents Is Genuinely Unsolved
Stacked Zero Trust: Post 7 of 13
There’s a particular reason for writing this now.
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.
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.