CIBA adds human approval to agent actions beyond the browser

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: CIBA lets agents pause for human approval on sensitive actions such as refunds, deletions, or infrastructure changes without killing the workflow.

Why it matters: It matters because IAM teams now have to govern approval outside the browser session, where agent actions can outlive the interactive consent model that traditional OAuth assumes.

Context

CIBA addresses a simple governance gap: an agent can be authorised to act, but not every action in that session should be pre-approved. Traditional browser-based consent breaks when the requester is an asynchronous agent running in the background, because the human may not be present when the sensitive action is triggered.

The article frames CIBA as an OAuth 2.0 extension that decouples the requesting entity from the authenticating entity. For identity teams, the point is not the protocol name but the control shift: approval becomes a separate event, bound to a specific action, time window, and user identity.

That makes the article directly relevant to agentic AI identity and authorisation design, especially where human approval must be preserved without forcing agents into brittle session-based workflows.

Key questions

Q: How should teams handle human approval for agent actions that happen outside a browser session?

A: Treat approval as a protocol-level authorisation event, not a UI prompt. The agent should request approval through a backchannel, the human should respond on a separate device or channel, and the resulting token should be scoped to one specific action. That keeps asynchronous execution governable without assuming the user is present at the moment of impact.

Q: Why is approval-bound to a specific agent action safer than broad consent?

A: Because broad consent assumes the future action is already known and acceptable, which is rarely true for sensitive operations. Action-bound approval ties the human decision to one request, one time window, and one identity context, so the token cannot be reused as standing permission for a different task.

Q: What are the signs that an agent approval flow is too weak?

A: If users are approving vague prompts, if the approval text does not match the actual operation, or if the same token can be reused across unrelated actions, the control is too weak. A good flow makes the action obvious, limits the token to that action, and records approval or denial as a final state.

Q: Should organisations separate agent permission checks from human approval checks?

A: Yes. Base permission checks decide whether the agent is allowed to attempt the action at all, while human approval decides whether a sensitive but permitted action should proceed. Mixing those layers creates false trust and makes it harder to explain why an action was allowed, denied, or expired.

Technical breakdown

How CIBA decouples agent requests from human authentication

Client-Initiated Backchannel Authentication moves approval out of the browser and into a backchannel exchange. The agent sends an authentication request to the authorization server, the server notifies the user on another device or channel, and the agent later receives a token if the user approves. This separates action initiation from human authentication, which is the core reason it works for asynchronous agents, scheduled tasks, and multi-step pipelines. The protocol still uses OAuth concepts such as scopes, clients, and access tokens, but it changes when and where the human decision happens. Practical implication: build approval as a protocol event, not as a browser redirect.

Practical implication: design agent approval flows around out-of-band authentication, not interactive sessions.

Why binding messages matter more than approval prompts

CIBA only stays governable if the user sees exactly what the agent wants to do. That is why the binding_message is central: it binds the approval to a specific action, such as refunding an order or terminating an instance, rather than to a vague scope string. This reduces the risk of consent confusion, where the human approves something broad without understanding the consequence. In identity terms, the binding message becomes the transaction context that makes the approval intelligible and auditable. Practical implication: treat the binding message as a control surface, not a UI label.

Practical implication: require action-specific approval text that maps to the exact operation being authorised.

How CIBA response modes affect control design

The three response modes change operational trade-offs, not the authorisation model itself. Poll mode is simplest but keeps the agent waiting; ping mode uses a callback notification and then a token request; push mode delivers the token directly to the callback endpoint. For long-running agent tasks, response mode determines latency, infrastructure dependence, and how much orchestration you need around the approval step. The governance question is not which mode is newest, but which mode preserves traceability without creating brittle approvals or excessive callback exposure. Practical implication: choose the response mode that matches the agent's execution pattern and audit needs.

Practical implication: align the approval transport with the agent's runtime pattern and audit requirements.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Event-scoped approval is the real control boundary for asynchronous agents. Browser-based consent assumes the user and the request live in the same session. That assumption fails when an agent acts later, elsewhere, or on its own schedule. The practical result is that approval has to move from session consent to task-bound authorisation, where the decision is tied to one action and one identity context.

The standing-permission model is too coarse for agentic execution. The article shows why broad consent such as "manage my calendar" or "handle support tickets" cannot safely cover destructive follow-on actions. That is a governance problem, not a UX gap. The field needs tighter event scoping because agent intent can change after initial authorisation has already been granted.

Action binding is the named concept this pattern introduces. CIBA makes approval meaningful only when the request, the identity, and the resulting token are all bound to the same transaction context. Without that binding, approval collapses into a generic permission grant. Practitioners should treat this as a control requirement for agentic authorisation, not an implementation detail.

Agentic approval workflows need auditability at the point of decision, not just at the point of execution. The article's emphasis on denials, expiries, and scoped tokens shows that the governance record is created when the human says yes or no. That changes how identity teams think about non-repudiation, escalation, and post-event review for autonomous workflows. Practitioners should make the approval event itself the primary audit object.

CIBA is a protocol answer to a lifecycle problem in agent governance. Agents do not just need credentials; they need decision checkpoints that survive asynchronous execution. That places CIBA alongside identity lifecycle and authorisation governance, not as a niche application feature. Practitioners should use it where human sign-off must remain attached to a live agent action.

From our research library:

• 40 percent of financial and software companies have already deployed agentic AI systems, and deployments are expected to double by 2028.
• Read next: AI Agent Authorisation Guide

What this signals

Action binding is the governance shift CIBA brings to agentic systems. Approval is no longer a browser event; it becomes a discrete authorisation decision attached to a named action, a named user, and a bounded token. That matters because asynchronous agents can move faster than human review cycles, so the control has to live at issuance time rather than at use time.

The practical programme implication is that IAM teams should stop thinking of approval as a front-end confirmation pattern. Instead, they need a policy layer that decides which agent actions require human sign-off, how the request is described, and how expiry, denial, and audit events are handled across the orchestration stack.

For practitioners

• Define approval-worthy agent actions Classify which tool calls require human sign-off before execution, using risk thresholds for destructive, financial, or externally visible actions.
• Bind approval to a specific transaction Write binding messages that name the exact action, object, and consequence so the approver can understand what is being authorised without context.
• Treat expiry as a control state Log expired requests with agent ID, user ID, action context, and requested expiry, then surface the outcome to the orchestrating system instead of retrying automatically.
• Separate permission checks from approval checks Keep the agent's base permission boundary distinct from the human approval gate so CIBA only runs for actions already within the agent's allowed scope.

Key takeaways

• CIBA turns human approval into a backchannel authorisation event, which is better suited to asynchronous AI agents than browser-based consent.
• The article shows that the real control boundary is action-specific approval, not broad session consent, because agents often act after the user has left the original interaction.
• For practitioners, the key design choice is whether approval logic sits in the agent dispatch layer and produces a scoped, auditable token for one sensitive operation.

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.
• Auth Request ID: A temporary identifier returned by the authorization server after a backchannel request. It lets the agent poll or continue the approval exchange without re-sending the full request, and it is central to tracking whether the user approved, denied, or ignored the action.
• Shared Access Token: A shared access token is a short-lived credential that is passed from one identity to another instead of being used only by the original authorized user or system. In S3, this is dangerous because it can enable unintended access within the token’s lifetime while leaving the bucket configuration unchanged.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.