AI SECURITYAWS2026.11.03

AWS、AgentCoreからServiceNowへ利用者の権限を引き継ぐ手順を公開

Microsoft Entra IDのon-behalf-of交換をGatewayの接続先で設定します。要求ごとにトークンを交換し、ServiceNowが元の利用者の権限を適用する構成です。

ROOT AI EDITORIAL

ここがポイント

エージェント全体の共通権限で接続する際の監査上の課題を扱います。認証情報の対応付けと、許可されない操作が拒否されることの検証が焦点です。

代理実行でも利用者の身元を保つ

AWSは11月3日、Amazon Bedrock AgentCore GatewayからServiceNowを呼び出す構成を公開しました。企業のエージェントがAPIを使う際、接続先にアプリ自体の身元だけが伝わると、元の利用者の権限や監査記録が失われるおそれがあります。今回の手順は、Microsoft Entra IDのon-behalf-of方式でトークンを交換し、利用者の身元を下流へ引き継ぎます。交換処理はGatewayの接続先に設定します。利用者ごとのAPI呼び出しで自動的に交換するため、独自の中継処理を管理する負担を減らす構成です。新製品の一括発表ではなく、認証をつなぐ実装例です。

問い合わせを受けた人の範囲で記録を読む

構成は、エージェント、Gateway、ServiceNowのAPIを結びます。Gatewayは受け取ったトークンをEntraへ渡し、ServiceNow用のトークンを取得します。接続先では元の利用者を解決し、その人に認められた権限を適用します。公開例は障害記録の一覧を取得する道具です。OpenAPIの定義で対象のAPIを示し、呼び出せる操作を設定します。影響を受けるのは、社内の問い合わせ対応や業務システムへAIを接続する担当者と見られます。アプリに与えた広い権限で全員の処理を行う方式とは、監査で確認できる情報が変わる可能性があります。原文は、OAuthで保護された他のAPIにも適用できるパターンとしています。ただし、個々の接続先で必要な設定や権限まで同一とは限りません。

トークンの設定と拒否の動作を点検する

実装では、Entra側のアプリ登録とAPIの権限設定が必要です。ServiceNowでは、交換されたトークンの利用者情報が有効なユーザーへ対応するようにします。Gateway側のスコープと交換パラメーターも一致させます。原文は、on-behalf-ofを指定する設定が欠けると認証が失敗すると説明しています。導入側では、成功する呼び出しだけでなく、権限がない人の操作を拒否できるか確認することが論点です。監査記録が本人の行為として追えるかも検証対象になります。Guardrailsを入力や出力の確認に併用できますが、本人の身元を引き継ぐ認証の代わりにはなりません。試行で作った認証設定や接続先の片付けも含め、保守担当者を決める必要があると見られます。

接続先ごとの利用条件を残す

今回の手順は、独自のLambdaによるトークン交換を不要にする構成を示しています。交換を管理サービスへ移しても、接続先のユーザー設定や権限の管理は残ります。今後の判断点は、実際の社内APIで同じ身元の連鎖を確認できるかです。認証が通ることと、必要な操作だけを許可することを分けて評価する必要があります。利用者の異動や権限変更が起きた際の確認も、運用上の論点になると考えられます。接続後も権限の見直しを続ける体制が必要と見られます。

公式発表を読む