Async Auth (CIBA) for Agents¶
Auth0's implementation of Client-Initiated Backchannel Authentication (CIBA, an OIDC spec) applied to the agent use case. Pillar 3 of auth-for-ai-four-pillars: AI can request my confirmation.
The problem¶
Autonomous agents run in the background. When they hit a risky operation — placing a stock order, sending money, deleting data, emailing at scale — they need explicit human approval, not just the ambient session token. But the user isn't at the keyboard; they may be asleep, in a meeting, on a plane.
Galan: "We don't want an hallucinating agent buying a stock in the middle of the night without my permission."
The flow¶
- Agent hits a pre-defined risky operation (developer decides which tools are risky — e.g.
place_order). - Agent calls Auth0's
backchannelAuthenticationSDK with the transaction details (symbol, quantity, price). - Auth0 sends a push notification to the user's Guardian MFA app (or email, with more channels coming).
- User sees structured transaction detail on their out-of-band device; approves or rejects.
- On approval, Auth0 issues an access token containing the exact transaction details the user approved.
- Agent resumes and executes, using the scoped token.
Rich Authorization Request (RAR)¶
The consent object is Rich Authorization Request — an OAuth spec extension letting Auth0 describe exactly what's being authorized (not just a generic "allow?"). Auth0 publishes a canonical schema so both the Guardian app and third-party approval UIs can render transaction detail reliably. The resource server can verify the access-token payload contains the approved detail.
Why this is an OAuth feature, not an LLM feature¶
The approval gate lives outside the LLM. The agent's tool wrapper (standard code) hits backchannelAuthentication before calling the actual place_order function. If the user declines, the tool never runs. The LLM cannot prompt-inject its way past this — the approval happens in the out-of-band device, not in the agent's context window.
This is the same pattern as capability-based-security: the dangerous operation isn't "available-but-gated"; it's literally unreachable until out-of-band approval mints a token with the right RAR payload.
Cross-references¶
- auth-for-ai-four-pillars — parent framework
- token-vault — pillar 2 sibling
- agent-as-oauth-client — the model this rides on top of
- verifiable-systems-for-agents — parallel approach to bounding agent action