The Agent Identity KeyAgent identity finder

Reviewed 3 November 2026

Human approval and CIBA

In short: human approval pauses a risky agent action until a named person confirms it on a separate device. CIBA is the OpenID standard for asking a user to approve asynchronously. For staff, a governance layer usually provides the approval step, with policy deciding which actions need a person.

What decision belongs with a person?

Human approval is a control for consequential actions, not a substitute for agent identity or authorization. First decide whether policy should allow, deny or ask.

Recommend approval for actions where human judgment matters, such as payments, deletions, production changes or external messages. Deny prohibited actions instead of offering an approval escape route.

NewCore documents this allow, ask and deny split. Its governance material also describes testing policies against recent sessions before putting them into operation.

Reserve prompts for meaningful decisions. A person should understand what will happen and why their judgment is needed before confirming.

How does CIBA relate to action approval?

CIBA means Client-Initiated Backchannel Authentication. The existing pattern describes it as an OpenID standard supporting asynchronous user interaction on another device.

Auth0 for AI Agents documents asynchronous authorization based on CIBA. That capability became generally available on 19 November 2025 and is positioned for customer-facing applications.

Distinguish the asynchronous interaction from the application decision it supports. Recommend checking how the approval is linked to the exact action your agent intends to execute.

A successful user interaction should not become blanket permission for unrelated tool calls. Require the application to enforce the approved scope when it resumes work.

Do not assume workforce approval requires CIBA, or that every approval product uses it. The reviewed governance products document different approval controls and deployment models.

What would a hypothetical approval flow look like?

Imagine a hypothetical support agent preparing an external message containing a proposed customer refund. Your policy permits drafting but requires a supervisor before sending.

The gateway evaluates the send request and returns an approval requirement. The message remains unsent while the supervisor reviews its recipient, content and refund details.

The supervisor confirms through a channel the agent cannot control. Recommend displaying the actual proposal rather than a generic request to approve the agent.

On approval, the application should verify that the pending action still matches the reviewed proposal. Changed recipients or amounts should trigger a new decision.

On rejection or expiry, recommend leaving the action blocked and recording the outcome. The agent may explain the result, but it should not manufacture an alternative approver.

This is a proposed design, not a vendor deployment claim. Validate channel separation, action binding and resumption behavior in your own integration.

Which products document relevant controls?

NewCore documents sending risky calls to a named approver in the NewCore App. The approver confirms with device biometrics, and agents cannot approve their own actions.

It also documents a single audit trail covering tool calls, sessions and approvals. Its gateway checks policy while the existing identity platform continues handling employee sign-in.

Silverfort documents an MCP Gateway with approve, block and step-up outcomes. Its material describes stepping up to a human before a tool call proceeds.

Descope documents a governance suite containing approval, documented purpose and an accountable owner. That suite is on the Enterprise plan, not the free hub tier.

Auth0 is the documented CIBA option for customer-facing asynchronous authorization in this comparison. Evaluate that application flow separately from workforce governance alongside an employee identity provider.

These descriptions establish documented capabilities, not equivalent approval semantics. Ask each supplier to demonstrate approver selection, rejection handling and evidence for your intended workflow.

Where do Okta and Entra fit?

Keep workforce sign-in separate from the decision to authorize a specific agent action. An agent governance layer can run alongside the existing identity provider.

The reviewed Okta general availability material lists human-in-the-loop controls as coming after GA. Treat that as a documented roadmap statement, not proof of current delivery.

The reviewed Entra Agent ID material documents sponsors and Conditional Access for agents. Per-action human approval was not found in that material.

An absence in reviewed documentation is not proof that Microsoft cannot support any approval workflow. Ask for current documentation covering the precise feature and integration you need.

Likewise, do not treat Auth0 asynchronous authorization as evidence that Okta Workforce already supplies identical action approval. Product context matters when interpreting related branding.

How should a team roll this out?

First, choose one consequential action and identify the person accountable for approving it. Define allowed, denied and approval-required cases before connecting the prompt.

Second, require the review screen to show the agent, requesting person when relevant, target, action and significant parameters. Recommend a clear explanation of the policy trigger.

Third, separate the approval channel from the agent session. Test that the agent cannot read confirmation secrets or invoke the approval endpoint as the human.

Fourth, define expiration, rejection, approver absence and service failure behavior. Recommend stopping the action rather than silently treating missing approval as consent.

Fifth, record the decision and execution outcome together. Review approval and rejection patterns, then adjust rules that create noise or consistently expose unsuitable agent behavior.

What should procurement and testing uncover?

Require vendors to demonstrate a changed proposal after approval, a repeated callback and an expired request. Ask which component prevents reuse of a previous confirmation.

Recommend checking whether approvals survive policy changes, agent revocation or lost user access. Specify when the application must reevaluate authority before execution.

Test direct tool access that bypasses the approval gateway. A trustworthy confirmation flow cannot protect an alternate route that still accepts standing credentials.

Finally, require exportable evidence linking the approver, proposal, decision and resulting tool call. Keep approval success distinct from execution success when reviewing incidents.

Questions buyers ask

Is CIBA mandatory for human approval?

No. Auth0 documents CIBA-based asynchronous authorization, while workforce governance products document other approval controls. Choose the interaction and enforcement model that fits your application.

Can the agent approve its own request?

It should not. NewCore explicitly documents preventing self-approval. Require other candidates to demonstrate equivalent separation rather than assuming a prompt provides it.

Does every risky request deserve a prompt?

No. Recommend denying prohibited actions outright and allowing routine permitted work. Use approval where a named person can make an informed, consequential decision.

Sources

NewCore: Govern; NewCore: Secure; NewCore: Identity foundation; Silverfort: AI agent security; Silverfort unveils AI agent security; Descope Agentic Identity Hub 3; Auth0 for AI Agents generally available; Okta for AI Agents general availability; Microsoft Entra Agent ID; What is Microsoft Entra Agent ID, read 2026-11-03

Which key results use this pattern?