By NHI Mgmt Group Editorial TeamPublished 2026-05-18Domain: Agentic AI & NHIsSource: WorkOS

TL;DR: CIBA gives AI agents a protocol for requesting human approval outside the browser session, so sensitive actions such as refunds, deletions, or infrastructure changes can pause and resume safely, according to WorkOS. The core issue is not UX but governance: approval must be bound to a specific action, not a standing permission model.


At a glance

What this is: This is a developer guide to Client-Initiated Backchannel Authentication for async AI agents, showing how it binds human approval to a specific action when the user is not in the same session.

Why it matters: It matters because IAM teams now have to govern approval flows for autonomous and semi-autonomous actions, not just login events, across NHI, agentic AI, and human identity programmes.

👉 Read WorkOS's guide to adding human approval to async AI agent actions


Context

AI agent governance fails when teams assume the approving human is present in the same session as the actor. In async workflows, the agent may decide to send, delete, refund, or terminate long after the original user interaction has ended, so browser-based consent breaks as an identity control model.

Client-Initiated Backchannel Authentication, or CIBA, moves approval out of the browser and into a separate channel tied to a specific request. For IAM practitioners, that makes the approval step part of identity and access design, not a user interface exception. The article is a developer guide, but the underlying issue is governance for agent-triggered sensitive actions.

The article's starting point is typical of real agent deployments: coarse initial consent, then a later need for explicit approval on an irreversible action. That is exactly where most current control models get thin.


Key questions

Q: How should security teams handle approval for sensitive AI agent actions that happen asynchronously?

A: Security teams should place approval in a separate authentication step that is bound to the exact action, not to the agent's general session. The approval should flow through a human-readable request, a scoped token, and a clear audit record. That keeps the control tied to the decision being made rather than to the browser session that started it.

Q: Why do agentic workflows need a protocol for human approval instead of a simple prompt?

A: Because prompts can be bypassed by workflow timing, background execution, or a missing browser session. A protocol forces the approval decision into the identity layer, where the system cannot proceed without a valid response. That makes the control enforceable across async tasks, multi-step pipelines, and out-of-band user devices.

Q: What do security teams get wrong about coarse consent for AI agents?

A: They often treat broad initial consent as if it covered every later action in the class of work. In practice, an agent allowed to manage a calendar or support queue still needs a separate decision for destructive or high-value actions. Coarse consent is a starting boundary, not proof of per-action authority.

Q: Who should own approval policy for autonomous agent actions, IAM or application teams?

A: Both, but IAM should own the identity and token rules while application teams define which actions are risky enough to require approval. The boundary belongs in the dispatch and authorization flow, not in the UI. That split keeps policy consistent while still letting product teams define operational thresholds.


Technical breakdown

Backchannel approval in OAuth 2.0

CIBA, defined in RFC 9126, separates the system requesting authorization from the device where the user authenticates. The client sends a backchannel request to the authorization server with a login hint, scope, binding message, and expiry. The user receives a notification on a separate device or channel, approves or denies, and the client later receives a token or an error. This matters because the sensitive action is not approved in-session. It is approved asynchronously, with a specific request context preserved across the gap.

Practical implication: treat backchannel approval as an identity transaction and log the approval context, not just the token issuance.

Polling, ping, and push response modes

CIBA supports three response patterns. Poll mode has the agent repeatedly check the token endpoint. Ping mode lets the authorization server notify a callback when the user responds. Push mode sends the token directly to the callback endpoint. These are not just implementation choices. They shape latency, infrastructure exposure, and how long the agent waits for a human decision. In agentic systems, the response mode has to fit the workflow's tolerance for delay and retry behaviour.

Practical implication: choose the least complex mode that still fits the agent's timing needs and audit requirements.

Binding messages and scoped approval

The binding_message is the user-facing statement that explains exactly what the agent wants to do. That message should read like a transaction confirmation, not a scope label, because the human must approve the action, not translate protocol jargon. The returned token is scoped to the request and should be treated as single-use for that action. This is where CIBA differs from broad session consent. It narrows approval to one decision, one actor, and one action path.

Practical implication: standardise human-readable binding messages for every sensitive agent action and tie them to the action itself.


Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

CIBA is not an agent control by itself, it is a human approval binding mechanism for async identity flows. The protocol sits above the agent's normal permission checks and adds a second decision gate when the action is high-risk, irreversible, or unusual. That makes it useful for governance, but only if teams understand that it does not replace authorization at the tool layer. Practitioners should treat CIBA as a transaction-level approval pattern, not a general policy engine.

The naming point here is approval-decoupled action control. The user who authorises an action is no longer the user who is sitting in the same browser session as the actor. That breaks a familiar identity assumption: approval can no longer be inferred from interactive presence. The implication is that access governance for agentic systems must account for asynchronous, out-of-band sign-off, because the decision can arrive after the initiating session has disappeared.

Existing consent models are too coarse for autonomous or semi-autonomous actions. Broad consent such as 'manage my calendar' or 'handle support tickets' does not establish per-action authority for deleting, refunding, or terminating. CIBA narrows the trust boundary to a specific request, which is why it maps well to high-impact agent behaviour. Practitioners should stop treating initial session consent as equivalent to operational approval.

The control value of CIBA depends on the quality of the risk decision that triggers it. The article places that decision in the tool-dispatch layer, which means the real governance question is not whether CIBA exists, but which actions are routed into it. If the risk threshold is too low, the workflow becomes unusable. If it is too high, irreversible actions slip through. IAM teams should view this as a policy-design problem, not a notification problem.

Async approval creates an audit boundary that identity teams can actually use. The approval event, the binding message, the requester, and the final token issuance all become part of one traceable decision. That is a stronger governance primitive than a generic prompt because it ties human judgment to a named action. For practitioners, the opportunity is to make agent approvals reviewable as identity events, not as application logs.

From our research:

  • 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
  • Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
  • For a broader view of the governance model, see Ultimate Guide to NHIs for how lifecycle and access controls apply across machine identities.

What this signals

Approval-decoupled action control is emerging as the missing governance layer for async agents. Teams that still rely on browser-based consent are effectively assuming the human is present at the moment of execution, which is no longer true for background agents and multi-step workflows. The practical shift is toward request-bound approvals, scoped tokens, and identity-grade audit trails.

With 80% of organisations already reporting that AI agents have acted beyond their intended scope in our AI Agents: The New Attack Surface report, the issue is no longer theoretical. CIBA-style flows make sense only when the approval trigger is aligned to risk, not to every tool call. That is where policy design and operational tolerance have to meet.

Practitioners should align async approval workflows with established identity and zero trust patterns, then measure whether approvals are actually blocking irreversible actions before they execute. The right test is not whether a prompt appears, but whether the system can continue without a valid human response on a separate device.


For practitioners

  • Map high-risk agent actions to a separate approval gate Define which tool calls always require human sign-off, such as refunds, deletions, external sends, and infrastructure changes. Put the decision in the agent's tool-dispatch layer before execution, so approval is enforced as part of authorization rather than as a UI prompt.
  • Standardise binding messages for every sensitive request Write approval text as a plain transaction statement that names the action, the target, and the consequence. Avoid scope strings and jargon, because the user must be able to approve or deny without interpreting protocol terminology.
  • Choose a response mode that fits the workflow Use poll mode only when latency and infrastructure simplicity matter more than efficiency, and prefer ping mode when the agent needs a callback without repeated polling. Reserve push mode for environments that can support the extra callback infrastructure and operational overhead.
  • Log approval as an identity event Capture agent ID, user ID, action requested, binding message, approval or denial, timestamp, and outcome. Treat expired requests as a separate state and do not auto-retry a stale approval request after the context has changed.

Key takeaways

  • Async AI agents need approval controls that survive the loss of the browser session, or sensitive actions will continue without meaningful human oversight.
  • CIBA works as a transaction-bound approval pattern, not a general-purpose authorization model, and that distinction is what makes it useful for agentic systems.
  • IAM teams should govern which actions trigger human approval, while application teams define the risk thresholds that decide when the backchannel flow activates.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10CIBA is used to constrain sensitive agent actions before execution.
NIST CSF 2.0PR.AC-4Approval gating supports least-privilege access decisions for agent actions.
NIST Zero Trust (SP 800-207)AC-6Zero Trust requires continuous authorization, not one-time session consent.

Require per-action verification for sensitive agent operations instead of relying on initial login consent.


Key terms

  • Client-Initiated Backchannel Authentication: A protocol that lets a client request user authentication through a backchannel instead of a browser redirect. In agentic systems, it is used to pause a workflow, obtain a human decision on a separate device, and then continue only if the authorization server returns a valid result.
  • Binding Message: The human-readable text shown to a user when an approval is requested. It explains the exact action the agent wants to perform, so the person is approving a concrete transaction rather than a vague permission scope. In practice, it is the key artefact that makes asynchronous approval understandable.
  • Async Approval Gate: A governance checkpoint that requires a human decision after an agent has already started working but before it can complete a sensitive action. It separates the decision to proceed from the execution itself, which is essential when the user and the agent are not in the same live session.
  • Scoped Approval Token: A token issued after a successful approval that is limited to the exact action or request that was authorised. For agentic workflows, the token should be treated as single-use and action-bound so that approval does not become a standing permission for other operations.

Deepen your knowledge

CIBA for agentic systems and human-in-the-loop approval design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for async agents and sensitive actions, it is worth exploring.

This post draws on content published by WorkOS: How to add human approval to async AI agent actions. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-05-18.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org