秘密ブローカーは、プロンプトに認証情報を露出させずにAIエージェントへどのように認証情報を渡すのか？
秘密のブローカーは、エージェントのワークロードを認証し、外部リクエストの境界でのみスコープを限定した認可情報を注入することで、認証情報をプロンプトから遠ざけます。
家庭用AIエージェントは、カレンダーの読み取りやバックアップのアップロードを必要とする場合があります。しかし、APIキーをプロンプト、メモリ、環境、またはツール出力に置くと、プロンプトインジェクションによってアクセス可能になります。ブローカーはワークロードのIDと承認済みのタスクコンテキストを検証し、有効期間の短い認証情報を取得して、管理されたプロキシまたはツールアダプター内に付加し、サービスの結果だけを返します。
ワークロードIDが静的キーの所持に取って代わる
エージェントは、承認済みのプロセス、コンテナ、サービスアカウント、または署名済みワークロードのどれがリクエストを実行しているのかを証明します。ブローカーは、生成コードやモデルコンテキストから読み取れる場所に保存されたベアラーキーを信頼するのではなく、そのIDをポリシーに対応付けます。
エージェントのワークロードIDに関する分析では、永続的な認証情報を保持すべきでないエージェントのための、アテステーションとマシン間認証について説明しています。IDの証明により、認可は会話上の主張ではなく、実行時のワークロードに基づくようになります。この違いは、後の家庭環境でのテストでも確認できます。
IDだけで、すべてのサービスへのアクセスが認められるわけではありません。ポリシーは引き続き、ワークロードをユーザー、宛先、操作、リソース範囲、時間枠に結び付けます。自動化を進める前に、中間結果を検証可能な状態に保つ必要があります。
ブローカーが範囲の狭い短期認証情報を発行または注入する
ポリシーの承認後、ブローカーはIDをスコープ付きトークンと交換するか、保護されたメモリ内で秘密情報を取得します。プロキシは、モデルが生成したパラメーターを検証した後、送信リクエストに認可ヘッダーを追加します。
短期のブローカー経由認証情報に関するセキュリティガイダンスでは、まず認証情報を一切与えず、特定のタスク用に短期トークンを提供するブローカーを利用することを推奨しています。これにより、漏洩後に利用できる操作だけでなく、露出期間も制限できます。この境界は、現実的な運用条件下で個別に測定する必要があります。
モデルに見えるのはツールスキーマとサニタイズ済みの応答であり、トークンではありません。ログ、エラー、トレース、コマンドライン、リトライでも認可情報を確実にマスキングしなければ、アーキテクチャは単に漏洩箇所を移しただけになります。複数のソースが限られたコンテキストを奪い合う場合に、この実際的な影響が現れます。
ポリシーと失効によって認証情報の悪用を制限する
宛先の許可リスト、メソッド制限、リソース識別子、ユーザー承認、レート制限、オーディエンスクレーム、有効期限、ワンタイムトークンによって、注入された権限の使用方法を制限します。ブローカーは、プロンプトやイメージを再構築せずに、今後の発行を取り消せます。
認証情報の注入境界に関する解説では、コンテキストウィンドウに入った秘密情報はすべて露出する可能性があるため、認証情報の処理をエージェントの外部に置くべきだと論じています。このパターンは、管理された認証済み呼び出しを維持しながら、開示リスクを低減します。この依存関係は、最終インターフェースでも明示しておく必要があります。
障害の境界となるのは、範囲が広すぎるブローカーのポリシーや、エージェントが任意に選んだリクエストに署名するプロキシです。隠された認証情報でも、プロンプトインジェクションを受けたエージェントが正当な権限を悪用することは防げないため、リクエストの意味と副作用についても引き続き検証が必要です。
1つの認証情報をIDから有効期限まで追跡する
各エージェントツールについて、ワークロードID、リクエスト元ユーザー、宛先、許可された操作、リソース範囲、承認状態、トークンのオーディエンス、有効期間、注入箇所、応答のマスキング、監査識別子、失効経路、フォールバック動作を文書化します。したがって、その結果を元の証拠と照合する必要があります。
エージェントツールの権限と制御を比較します。秘密情報を要求するプロンプト、環境のダンプ、リダイレクトされた宛先、有効期限後のリプレイ、拡大されたリソースID、エラーログ、ツールのリトライ、侵害されたサンドボックスプロセスをテストします。この違いは、後の家庭環境でのテストでも確認できます。
生の認証情報がモデルから見えるデータに一度も入らず、認可されていないリクエストの派生パターンがブローカーまたはプロキシで失敗する場合にのみ合格とします。トークンは短期に保ち、ポリシーはタスク固有にし、ログはマスキングし、不可逆な操作には独立して結び付けられた承認を要求します。自動化を進める前に、中間結果を検証可能な状態に保つ必要があります。
おすすめ商品
テック＆AIハブ
もっと読む
エンベディングドリフトとは何か、プライベート検索インデックスの再構築が必要になるのはいつか？
モデル、前処理、コーパス、クエリのドリフトを解読し、監視と非互換性を区別して、プライベートインデックスの再構築が必要なタイミングを判断します。
トークナイザーの互換性とは何か、なぜモデルの切り替えで問題が起きるのか？
ローカルモデル切り替えのために、語彙の同一性、特殊トークンのセマンティクス、チャットテンプレート、キャッシュ済みトークン、アダプター、互換性チェックを解読する。
モデル常駐とは何か、ローカルAIサービスはいつ重みをロードしたままにすべきか？
重みの常駐性、キャッシュレベル、コールドスタート、追い出し、マルチプレクシング、メモリプレッシャー、そして家庭用AIサービスをウォーム状態に保つべきタイミングを解説します。
