Auth0 for AI Agentsの「非同期認可」の機能で、AIの「勝手な行動」を防ぐ承認フローが組めるぞ
はじめに
本記事は SaaSで加速するゲーム開発 - Advent Calendar 2025 - の 21 日目のブログです。
前回あらすじ
前回は、2025年11月にGAとなった Auth0 for AI Agents を使い、「AIが参照できるデータをユーザーの権限範囲に留める（Readの制御）」検証を行いました。
しかし、AIエージェントで実行したいのは「データの参照」だけではありません。 APIを叩いて商品を注文したり、会議室を予約したり、送金をしたりと、AIに「アクション」を実行してもらいたい場面も多々あります。
ここで、「もしAIがハルシネーションを起こして、勝手に100個の商品を注文したら？」 「ユーザーの曖昧な指示を勘違いして、重要なデータを削除したら？」という課題が生じます。
今回は、そのようなAIの「やり過ぎ」を未然に防ぐための機能、Auth0 for AI agentのAsynchronous Authorization（非同期認可）について、アーキテクチャの観点から解説します。
検証シナリオ
ユーザーがチャットで「スニーカーを買って」と指示したとき、AIが即座に決済APIを叩くのではなく、一度ユーザーのスマホに通知を飛ばし、「以下の内容で注文して良いですか？」と承認を求めるフローを構築します。
この裏側では、CIBAというプロトコルが動いています。
CIBAとは？
CIBA（シーバ）の正式名称は Client-Initiated Backchannel Authentication です。
一言で言うと、「操作しているデバイス（PCなど）とは別のデバイス（スマホなど）で、本人確認や承認を行う仕組み」のことです。
CIBAは、AIのために作られた新しい技術ではありません。
OIDCの拡張仕様として策定され、金融業界やコールセンターなどで利用されてきた技術です。
例えば、コールセンターのオペレーターが、電話口の顧客（承認者）のスマホに「本人確認通知」を送る。
もしくは、画面のないスマートスピーカーが、持ち主のスマホ（承認者）に「決済承認」を送る。
このように「操作する主体」と「承認する主体/デバイス」が分離しているケースで使われてきました。
処理の全体像（シーケンス）
今回の検証で構築するフローをシーケンス図にしました。
AIが勝手にAPIを叩くのではなく、必ず人間の承認を経由しないとアクセストークンが発行されない流れになっています。
実装のポイント
公式のチュートリアルに従って実装します。
このフローを実現するための核となるのが、Auth0 AI SDKが提供する bindingMessage です。
AIエージェント（今回はLangGraphを使用）のツール定義を withAsyncAuthorization でラップすることで、この承認フローを強制的に組み込めます。
// src/lib/auth0-ai.ts
export const withAsyncAuthorization = auth0AI.withAsyncAuthorization({
// 承認を求める対象のユーザーID（現在会話しているユーザー）
userID: async (_params, config) => {
return config.configurable?.langgraph_auth_user?.sub;
},
// スマホの通知画面に表示するメッセージ
// AIがツールに渡そうとしている引数（product, qty）に埋め込める
bindingMessage: async ({ product, qty }) =>
`Do you want to buy ${qty} ${product}?`,
// 必要なスコープ（API実行用）
scopes: ["openid", "product:buy"],
audience: process.env["SHOP_API_AUDIENCE"]!, // Auth0で作成したAPIのIdentifier
});
このラッパー関数を、AIが使用するツール（shopOnlineTool）に適用します。
// エージェント側のツール定義
const tools = [
withAsyncAuthorization(shopOnlineTool),
];
この実装で、ツールが呼ばれる直前にCIBAフローが走り、承認が得られるまで実行がブロックされるようになります。
なぜこれが重要なのか？
想定される事故シナリオ
もしユーザーが少し曖昧に「靴を買っておいて」とだけ指示したとします。
AIが勝手に気を利かせて「高級スニーカーを10足買う」と判断してしまった場合、非常に困ります。
しかし、この実装が入っていれば、ユーザーの手元のスマホには、以下のような通知が届きます。
Do you want to buy 10 Luxury Sneakers?
[承認 (Allow)] [拒否(Deny)]
ここでユーザーは、「10足はいかん！」と気づき、[拒否] ボタンを押すことで事故を未然に防ぐことができます。
もしこれが単なる「承認しますか？」だけの通知だったら、ユーザーは流れ作業で承認してしまい、誤発注が発生するかも知れません。
AIが生成したパラメータ（個数や商品名）を、改ざん不可能な別経路（バックチャネル）で人間に提示する。
この仕組み（Binding Message）こそが、実務でAIエージェントを使う上での大事になると感じました。
最後に
前回と今回で、Auth0 for AI Agentsの2つの主要機能を見てきました。
- Readの制御: Token Exchangeにより、AIは「そのユーザーが見て良いデータ」しか参照できなくなる。
- Writeの制御: CIBAにより、AIは「人間が承認したアクション」しか実行できなくなる。
AIエージェントを利用するアプリを実装する際、特有の気をつけるべきことがあると理解できました。
以上です。
