MCPのAPIキー管理：発行・スコープ・ローテーション・失効の運用手順【MCPセキュリティ実践編・2026】

最終更新：2026年10月14日／対象：MCP仕様 2026-07-28版（Authorization、Authorization Security Considerations）、OWASP MCP Top 10（2025年版・ベータ）、OWASP Secrets Management Cheat Sheet

結論（30秒で読める要約）

MCPのAPIキー管理とは、リモートMCPサーバーを呼び出すための資格情報を「発行・スコープ設定・保管・ローテーション・失効・監視」まで一貫して管理することです。MCPセキュリティの中でも、実際の事故につながりやすいのがこの部分です。トークンは長く使われ、設定ファイルにコピーされ、ほとんど交換されないからです。

要点は6つです。

呼び出し元ごとに資格情報の種類を選ぶ。人が自分のIDで使うならOAuth 2.1、エージェント・バッチ・CIには呼び出し元ごとのAPIキー。チーム共有のキーは作らない。
見つけやすく、検証しやすい形式で発行する。固有のプレフィックス、128ビット以上の乱数、チェックサムを付け、キーは一度だけ表示してハッシュだけを保存する。
キーごとに必要なツールだけを許可する。ツール単位のスコープにし、読み取りと書き込みを分け、本番で * は使わない。
漏れやすい場所に置かない。URL、ログ、コミットされるMCP設定ファイルには書かない。GitGuardianの調査では、公開GitHub上のMCP設定ファイルから24,008件の固有シークレットが見つかっています。
ローテーションは新旧を並走させて切り替え、失効は数分で終わらせる。漏えい時の手順は事前に決めておく。
不正利用の兆候を監視する。401の急増、見慣れない送信元IP、scope_denied が最初のサインです。

MCPのAPIキー管理とは
なぜ資格情報がMCPセキュリティの一番の弱点なのか
呼び出し元ごとの資格情報の選び方
トークンのライフサイクル早見表
発行：キーの形式を設計する
スコープ：1つの呼び出し元・1つのサーバー・1つの用途
保管：サーバー側とクライアント側
ローテーション：新旧を並走させる手順
失効：漏えい時の15分ランブック
検知：キーが不正利用されているサイン
よくある失敗（症状→原因→対処）
NodeFlareならこう解決できる
よくある質問（FAQ）

1. MCPのAPIキー管理とは

MCPのAPIキー管理とは、リモートMCPサーバーに提示される資格情報を、発行から廃止まで決まったルールで扱うことです。対象は固定のAPIキーとOAuthのアクセストークン、そしてMCPサーバー自身が裏側のSaaSやDBを呼ぶための資格情報です。

この記事では、次の3つを区別して使います。

用語	この記事での意味	一般的な有効期間
APIキー	自社で発行し、人以外の呼び出し元（エージェント、バッチ、CI）1つに渡すランダムな秘密の文字列	期限を設定しない限り長期
アクセストークン	認可サーバーが特定のMCPサーバー宛て（audience）に発行するOAuth 2.1のトークン	短期（仕様では認可サーバーは短命のトークンを発行すべき＝SHOULD）
下流の資格情報	MCPサーバーがラップするSaaSやDBにアクセスするための、サーバー自身のキー	サーバーのシークレットとして管理し、呼び出し元には渡さない

APIキーもアクセストークンも送り方は同じです。MCP仕様（2026-07-28版）では、クライアントはすべてのHTTPリクエストで Authorization: Bearer <token> を使わなければならず（MUST）、アクセストークンをURLのクエリ文字列に入れてはいけません（MUST NOT）。一方で、MCPの認可仕様そのものは任意（OPTIONAL）で、APIキーについては何も定めていません。APIキーの運用は、すべて提供者側の責任です。

2. なぜ資格情報がMCPセキュリティの一番の弱点なのか

有効なトークンを持つ攻撃者のリクエストは、正規の利用と見分けがつかないからです。仕様のAuthorization Security Considerationsにも、クライアントに保存されたトークンや、サーバーでキャッシュ・ログに残ったトークンを入手した攻撃者は「正規に見えるリクエストで保護されたリソースにアクセスできる」と書かれています。

数字で見ると、状況はかなり深刻です。

調査結果	数値	出典
公開GitHub上のMCP設定ファイルで見つかった固有シークレット	24,008件	GitGuardian「State of Secrets Sprawl 2026」
そのうち有効だったものの上位	Google APIキー（19.2%）、PostgreSQL接続文字列（14%）	同上
AIサービス関連シークレット漏えいの前年比	81%増	同上
2022年に検出された有効なシークレットのうち、4年後も有効なもの	64%	同上
OWASP MCP Top 10での「トークンの不適切な管理とシークレット露出」	MCP01（1位）	OWASP MCP Top 10（2025年版・ベータ）

注目すべきは64%という数字です。見つけること自体は難しくなく、GitGuardianも「問題は検知ではなく対処だ」とまとめています。キー管理の仕組みは、漏れても被害が小さく、すぐに無効化できる状態を作るためにあります。

OWASP MCP01は、MCPならではの漏れ方も挙げています。過去のセッションで使ったAPIトークンをエージェントに思い出させる、ツール呼び出しの生のペイロードがデバッグログに残る、共有コンテキストに仕込まれた指示で後から秘密を話させる、といったシナリオです。

3. 呼び出し元ごとの資格情報の選び方

人が自分のIDで操作するならOAuth 2.1、両端を自社で管理しているなら呼び出し元ごとのAPIキー、が基本です。社内SaaSをMCPで公開する場合の出発点として、次の表を参考にしてください。

呼び出し元	資格情報	有効期間の目安	理由
ClaudeやChatGPT、IDEから接続する社員	ユーザーごとのOAuth 2.1アクセストークン	数分〜数時間（リフレッシュあり）	ユーザー単位で同意・失効でき、仕様でaudienceの検証（RFC 8707）が求められる
デスクトップアプリやCLIなどのパブリッククライアント	リフレッシュトークン	使うたびに交換	仕様で、パブリッククライアントのリフレッシュトークンはローテーション必須（MUST）
社内エージェント・定期ジョブ	ジョブごとのAPIキー	30〜90日で定期交換	ブラウザでのログインが不要。ジョブごとに分ければログで誰か分かる
CIパイプライン	CIのシークレットストアに置いたAPIキー	短め。パイプライン変更時に交換	CIのログやフォークは典型的な漏えい経路
MCPサーバーからSaaS APIへの呼び出し	下流の資格情報（サーバーのシークレット）	SaaS側のポリシーに従う	仕様で、クライアントのトークンをそのまま転送することは禁止（MUST NOT）
ローカルのstdioサーバー	環境変数から読む資格情報	接続先サービスに従う	仕様で、stdioではHTTPの認可フローを使わない（SHOULD NOT）

有効期間はNodeFlare編集部の目安で、仕様の要件ではありません。一次情報として求められているのは、短命のアクセストークン（SHOULD）、パブリッククライアントのリフレッシュトークンのローテーション（MUST）、そしてOWASPの「可能な限り、一定期間で失効するようにシークレットを作る」という推奨です。

4. トークンのライフサイクル早見表

どの資格情報も、同じ6つの段階をたどります。各段階は本記事の5〜10章に対応しています。

段階	やること	一次情報
発行	暗号論的乱数、プレフィックス、チェックサム。表示は一度だけ	OWASP Secrets Mgmt 2.7.1、GitHubのトークン形式
スコープ	1つの呼び出し元、1つのサーバー、必要なツールだけ	MCP仕様 Scope Selection Strategy、OWASP MCP01
保管	サーバーはハッシュで保存。クライアントはシークレットストアかOSのキーチェーン。ログとURLには残さない	MCP仕様 Token Theft、Access Token Usage
ローテーション	新旧を並走させ、確認してから旧キーを廃止	OWASP Secrets Mgmt 2.7.2、2.4
失効	疑いの時点で即時。失効済みキーの利用試行も記録	OWASP Secrets Mgmt 2.7.3、8.3、9.2
監視	誰が、どのIPから、どのツールを呼び、結果はどうだったか	OWASP Secrets Mgmt 6.4

5. 発行：キーの形式を設計する

よいMCP APIキーは、推測できないほどランダムで、スキャナーが見つけやすく、DBに問い合わせなくても形式の正しさを確かめられるものです。参考になるのは、GitHubが2021年に導入したトークン形式です。

性質	GitHubの設計	MCPのAPIキーに当てはめると
プレフィックス	`ghp_`、`gho_`、`ghs_` など種類ごとに固有	コード・ログ・チャットの書き出しから自社のキーを検出できる。GitHubはプレフィックスだけで誤検知率が約0.5%まで下がると見込んだ
区切り文字	アンダースコア	Base64に含まれない文字で、ダブルクリックでトークン全体を選択できる
エントロピー	Base62で30文字、OAuthトークンで178ビット	総当たりは現実的に不可能
チェックサム	末尾6文字。CRC32をBase62で表現	偽物や途中で切れたキーを、DBを見る前にはじける

Pythonでの最小実装例です（Python 3.11で動作確認済み）。

import hashlib, secrets, zlib

ALPHABET = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
PREFIX = "acmemcp_"

def b62(n: int, width: int) -> str:
    out = ""
    while n:
        n, r = divmod(n, 62)
        out = ALPHABET[r] + out
    return out.rjust(width, "0")

def new_api_key() -> tuple[str, str]:
    body = "".join(secrets.choice(ALPHABET) for _ in range(32))  # 約190ビットの乱数
    key = PREFIX + body + b62(zlib.crc32(body.encode()), 6)        # 6文字のチェックサム
    digest = hashlib.sha256(key.encode()).hexdigest()
    return key, digest  # keyは一度だけ表示し、保存するのはdigestだけ

def looks_valid(presented: str) -> bool:
    """DB問い合わせ前の軽いチェック（シークレットスキャナーにも使える）"""
    if not presented.startswith(PREFIX) or len(presented) != len(PREFIX) + 38:
        return False
    body, checksum = presented[len(PREFIX):-6], presented[-6:]
    return b62(zlib.crc32(body.encode()), 6) == checksum

設計のポイントは次のとおりです。

保存するのはハッシュだけにする。キー自体に約190ビットの乱数があるので、SHA-256のような高速なハッシュで十分です。遅いパスワード用ハッシュは、人が考えた推測しやすいパスワードを守るためのものです。照合はハッシュ値で行います。
ハッシュと一緒にメタデータを残す。持ち主、呼び出し元名、対象サーバー、スコープ、作成日時、有効期限、最終利用日時、最終利用IP。ローテーションや事故対応はこの情報がないと進みません。
キーは作成時に一度だけ表示し、二度と表示しない。なくしたら新しく発行します。
環境ごとにプレフィックスを変える（例：acmemcp_live_ と acmemcp_test_）。テスト用のキーが漏れても、本番用と取り違えずに済みます。

6. スコープ：1つの呼び出し元・1つのサーバー・1つの用途

1本のキーでできることは、1つのMCPサーバーに対する1つの用途だけにします。こうすると、キーが漏れたときの被害も、プロンプトインジェクションで操られたエージェントができることも小さくなります。

社内SaaSをMCPで公開する場合のスコープ設計の例です。

呼び出し元	許可する	許可しない
サポート用エージェント（チケットを読み、返信案を作る）	`tools:list`、`get_ticket`、`search_kb`	`update_customer`、`send_email`
夜間の集計ジョブ	`export_usage` のみ	書き込み系のツールすべて
CIのスモークテスト	`tools:list`、`health_check`	それ以外すべて
運用自動化	`create_ticket`、`update_ticket`	`delete_record`、請求関連のツール

スコープ設計を機能させるためのルールです。

共有キーを作らない。OWASP MCP01は、トークンを「特定のエージェント、ツール、セッションに紐づける」ことを推奨しています。共有キーだとログで誰か分からず、1回のローテーションで全員が止まります。
本番でワイルドカードを使わない。* や全権限のキーは、漏れた時点で全面的な侵害になります。仕様のScope Selection Strategyでも、scopes_supported は「基本機能に必要な最小限のスコープ」とされています。
判定はサーバー側で、ツールの実行前に行う。クライアントやモデルはセキュリティ境界になりません。
スコープ不足には正しく応答する。OAuthの呼び出し元に対しては、403 と WWW-Authenticate: Bearer error="insufficient_scope" を返し、その操作に必要なスコープを1回のチャレンジでまとめて示すことが推奨されています（SHOULD）。

そもそもツールをどうリスク段階に分けるかは、MCPセキュリティ対策チェックリスト25項目のスコープ設計の章で解説しています。

7. 保管：サーバー側とクライアント側

MCPのキーが漏れるのは、使う場面よりも、保存したり表示したりする場面です。両側で対策します。

サーバー側（またはゲートウェイ）

やること	避けること
APIキーはハッシュで保存する	生のキーをDBやキャッシュに保存する
アクセスログやエラーのトレースから `Authorization` ヘッダーと既知のトークン形式を消す	MCPの生のペイロードをログに出す（OWASP MCP01のログ漏えいシナリオ）
下流の資格情報は暗号化したシークレットとして実行時に注入する	イメージ、ビルド引数、ソースコードにキーを埋め込む
IP単位で失敗回数を制限し、ロックアウトする	認証の総当たりを無制限に許す

クライアント側（Claude、IDE、エージェントを動かすマシン）

やること	避けること
クライアントが対応していれば、MCP設定から環境変数やシークレットマネージャーを参照する	コミットされるプロジェクトのMCP設定ファイルにキーをそのまま書く
MCP設定ファイルをシークレットスキャンやpre-commitフックの対象に入れる	キー入りの設定ファイルをチャットやチケットに貼る
個人利用ならOSのキーチェーンやパスワードマネージャーに保管する	`?token=...` のようにURLに入れる（プロキシやCDNのログに残る）
端末ごと、エージェントごとにキーを分ける	同じキーをノートPC、CI、サーバーで使い回す

ここで直接効く仕様のルールは2つです。トークンをクエリ文字列に入れてはいけない（MUST NOT）こと、そしてクライアントとサーバーはOAuth 2.1の7.1節に沿って安全にトークンを保管しなければならない（MUST）ことです。

8. ローテーション：新旧を並走させる手順

旧キーと新キーを短い期間だけ両方有効にし、切り替えを確認してから旧キーを廃止します。こうすれば停止が起きず、「止まるのが怖いから交換を先延ばしにする」状態を避けられます。

手順	作業	次に進む前の確認
1	同じスコープ・新しい有効期限で新しいキーを発行する	キーの台帳に新しいキーが載っている
2	呼び出し元のシークレットストア（CIのシークレット、Vault、環境変数）を更新する	コードやチャットにキーを直接書いていない
3	呼び出し元を再デプロイまたは再起動する	新しいキーでリクエストが成功している
4	ログで旧キーの利用を見張る	ジョブ1周分、旧キーへのリクエストが0件
5	旧キーを失効させる	旧キーでの試行が「拒否」として記録される

頻度の考え方です。

長期キーは定期的に。OWASPは「盗まれた資格情報が短期間しか使えないよう、定期的にローテーションする」ことを求め、手作業は「ミスにつながりうる」として自動化を勧めています。30〜90日ごとが現実的な初期値です。
次のときは即時に。アクセス権を持っていた人が異動・退職したとき、キーが画面に映ったり、どこかに貼られたりしたとき、呼び出し元の依存先が侵害されたとき。
OAuthは自動で。短命のアクセストークンとリフレッシュトークンのローテーションに任せます。

9. 失効：漏えい時の15分ランブック

キーが漏れた可能性があるなら、調査より先に失効させます。OWASPのインシデント対応の章にも「露出したキーは直ちに失効させる」とあります。

経過時間	作業
0〜2分	キーを失効させる。ゲートウェイがキーの照合結果をキャッシュしている場合は、そのTTLが切れるまで失効が効かない可能性があるので、TTLを把握しておく
2〜5分	同じか、より狭いスコープで代わりのキーを発行し、正規の呼び出し元を更新する
5〜10分	漏えい期間のリクエストログを確認する（送信元IP、呼ばれたツール、結果）
10〜15分	書き込み系や外部送信系のツールが呼ばれていたら、そのツールが使う下流の資格情報も交換し、影響を受けたデータを確認する
その後	漏れた場所（リポジトリの履歴、ログ、チケット）からキーを削除し、経緯を記録する

見落としやすい点が2つあります。

サーバーを再起動しても何も失効しない。OWASPも「アプリケーションの再起動だけでは、盗まれた資格情報は失効しない」と明記しています。
失効済みキーの利用試行も記録する。OWASPの検知のライフサイクルで求められている項目で、失効後も繰り返し使われていれば、漏えいが実際に悪用されていると分かります。

10. 検知：キーが不正利用されているサイン

OWASPは「誰が・何が、どのIPから、どの方法でシークレットにアクセスしたか」を継続的に監視するよう求めています（Secrets Management Cheat Sheet 6.4）。MCPでは、次のサインが特に役立ちます。

サイン	考えられること	対応
401が急増する	総当たり、または失効済みの漏えいキーが使われている	ロックアウトの状況と送信元IPの範囲を確認する
有効なキーが新しい国やASNから使われる	発行した端末の外にキーがコピーされた	失効・再発行し、IP許可リストを検討する
普段使わないツールで `scope_denied` や403が出る	プロンプトインジェクションでエージェントが操られている、または盗まれたキーで探索されている	セッションを確認し、スコープを狭いまま保つ
ジョブの実行時間外に呼び出しがある	キーがジョブ以外で使われている	失効させ、CIやオフィスのIP範囲に限定する
同じキーが同時に多数のIPから使われる	共有されたか、漏えいしたキー	呼び出し元ごとのキーに分割する

ログはインシデント対応に必要な期間だけ残します。OWASPのCI/CD向けの指針では、少なくとも90日間は検索できる状態にしておくことが推奨されています。

11. よくある失敗（症状→原因→対処）

症状	原因	対処
キーを1本交換したら5つのエージェントが止まった	共有キー	呼び出し元ごとにキーを分け、個別にローテーションする
数週間後に公開リポジトリでキーが見つかった	コミットされたMCP設定ファイルにキーを直書き	環境変数参照とpre-commitスキャンを導入し、失効・再発行する
CDNやプロキシのログにキーが残っている	クエリ文字列にトークン	`Authorization` ヘッダーに移し（仕様でMUST）、ローテーションする
キーの持ち主が誰も分からない	発行時にメタデータを残していない	持ち主、呼び出し元、サーバー、スコープ、期限をハッシュと一緒に記録する
古いキーがいつまでも生きている	有効期限も最終利用日時もない	期限を設定し、30日使われていないキーは失効させる
読み取り用のキーが漏れてデータが書き換えられた	「念のため」書き込み権限も付けていた	読み取りと書き込みでツールもキーも分ける
下流APIのログにエンドユーザーのトークンが出ている	トークンパススルー	サーバー自身の資格情報を使う（仕様で転送はMUST NOT）

12. NodeFlareならこう解決できる

NodeFlareでは、各MCPサーバーの前にプロキシがあり、リクエストがコードに届く前に認証と認可を行います。この記事で挙げたリスクごとに、ドキュメントに記載された機能で対応できる部分をまとめます。

この記事のリスク	NodeFlareの機能	内容
認証なしのアクセス、共有の資格情報	APIキーとOAuth	呼び出し元は `mcp_*` 形式のAPIキーかOAuthアクセストークンを `Authorization: Bearer` で送る。プロキシがOAuthのディスカバリー（RFC 8414 / RFC 9728）を提供するので、対応クライアントは認証フローを自動で見つけられる。サーバーは既定で非公開
生のキーの保存、総当たり	キーのハッシュ化とロックアウト	APIキーはハッシュ化して保存。同じIPから誤ったキーが続くと、そのIPを10分間ロックアウト
権限が広すぎるキー（6章）	リクエストごとのスコープ判定	MCPのメソッドと対象を正確に照合する：`*`、`tools:list`、`tools:call`、`tools:call:<ツール名>`（例：`tools:call:get_weather`）、`resources:read:<uri>`、`prompts:get:<name>`。拒否された呼び出しはJSON-RPCエラーになり、サーバーには届かない
漏れたキーが別の場所から使われる（10章）	送信元IPの許可リスト	アクセスポリシーを `restricted` にしてIPv4/IPv6のCIDRを登録する。認証やVMの起動より前に判定され、リストが空ならすべて拒否
下流の資格情報の漏えい（7章）	暗号化されたシークレット	環境変数は保存時に暗号化され、VMの起動時にだけ注入される。ビルド引数、イメージレイヤー、ログには残らず、ビルドログでは既知のトークン形式が伏せ字になる
盗まれた下流の資格情報によるデータ持ち出し	Egress制御	モードは `off`（既定）、`observe`（送信先を記録）、`enforce`（遮断）。許可リストは最大100件（完全一致のホスト名、先頭1つのワイルドカード、IP）
漏えい時に証拠がない（9〜10章）	リクエストログ	リクエストごとに `caller_kind`（`api_key`、`oauth`、`anonymous`）、`client_ip`、`session_id`、`outcome`（`ok`、`scope_denied`、`rate_limited` など）、`http_status` を記録。ツール引数は値を残さずキー名だけを記録。保存期間はFreeで7日、Pro/Teamで30日
1つのサーバーの侵害が他に広がる	microVMによる分離	サーバーごとに専用のFirecracker microVMで動き、NodeFlareが運用する専用の物理サーバー上で稼働

利用者側に残る仕事もあります。有効期限とローテーションの周期を決めること、クライアントの設定ファイルにキーを書かないこと、漏えい時のランブックを回すことです。また、NodeFlareはモデル内部で起きるプロンプトインジェクションそのものは防げません。狭いスコープ、Egress制御、ログによって、乗っ取られたエージェントが有効なキーでできることを小さくする、という位置づけです。

最小の始め方

MCPサーバーをデプロイする（既定で非公開）。
呼び出し元ごとにAPIキーを作り、必要な tools:call:<ツール名> だけを付ける。
アクセスポリシーを restricted にしてオフィス・VPN・CIのIP範囲を登録し、Egress制御を observe で有効にする。

1サーバーまでは無料で試せます。NodeFlareを始める

13. よくある質問（FAQ）

MCPサーバーのAPIキーはどう管理すればいい？

呼び出し元ごとにプレフィックス付きのランダムなキーを発行し、ハッシュだけを保存し、必要なツールだけのスコープと有効期限を付けます。ローテーションは新旧を並走させて行い、疑いがあれば即座に失効させ、呼び出し元・ツール・結果をすべてログに残します。

リモートMCPサーバーはOAuthとAPIキーのどちらを使うべき？

社員などの個人が自分のIDで接続するならOAuth 2.1です。ユーザーごとに同意と失効ができます。ブラウザでログインできない社内エージェント、定期ジョブ、CIには、呼び出し元ごとのAPIキーが向いています。両方に対応するサーバーも多くあります。

MCPの仕様にAPIキーの定めはある？

ありません。MCPの認可仕様（2026-07-28版）はHTTPトランスポート向けにOAuth 2.1ベースのフローを定めたもので、認可そのものが任意（OPTIONAL）です。ただし、Authorization: Bearer で送り、クエリ文字列には入れないというヘッダーのルールは、APIキーにもそのまま当てはめるべきです。

MCPのAPIキーはどのくらいの頻度でローテーションすべき？

長期キーは30〜90日などの決まった周期で交換し、アクセス権を持つ人が抜けたときや露出の疑いがあるときは即時に交換します。OAuthでは短命のアクセストークンとリフレッシュトークンのローテーションに任せます。仕様は、パブリッククライアントのリフレッシュトークンのローテーションを必須にしています。

MCPのAPIキーが漏れたら何をすればいい？

まず失効させ、代わりのキーを発行し、そのあとリクエストログで何に使われたかを確認します。書き込み系や外部送信系のツールが呼ばれていたら、そのツールが使う下流の資格情報も交換し、漏れた場所からキーを削除します。

MCPのトークンをURLに入れてもいい？

いけません。MCP仕様では、アクセストークンをURLのクエリ文字列に入れることは禁止（MUST NOT）です。URLはブラウザの履歴やプロキシ、CDNのログに残るためです。毎回のリクエストで Authorization ヘッダーに入れて送ります。

MCPのAPIキーを特定のツールだけに制限するには？

キーにツール単位のスコープを付け、ツールを実行する前にサーバー側で判定します。読み取り用と書き込み用のツールを分けておけば、読むだけの呼び出し元に書き込み権限を渡さずに済みます。本番ではワイルドカードのスコープを避けます。

MCP設定ファイルのシークレットは本当に問題になる？

なります。GitGuardianの「State of Secrets Sprawl 2026」では、公開GitHub上のMCP設定ファイルから24,008件の固有シークレットが見つかりました。クライアントが対応していれば環境変数やシークレットマネージャーを参照し、MCP設定ファイルもシークレットスキャンの対象に入れます。

トークンパススルーとは？なぜ禁止されている？

MCPサーバーがクライアントから受け取ったトークンを、そのまま下流のAPIに転送することです。仕様ではMUST NOTとされ、サーバーは上流への呼び出しに、別に発行された自分の資格情報を使わなければなりません。

MCPのAPIキーに有効期限は必要？

可能な限り付けるべきです。OWASPのSecrets Management Cheat Sheetは「可能な限り、一定期間で失効するようにシークレットを作る」ことを推奨しています。期限があれば、失効を忘れたキーの被害にも上限ができます。最終利用日時も記録し、使われていないキーは失効させます。

まとめ

MCPのAPIキー管理は、日々のMCPセキュリティの成否を分ける部分です。呼び出し元ごとにプレフィックス付き・ハッシュ保存・狭いスコープのキーを渡し、URL、ログ、コミットされる設定ファイルには置かず、新旧を並走させてローテーションし、数分で終わる失効手順を用意しておきます。人にはaudienceに紐づいた短命のOAuth 2.1トークンを使い、下流の資格情報はサーバー側のシークレットとして管理します。tool poisoningやサプライチェーンを含む脅威の全体像はMCPセキュリティ対策チェックリスト25項目を、MCPサーバーの置き場所を検討中なら認証方式も比べたMCPサーバーホスティングのランキングをご覧ください。