Is ID-JAG the AI Agent Identity Solution? What the past tells us…

Originally published on LinkedIn: https://www.linkedin.com/pulse/id-jag-ai-agent-identity-solution-what-past-tells-us-jonathan-sander-fsbie/

Cloud and SaaS stretched our trust boundaries far outside our firewalls. Today’s workloads commonly use several different hosted platforms to tie together best of breed features. The bleeding edge of AI is often an extreme example of this federated approach. The obvious security implication is we need to trust these suppliers, and they need ways to trust one another. Every security practitioner working with these systems has scrutinized users, the rights they’re granted, and the policies applied across multiple systems to make sure there’s no gaps in controls. It’s no fun, and messing it up can have real consequences. It’s like spinning plates, and there’s too many of them on very high sticks. AI agents threaten to take what’s been barely spinning and make it scale to the point where it all comes crashing down down.

This is the setting for the new IETF draft: Identity Assertion Authorization Grant, ID-JAG for short. The idea is simple enough. Use the IdP to give you access tokens for multiple services. It compares this to the idea of Single Sign On (SSO) for a person. There’s one authentication event which authorizes access to many relying parties. Most importantly, there’s one policy that determines what these tokens will access and using what rights. This also extends that idea to machine, workload, AI, and other non-human access scenarios; so far beyond the world of traditional SSO. Some-THING can authenticate once and then gain access to many services, all with the IdP acting as a broker and a place to audit all these access events.

We Need Something Like ID-JAG Urgently

ID-JAG seems like a very elegant extension to existing OAuth and OIDC flows. Nothing it’s adding seems unnatural. It’s easy to grok the two central ideas:

1. The central IdP holds the policy for access across all relying parties.
2. A token is issued that authorizes access that comes from a place a service already trusts.

I don’t know about you, but when something has that sort of elegance it seems more powerful to me. It’s no mistake that the folks who are first to champion this are from Okta, because you can already see policies at the user access layer in their SSO products which look very much like the ones being suggested in this new draft.

When talking with our customers about Non-Human Identity (NHI) workloads, we consistently hear about the severe policy limitations when systems and agents need to span multiple applications. Put more simply, they need a central way to coordinate access so that a condition in one application (the "if") can directly govern an outcome in another (the "then") For instance, a single policy should ensure: if an agent is authorized to access PCI scope data in this system, then it is also authorized to access PCI scope data in that other system. Allowing the people governing access to centrally coordinate policy so all the "ifs" and "thens" are in one place would be a clear and urgently needed win for the good guys.

We also hear people expressing fear of the hordes of AI Agents crashing into their tech stacks. These agents demand new ways to express policies that control access across every domain and in ways that have previously only been needed for human, interactive sessions. So ID-JAG feels like a good idea which is appearing at exactly the right time.

First Signs of Trouble

Not every system will use the same IdP.

This is the elephant in the room. The ID-JAG draft itself is scoped for situations where the client and the resource server share the same IdP. That’s fine for demos, maybe fine for smaller orgs. Usually large enterprises have multiple IdPs due to mergers, acquisitions, regional deployments, or just because one business unit went with Azure AD while another chose Okta. And that’s before you cross organizational boundaries to vendors, partners, or customers. In practice, “same IdP” is the exception, not the rule. If ID-JAG adoption depends on it, we’ll end up with silos of interoperability instead of a true enterprise-wide solution.

There will be layer 8 & 9 challenges.

At layer 8 (people) and layer 9 (politics), things get messy. People don’t always align, and organizations definitely don’t. The big IdP players — Microsoft, Google, Okta, Ping — don’t naturally want to trust each other’s assertions. They’d rather keep customers inside their walls. Even if the spec makes it technically possible, you still have to overcome human friction, organizational incentives, and literal geopolitical issues around data residency and compliance. We saw this dynamic with WS-Fed vs SAML vs Shibboleth in the 2000s (more on that in a moment). The protocols worked, but cooperation between giants was slow because people, organizations, and politics didn’t line up.

Some players will lag in support and threaten all this elegance with irrelevance.

Not everyone moves at the same speed. Smaller SaaS vendors are usually slow to fully implement the latest OAuth profiles. Many still struggle with basic OIDC. If ID-JAG relies on broad support across the long tail of apps, it risks being held back. Just like in the SAML days, the niche SPs only built out federation when a large customer demanded it, and even then it was often buggy or incomplete. Without consistent adoption, the beautiful ID-JAG flow falls apart the moment you hit a lagging app.

Déjà vu a la Past Standards

It wasn’t hard for me to imagine these issues because I didn’t have to analyze and think about them. All I had to do was remember. There’s an interesting analog hiding right in the first analogy this standard uses - SSO. The reigning champ of SSO for a long time was SAML (in most enterprise settings it’s still the champ). SAML had many similar challenges in its early days.

How SAML Struggled

1. Same-IdP problem: SAML started out mostly in bilateral, “same ecosystem” setups. An enterprise used one IdP and one SaaS, and both sides exchanged metadata manually. Multi-IdP setups were fragile and uncommon. The comparison here is obvious.
2. Layer 8 (people) challenges: SAML often failed in practice because administrators on both sides had to coordinate metadata, cert rollovers, and attribute mapping. Human friction — lack of knowledge, inconsistent implementation, or just people not talking to each other — caused countless failures. This was a big issue for SAML, but seems less likely for ID-JAG. Though, I’m not 100% certain I can rule this out until it gets some laps around the track in practice.
3. Layer 9 (politics) challenges: The big vendors each pushed their own federated identity story. Microsoft leaned on WS-Fed and ADFS, higher-ed communities built around Shibboleth, Sun and IBM each had their own SAML stacks. These political fiefdoms slowed down cooperation. Even when the tech was interoperable on paper, organizational and vendor politics made actual federation hard to achieve. The community as a whole is pretty united around OAuth & OIDC, but extensions like this are always tricky and we would need to see what it goes.
4. Small players lagged: Many SaaS apps only implemented just enough SAML to support Salesforce or Okta integrations. Features like encrypted assertions or proper attribute release were inconsistently supported. We all know where this is. If you need any convincing this can be an issue, please refer to the SSO Wall of Shame.

We STILL Need Something Like ID-JAG Urgently

ID-JAG is a very elegant extension to existing OAuth and OIDC flows - as stated above. The real question will be: is ID-JAG the thing we need or is it just something that’s close to the mark? There will be a lot of factors that come into making those choices. If remote MCP servers quickly become commonplace, the fact that they require OAuth 2.1 could weigh in heavily. Though you could make a case that this will bake in the current OAuth 2.1 and extensions like ID-JAG will sit in the waiting room for a long time despite its elegance. If the AI-ification of all the things means that these new generation of transitive trusts must happen super fast, then ID-JAG may be the only game even close to town (even if it’s not in town yet). It will then benefit from that board room pushing down pressure to “get it done” which surrounds AI right now. That would clear most if not all of the obstacles I’m imagining here very quickly. In the end, it remains to be seen. Every day that passes means a new idea could emerge. But ID-JAG is a pretty good spark to start this fire. And it’s a fire we need to spark up unless we’re all going to get burned.

What Is Astrix Doing About It?

I’d be remiss if I didn’t point out we’re not just being spectators to all of this. The major reason we’re hearing so much about this in our conversations is we are both helping illuminate the problems and offer solutions. The discovery and security posture capabilities we have for NHIs (machine identities, workload identities, or whatever term you prefer here) are helping give insight to where this is happening. It’s probably not shocking to anyone who lived through the cloud era that the business is off and running in AI and handing out static tokens bearing standing access to all their LLM powered apps and AI Agents. And our Agent Control Plane offers a solution that will centralize that access and policy management. We’ve built it to apply all the best practices and standards to the problem, and we would totally welcome a solution like ID-JAG to come and simplify some of the tricks we’ve had to use to do it. We’re rooting for elegance just as much as everyone else. Until then, we'll keep the plates spinning for people waiting for there to be less plates or better sticks.