User: "Book me a flight, then expense it, then update my calendar."
Agent: "On it."
Agent to booking agent: "Book this flight."
Booking agent to payment agent: "Charge this card."
Payment agent: "...on whose authority, exactly?"
That last question is the one your CIAM architecture probably cannot answer yet.
Why this is arriving faster than your roadmap
The Auth0 Token Vault hackathon winner put a spotlight on something identity teams have mostly filed under "next year's problem": what happens to authorization when one agent invokes another agent on a user's behalf. What looks like a developer convenience feature carries CIAM architecture consequences that identity teams need to scope deliberately.
I've written before about the shape-shifting login, the idea that tomorrow's credential is not a static key but something that changes shape as it moves. Multi-agent workflows are where that stops being a metaphor. When an orchestrating agent calls a specialized agent, which calls a payment API, the identity context has to survive every hop. If it doesn't, you have a chain of tokens where nobody downstream can prove who actually authorized the action, only that somebody, somewhere, held a valid token.
That distinction is the one authorization models in multi-agent environments have to be built around.
Identity-chained authorization, and why "valid token" is the wrong bar
The common failure mode looks like this: most systems treat a valid token as sufficient proof to act. In a single hop from human to app, that's mostly fine. In a five-hop agent chain, "I hold a valid token" tells you almost nothing about intent, scope, or the human who started the whole thing.
Identity-chained authorization means every agent in the workflow can prove three things: who the original human principal was, what that human actually authorized, and that each intermediate agent stayed inside those bounds. The payment agent shouldn't just verify it received a token. It should be able to answer "did the human who started this chain consent to a charge of this size, to this merchant, right now?"
If your architecture can't carry that context across hops, the chain collapses into something worse than a single overprivileged token. It becomes a laundering path for authority, where each agent adds a layer of abstraction between the action and the person accountable for it.
We already fought this war, in human identity
Enterprises spent the last decade cleaning up overprivileged service accounts. The pattern was always the same: a service account gets broad scopes because narrowing them is annoying, then it sits there for years, and eventually it's the thing that shows up in the incident report.
Token delegation between agents without scoped constraints is that pattern reborn, except it moves at machine speed and it multiplies. One human action can fan out into dozens of agent-to-agent calls. If each delegation passes along the full scope it received instead of the minimum the next step needs, you've rebuilt the overprivileged service account problem, now with more actors and less human oversight per decision.
The fix we learned then applies now: delegation should narrow, never widen. Each hop should hand down a scope constrained to the task in front of it, and no more. The difference is that in the agentic world, you have to enforce this by design, because there's no human pausing to notice that an agent is asking for far more than it needs.
Most CIAM platforms weren't built to reason about this
Identity teams standardized on a single platform face a structural challenge worth naming directly. CIAM as a category grew up around human-to-application flows. Authenticate a person, issue a token, let an app act. The mental model has a human at one end and a resource at the other.
Non-human principal calling non-human principal, on behalf of a human who is no longer in the loop, breaks that model. Some platforms are bolting on token vaults and delegation primitives now, and that's genuinely useful. But a vendor feature announcement does not answer the question you actually have to answer, which is whether your authorization model can represent and enforce a chain of delegated intent across principals your platform was never designed to think about.
This is exactly why I keep coming back to vendor-neutral framing. The question worth prioritizing is which architectural pattern your CIAM layer has to enforce regardless of which platform you're on, so that when vendor roadmaps shift, your authorization model remains intact.
What to scope now
Teams that are still pre-production on agentic workflows have a genuine window to get the authorization model right before the first agent calls the second. A few things worth putting on the table before you do:
Define your authorization chain policy first. Decide now what "prove the original principal" means in your environment, what claims must travel with a delegated action, and how a downstream service verifies them. Retrofitting this after an agent charges something it shouldn't have is not a position you want to negotiate from.
Treat every delegation as a scope-narrowing event. Write the rule down: an agent may never pass along more authority than the next step requires. Then build enforcement into the architecture rather than relying on convention. This is the basis for ‘continuous identity’ - never trust, always verify.
Audit for accountability across hops. If a multi-agent workflow does something wrong, can you reconstruct which human authorized it, what they authorized, and where in the chain the scope drifted? If the answer is no, your logging is describing tokens when it should be describing intent.
Separate the platform question from the pattern question. Pick the architectural model you need first, human-provable authority carried across every hop, then evaluate whether and how each platform supports it.
The takeaway
Agentic workflows are going to make a lot of things faster, including the ways your authorization model can fail. The teams who come out ahead are the ones treating identity-chained authorization as an architecture decision they make deliberately, before the first production agent calls the second one.
Across a large portfolio of enterprise identity engagements, the failures we get called in to fix consistently originate at the seams, the handoffs between systems where identity context was supposed to travel and quietly didn't. Multi-agent workflows are seams all the way down.
If your team is starting to sketch agentic workflows and you want an independent read on whether your authorization model holds up across the chain, book a CIAM maturity assessment. Bring your messiest hypothetical agent-to-agent flow. That's the one worth stress-checking now.
When your agent calls another agent, the authorization model has to be able to answer who authorized the action and within what bounds. If that answer isn't clear yet, that is the scope item to prioritize.
— Nate Szytel, CEO, Next Reason