CIBA for AI agents exposes the limits of CLI auth flows

At a glance

What this is: This is a tutorial on using CIBA with Claude Code hooks and an MCP server so an AI agent can pause, request human approval out of band, and then retry a protected tool with a valid token.

Why it matters: It matters because agentic workflows break browser-based auth assumptions, and IAM teams need a clean approval pattern that keeps credentials out of the agent context while preserving enforceable scope checks.

👉 Read Descope's tutorial on CIBA for AI agents with Claude Code hooks

Context

AI agent identity becomes hard to govern when the approval moment is separated from the execution loop. Traditional browser redirects assume a human is sitting in front of the same session, but CLI agents and tool-calling workflows need a different trust boundary for consent, token issuance, and replay.

In this article, Descope uses CIBA to decouple initiation from approval so a Claude Code agent can request access to a protected tool without ever seeing the credential itself. For IAM, PAM, and NHI teams, the real issue is not whether the agent can call a tool, but whether the approval chain is explicit, auditable, and bound to the requested scope.

Key questions

Q: How should security teams govern AI systems that can act without human approval?

A: Security teams should govern autonomous AI the same way they govern other high-risk identities, but with runtime enforcement instead of periodic review. That means tightly scoping tools, data, and actions; logging every material step; and making revocation and containment available while the session is still active. Static policy alone does not control machine-paced execution.

Q: Why do browser-based login flows fail for CLI AI agents?

A: Browser redirects assume the user and the application share the same interactive session, which is not true for CLI agents or background tool execution. A backchannel flow solves that mismatch by moving approval out of band while preserving token issuance, scope enforcement, and a replayable execution path.

Q: What do teams get wrong when they treat agent hooks as the control layer?

A: They often assume the hook itself is the security boundary. In practice, the hook is only an orchestration point. Real control still depends on server-side token validation, scope checks, approval logging, and rate limits on how often the agent can request authorisation.

Q: How do you know whether CIBA is actually reducing agent risk?

A: Look for evidence that sensitive tool calls cannot execute without an explicit approval record, that the agent never sees reusable credentials, and that scope checks happen on every retry. If approval is optional, vague, or bypassable through alternate client paths, the control is not doing its job.

Technical breakdown

How CIBA separates approval from agent execution

Client-Initiated Backchannel Authentication moves the user approval step away from the agent session. The agent starts an authentication request, the authorization server sends a notification to the user, and the user approves on a separate device. The agent then polls for the token and continues only after approval. This is useful for CLI and tool-based agents because it avoids browser redirects and keeps credentials out of the agent context. The important design point is that the approval event is not embedded in the agent’s local runtime.

Practical implication: keep approval and token issuance on a separate trust boundary so the agent never handles the credential directly.

Why MCP tools need a structured auth-required signal

The pattern in the article uses a protected MCP server that returns a structured signal when no token is present, rather than executing the tool. That signal tells the hook to initiate CIBA, then replay the same tool call with the approved token. This matters because the enforcement point remains the resource server, not the agent. Scopes, audience, token validation, and replay all happen server-side, which is what prevents the workflow from becoming a prompt-only control.

Practical implication: make the resource server the policy enforcement point and treat the agent hook only as the orchestration layer.

Where Claude Code hooks sit in the control path

Claude Code hooks fire after a tool call and can inspect the tool output before the agent acts on it. In this pattern, the PostToolUse hook intercepts the CIBA-required response, initiates the backchannel flow, polls until approval, and injects the resulting token into the retry. That means the hook is effectively a control adapter between agent behaviour and identity policy. The approach works because the agent loop remains intact while the auth decision is externalised.

Practical implication: use hooks to mediate agent behaviour, but keep approval logic and token validation outside the model runtime.

NHI Mgmt Group analysis

CIBA is a useful control pattern, but it does not remove the core identity problem for agents. It only proves that an agent can request approval without carrying a browser session or secret in context. The underlying governance challenge remains scope, ownership, and replay control for a tool-using identity that can invoke actions repeatedly across a session. Practitioners should treat CIBA as a consent mechanism, not as a complete agent identity model.

Human-paced approval flows remain the wrong default for agentic execution. This article shows why CLI and MCP-based agents need decoupled authentication, because the execution loop is not browser-native. The broader lesson is that IAM controls built around synchronous login assumptions do not map cleanly to autonomous tool invocation. Security teams need to distinguish between approval for a single sensitive action and durable authorisation for an ongoing agent session.

Explicit binding messages are the right accountability primitive for agent actions. A user needs to understand what the agent is asking to do, in plain language, before granting approval. That creates an audit trail and a decision record, which is more valuable than a generic login event in agentic workflows. For identity governance, the message attached to the approval request becomes part of the control evidence.

Policy enforcement at the authorisation server is more durable than client-side orchestration. The article’s own limitation is that hook-based handling depends on a controlled client path. The stronger pattern is to govern CIBA initiation, polling, and scope frequency at the authorization layer so agent behaviour cannot outpace policy. That is the direction IAM teams should expect as agentic identity matures.

Agentic identity governance needs a named concept: out-of-band approval binding. The value here is not just human approval, but approval that is linked to a specific requested action, scope, and actor in a separate channel. That binding is what makes the event auditable and reviewable. Practitioners should look for identity controls that preserve that binding across tool retries, delegated execution, and session replay.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, 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 control model, see OWASP Top 10 for Agentic Applications 2026 for the security patterns that CIBA alone does not address.

What this signals

Out-of-band approval binding: the control value here is not just consent, but consent tied to a specific tool request, scope, and actor identity. That makes review and investigation possible when a later event needs to be reconstructed across the agent loop and the authorization server.

Agent teams should expect approval friction to become a governance design variable, not a user-experience afterthought. If too many actions require human sign-off, practitioners will push work around the control; if too few do, the approval step becomes ceremonial. The programme challenge is to set thresholds that reflect actual data and action sensitivity.

For identity programmes already thinking about agentic AI governance, this pattern fits alongside NIST AI Risk Management Framework because the real issue is not model output alone, but the authorisation logic wrapped around it.

For practitioners

• Define an approval boundary for sensitive agent actions Classify which tool calls require out-of-band human approval, then separate those from low-risk agent actions so the agent does not request consent for every routine operation.
• Enforce scope validation at the resource server Validate token audience and scope server-side before any protected tool executes, and reject fabricated or replayed tokens even if the agent retries the call.
• Use binding messages that name the exact action Include a human-readable statement of what the agent is requesting, such as the tool name and scope, so the approver can make a decision with clear context.
• Set policy limits on repeated CIBA initiation Throttle how often a client can trigger backchannel authentication, especially when many tools run in parallel or when retries create repeated approval requests.

Key takeaways

• CIBA helps agentic workflows request explicit approval without exposing reusable credentials, but it does not replace the need for strong server-side authorisation controls.
• The governance value is strongest when approval is tied to a specific action, a specific scope, and a clear audit trail that security teams can review later.
• IAM teams should treat hook-based orchestration as an integration pattern, not as the control boundary, and place enforcement where the token is validated.

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.
• Out-of-band approval: Out-of-band approval is a separate consent path for sensitive actions, often delivered through a channel outside the agent session. It is used when a headless or autonomous workflow needs human authorisation without handing the whole interaction back to a person.
• Remote MCP Server: A Remote MCP server exposes tools over a network so an AI client can discover and invoke them through a standard protocol. In security terms, it becomes part of the identity chain, because it brokers requests, handles authorization, and can expand the blast radius when its OAuth implementation is weak.
• 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.

What's in the full article

Descope's full tutorial covers the operational detail this post intentionally leaves for the source:

• Step-by-step Descope console configuration for MCP server resources, scopes, and discovery metadata
• Full Claude Code hook script that intercepts the CIBA-required response and replays the protected tool call
• Working Python examples for token validation, scope enforcement, and OAuth protected metadata routing
• Exact environment variables and local deployment steps for running the MCP server and hook together

👉 The full Descope post includes the working server code, hook logic, and configuration steps for the CIBA flow.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.