プロバイダーキーは、モデルのコンテキスト、ツール引数、ツール結果、URL、ブラウザーコード、ログの外に置きます。MCPサーバーは個別の上流認証情報を使い、モデルには認可済みのツール結果だけを渡します。
MCPのaccess tokenも保護する必要がありますが、プロバイダーtokenではありません。上流APIへそのまま渡すと、プロトコルが定義するaudience境界が壊れます。
認証情報が漏れる場所
プロンプトとコンテキスト
設定を診断するためにエージェントが.envを読み、その値を推論、生成コード、transcriptへ出力する場合があります。可能な限り、モデル向けファイルツールからsecret storeを読み取れないようにします。プロセスに認証情報が必要なら、モデルに取得させるのではなく、そのプロセスへ直接注入します。
ツールの引数と結果
上流APIをそのまま反映したツールがapiKeyを受け取ったり、認証情報やdebug headerを含むプロバイダーresponseを返したりする場合があります。シークレットフィールドをスキーマから完全に削除してください。サーバーは認証済みセッション状態から認証情報を解決します。
URL
query stringはaccess log、ブラウザー履歴、analytics、error report、screenshotに残ります。MCP認可仕様は、bearer access tokenをAuthorization headerに置くことを求め、URIのquery stringに含めることを禁止しています。
ログとトレース
HTTP middlewareが、アプリケーションのredact処理より先にheaderやbodyを記録する場合があります。error trackerは環境変数、subprocess command、ローカルファイルを取得する場合があります。収集境界でredactし、logger呼び出しだけでなくserialize済みイベントをテストします。
生成コードと成果物
.envがGitの対象外でも、エージェントが値をscript、fixture、notebook、screenshot、ビルド出力へハードコードする可能性があります。デプロイ前に、ビルド済みclient bundleと生成成果物から認証情報のprefixを検索してください。
AIエージェントのセキュリティガイドでは、MCP以外のシークレット処理も扱っています。
二つの認可境界を使う
flowchart LR
C[MCP client] -->|MCP access token| S[MCP server]
S -->|validated user and policy| P[Tool executor]
P -->|separate upstream credential| U[Provider API]
U -->|bounded result| P
P -->|redacted tool result| C
MCPサーバーは、access tokenが自身のaudience向けに発行されたことを検証します。続いて、代理対象のユーザーとツールアクションを認可します。executorは上流サービス向けの認証情報を使います。可能な場合は、上流APIでも最終リソースを認可します。
MCP仕様は、受信したMCP tokenを上流APIへ転送することを明示的に禁止しています。認証・認可ガイドでは、resource indicator、audience check、個別の下流認可を説明しています。
上流の認証情報をツールへ限定する
ツールに必要なアクションとリソースだけを操作できる認証情報を使います。読み取り専用の顧客検索をアカウント管理者キーで実行してはいけません。プロバイダーが適切なscopeを発行できない場合は、狭いserver-side proxyを前に置き、不足するルールをそこで強制します。
開発環境と本番環境には別の認証情報を使います。本番の認証情報をコーディングエージェントのworkspaceやtest fixtureへ含めないでください。
Cohesivityの認証情報をサーバー側に置く
Cohesivityは、テナント管理に使うmanagement keyと、プロビジョニング済みサービスに使うapplication keyを分けています。どちらもサーバー側のコードに置きます。上流プロバイダーの認証情報はCohesivity内に保持されます。
HTTPアプリケーションでは、offeringが対応していればapplication keyを短期edge session tokenへ交換し、そのtokenをサーバーのリクエスト経路に保持します。coh_*の値を公開環境変数やブラウザーリクエストへ含めないでください。
バックエンドのプロビジョニング手順では、フルセットアップ中のこの分離を紹介しています。
canaryでredactionをテストする
テスト環境で、認証情報と同じ形の偽canaryを使います。モデル入力、ツール実行、上流の失敗、再試行、logging、tracing、error reportingまでリクエストを通し、取得した全成果物からcanaryを検索します。
少なくとも次をテストします。
- requestとresponseのログ
- traceのattributeとevent
- error trackerのpayload
- モデルのtranscript
- 生成sourceとビルド出力
- shell historyとプロセスのcommand line
- test snapshotとfixture
このテストに実際の認証情報を使わないでください。
インシデント前にローテーションと取り消しを設計する
認証情報の所有者、scope、作成時刻、最終利用、ローテーション手順、取り消し経路を記録します。新旧の認証情報を併用するのは、デプロイに必要な期間だけにします。取り消しのために、人間のユーザーアカウントやorganization内の全連携を削除する必要があってはいけません。
以下のプロンプトは、値を表示せず、指定した認証情報をシステム全体で追跡します。