Scattered identity icons being sorted into four ordered layers, illustrating non-human identity acronyms grouped by function.

Non-Human Identity 101: The AI-Agent acronym soup, sorted

by

Hiya folks.

If you’ve stuck your head into non-human identity or anything involving AI agents and identity over the past year, you’ve probably hit the same wall I did. Not a hard concept. Just a wall of acronyms. DPoP. SPIFFE. ID-JAG. XAA. CAEP. SVID. A few of them sound like spare droids from Star Wars.

I spent longer than I’d like to admit being quietly confused by all of it. The thing that finally helped was realising most of these aren’t rivals fighting over the same job. They sit at different layers, and each one answers a different, fairly plain question. Once I could sort them into those questions, the soup stopped being intimidating.

So this post is me handing you that sorting. It’s aimed at whoever’s new to this corner of identity. No deep protocol internals, no assumed background. Just the map I wish someone had drawn for me. This space is moving quickly and some of it isn’t settled, so I’ll flag what’s stable versus what’s still baking. Everything’s linked at the bottom if you want to check my working.

Here’s the whole thing in one breath:

The four questions

  1. Who is this workload? → SPIFFE / SPIRE
  2. Prove you actually hold this token? → DPoP
  3. Can this app act on my behalf over there? → ID-JAG and relatives
  4. The robot needs access too? → non-human identity / agentic identity

If that’s all you came for, you’re sorted. If you want the why behind each, read on.

The mental model: an office building full of badges

Picture an office building. People walk around with badges. The badge says who you are, the door reader decides what you’re allowed into, and if you leave, your badge stops working. Simple, and we’ve done it for decades.

Now the building fills up with things that aren’t people. Scripts. Service accounts. Pipelines. And lately, AI agents wandering the halls trying to open doors on someone’s behalf. The old badge system starts creaking, because it was built for humans who log in once in the morning and go home at night.

Each acronym below is really just a fix for one specific crack in that badge system. Same building, harder problem.

1. “Who is this workload?”

The first crack: machines need to prove who they are, and for years we did that with shared secrets. An API key here, a password in a config file there. Copy one, and you are that machine as far as everything else is concerned. Not great.

SPIFFE is the standard answer. It gives each workload its own cryptographic identity instead of a shared secret, and SPIRE is the software that hands those identities out. The identity document a workload receives is called an SVID. Think of it as the machine getting its own badge, minted fresh, rather than everyone sharing one master key taped under the keyboard.

The big cloud providers solve a similar problem with Workload Identity Federation, which lets a workload swap its native cloud identity for a short-lived token rather than carrying a static key around. Different flavour, same goal: stop machines sharing secrets.

SPIFFE is a graduated project under the CNCF, so this layer is about as settled as anything here gets. If you take one idea from it: a workload should have an identity, not a password.

2. “Prove you actually hold this token”

Second crack. Say a workload has a token. Most tokens today are what’s called bearer tokens, which means whoever holds it can use it. Like cash. If I nick your token, I can spend it, and nothing stops me.

DPoP (Demonstrating Proof of Possession) fixes that by binding the token to the client’s own key. The token only works when presented by the thing that actually holds the matching private key. Back to badges: it’s a badge that only works in your hand. Photocopy it and the copy is useless.

There’s an older, certificate-based way to do roughly the same thing called mTLS token binding. Same intent, heavier setup. DPoP is the lighter, more common choice on newer builds.

Both are published RFCs, so this layer is stable too. The one-liner: proof-of-possession turns your token from cash into a badge with your face on it.

3. “Can this app act on my behalf over there?”

Now the interesting bit, and the one drawing the most attention right now.

You’re logged into App A. App A needs to go and do something for you in App B. The old way was either handing App B a long-lived API key, or making you click through a consent screen every single time. Neither scales when you’ve got dozens of apps, and it really doesn’t scale when an AI agent wants to hop across five of them in a row without stopping to ask you to log in again at each door.

ID-JAG (Identity Assertion JWT Authorization Grant) is the emerging standard for this. Your identity provider issues a short-lived, signed assertion that says “this really is this user, and this app is allowed to act for them”, and the receiving app trades that for its own access token. It’s a signed permission slip, so nobody has to hand over their actual badge.

A few names you’ll see near it:

  • Token Exchange (RFC 8693) is the underlying OAuth mechanism ID-JAG is built on.
  • On-Behalf-Of, often shortened to OBO, is Microsoft’s long-standing version of the same delegation idea.
  • XAA (Cross-App Access) is the product branding one vendor uses for their ID-JAG implementation, aimed squarely at the agent-hopping-across-SaaS-apps scenario.

ID-JAG itself is still a draft working its way through the IETF, so expect details to shift. But the shape of it looks like where things are heading, and there are public playgrounds you can poke at to watch a token exchange happen live (linked below).

4. “The robot needs access too”

The newest and least settled layer, so I’ll be honest about how much is still hand-wavy.

Non-Human Identity, or NHI, is the umbrella term for every identity that isn’t a person. Service accounts, bots, workloads, and now AI agents. The reason it’s suddenly everywhere is scale. The non-human population has quietly outnumbered the human one in most organisations, and by a wide margin. You’ll see ratios thrown around from tens-to-one up past a hundred-to-one, and the exact figure depends heavily on who’s counting and what they’re counting. Treat any single number as directional rather than gospel. The direction, though, isn’t really in dispute.

Agentic identity is the narrower, buzzier subset: identity built specifically for AI agents that act semi-independently. Several vendors are actively building here, including one that’s shipped a dedicated agent-identity framework layered onto its existing directory. Sitting alongside this you’ll hear about CAEP and the broader Shared Signals framework, which let an identity provider push a real-time “revoke this session now” signal to other apps. That matters a lot when the thing holding access is an agent that might go off the rails at 3am while you’re asleep.

I’ll be upfront: this layer is genuinely unsettled. Standards are landing month by month and the vocabulary keeps shifting under everyone’s feet. If you feel like you can’t quite pin it down yet, that’s not you. It’s the state of the field.

The cheat sheet

Stick this somewhere handy.

QuestionAcronymWhat it isWhere it sits
Who is this workload?SPIFFE / SPIREOwn identity for each machine, no shared secretsMature (CNCF)
Prove you hold the token?DPoPBinds a token to the holder’s keyStable (RFC 9449)
Act on my behalf elsewhere?ID-JAGSigned “act for this user” assertionEmerging (IETF draft)
The robot needs access?NHI / Agentic IDIdentity for bots and AI agentsStill settling

The one mental model that ties it together: SPIFFE answers who is this machine, DPoP answers prove you hold this token, and ID-JAG answers let this app act for a user somewhere else. NHI is the umbrella the whole conversation now lives under.

Where I’m still figuring things out

A couple of honest gaps, since I’d rather say so than pretend.

The agentic layer is the obvious one. I don’t think anyone can tell you with a straight face exactly how agent identity shakes out over the next two years, because the standards aren’t finished. Anyone who’s very certain here is probably selling something.

The second is how neatly these layers actually stack in a real deployment. On a slide they line up beautifully. In an actual estate, with legacy service accounts and half-migrated apps, it’s messier. That’s the next thing I want to dig into, and it’s likely the next post: less “what is this acronym” and more “here’s how I’d actually wire it together”. No promises on timing. I’ve been known to let a follow-up sit for a while.

If I’ve got something wrong above, tell me. I test what I can, but this is me learning in public as much as anything.

Catch you in the next one.

References

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.