サービス プロバイダーの認証エージェントは多くの顧客に対して機能しますが、各操作には 1 つの検証済みの顧客コンテキストが必要です。プロンプト内の顧客名は、アクセス制御の決定ではありません。信頼できるアプリケーションによって識別されたテナントにセッションとジョブをバインドし、その ID を取得、提案、承認、実行、証拠の保管を通じて伝達します。
顧客の境界線を確立する
オンボーディング中に、承認されたドメイン インベントリと、要求されたサービスに対する顧客管理者の権限を取得します。類似した表示名に依存するのではなく、安定した一意のテナント ID を記録します。アクセスを許可する前に、 DNSゾーンとレポートの宛先が意図したスコープに属していることを確認してください。
顧客範囲の認証情報、または同様に強制可能なダウンストリーム承認メカニズムを使用します。広範囲にアクセスできる中央サービス ID には、リソースの検索ごとに堅牢なチェックが必要です。 OWASP では、一般的な特権 ID が関連するユーザー コンテキストを超えてリソースにアクセスするリスクについて説明しています。 OWASP LLM06.
証拠を分けて保管する
テナント スコープをレポート ストレージ、検索インデックス、キャッシュ、会話コンテキスト、エクスポート ファイルに適用します。証拠がモデルに到達する前に取得を制限します。別の顧客の資料を最終的な回答から除外しても、すでに作業コンテキストに入っている場合は手遅れです。ログにもアクセス制御が必要です。デバッグ ダッシュボードを共有すると、慎重に分離できなくなる可能性があります。
2 人の顧客が共有する IP またはプロバイダー名は、プライベート証拠に参加する許可にはなりません。公共インフラに関する事実を、顧客固有のアカウント所有権、サービス活動、連絡先とは別に記録します。類似のドメイン サフィックスまたは共通のリセラーは、2 つのテナントを 1 つの承認境界にしません。
取り消された付与全体でキューに入れられたジョブを追跡する
顧客 A の有効な許可に基づいてジョブが作成され、アクセス管理者が実行前にその許可を取り消したとします。実行者は、以前のセッションに依存するのではなく、現在の権限を再確認する必要があります。キャッシュに同じ短縮名で顧客 B のレコードも含まれている場合、ルックアップのスコープは A のままでなければなりません。共有インフラストラクチャや同様の名前は、B の個人的な証拠を取得することを正当化することはできません。
これらは仮想の境界ケースであり、テストされたコネクタや提供された Runbook ではありません。スコープの承認、運用変更、独立したアクセスレビュー、オフボーディングに対して明確な責任を割り当てます。許可される A リクエストと拒否される B リクエスト、キューに入れられたジョブの取り消し、および適切な範囲のキャッシュ取得など、実際のデプロイメントの測定可能な受け入れ条件を定義します。関連するパスが実際にテストされるまでは、テナント間エクスポージャがゼロであると主張しないでください。
ジョブとセッションを確認する
承認をテナントにバインドし、実行時に同じ ID を検証します。自由記述の顧客名からどの資格情報を使用するかをモデルに選択させないでください。キューに入れられたジョブが実行されるときに認可を再確認します。ジョブの作成後に付与が取り消された可能性があります。期限切れまたは譲渡された顧客関係には、アクセスを継承するのではなく、明示的な処理が必要です。
意図的に類似した顧客名、重複するプロバイダー IP、再利用されたレコード名、および別のテナントからのキャッシュされた回答を使用してテストします。グローバルに無効になっているコネクタではなく、範囲指定されたアクセスをテストで証明できるように、許可された顧客 (読み取り) を含めます。上記の仮説的な例では、これらの展開テストは実行されません。実際のリクエストコンテキスト、認可決定、および観察された効果を評価するときに保持します。
関係をきれいに終わらせる
オフボーディングでは、新しい作業を停止し、アクセスを取り消し、キューに入れられたジョブを処理し、合意された証拠保持プロセスを適用する必要があります。責任あるシステムを通じて各アクションを確認します。該当する契約に基づく以前の作業を説明するために必要な最小限の監査履歴を保持します。エージェントが後の質問に答える必要があるからといって、証拠を自動的に消去したり、無期限にアクセスし続けたりしないでください。