Notifications
Clear all
Topic starter
06/06/2026 1:36 am
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.
NHIMG editorial — based on content published by WorkOS: How to add human approval to async AI agent actions
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Standardise binding messages for every sensitive request Write approval text as a plain transaction statement that names the action, the target, and the consequence.
- 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.
What's in the full article
WorkOS's full guide covers the implementation detail this post intentionally leaves for the source:
- A step-by-step CIBA request flow with sample code for /bc-authorize and token polling.
- Implementation guidance for poll, ping, and push response modes in async agent workflows.
- Error handling for authorization_pending, slow_down, access_denied, and expired_token.
- User-facing binding message examples for approvals such as refunds, deletions, and infrastructure changes.
👉 Read WorkOS's guide to adding human approval to async AI agent actions →
CIBA for agentic systems: how do approvals work when agents run async?
Explore further
06/06/2026 2:50 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: CIBA adds human approval to agent actions beyond the browser
