なぜ Model Context Protocol (MCP) には認証・認可が不可欠なのか


## はじめに

生成 AI が業務フローに入り込み、LLM が社内 API や SaaS を直接叩く時代になりました。LLM と外部システムを安全につなぐ標準として登場した **Model Context Protocol（MCP）** は、LLM の USB‑C ポートと表現されていますが、ポートを開け放つだけでは機密情報も操作権限も垂れ流しです。本稿では **「なぜ認証（Authentication）と認可（Authorization）が不可欠なのか」** をリスクと対策の観点で整理します。


## MCP が直面する 4 つのセキュリティ課題

| # | リスク             | 具体例                             | 認証・認可の役割                                |
| - | --------------- | ------------------------------- | --------------------------------------- |
| 1 | **機密データ漏えい**    | 売上 DB へ SELECT が誰でも実行できる        | 認証で主体を確定し、認可で読み取りのみの最小スコープを付与           |
| 2 | **破壊的オペレーション**  | LLM が誤って `DELETE FROM invoices` | 書込み系スコープは別扱いし、追加認証や人間承認を要求              |
| 3 | **マルチテナント境界破り** | SaaS 上で他社データを読む                 | アクセストークンに tenant\_id を署名付きで保持し、越境なら 403 |
| 4 | **追跡不能**        | 事故後「誰が何をした？」不明                  | 署名付きトークンとアクセスログで完全な監査証跡を残す              |

## MCP 特有の事情：プロンプト流出と短命トークン

LLM ではツール呼び出しも文字列としてモデルへ渡るため、**アクセストークンやシークレットがプロンプト本文に混入**しやすいのが致命的です。

```
1) sql_query(...) の引数に api_key をベタ渡し
2) エージェントが JSON で LLM へ送信
3) LLM 出力をそのまま UI に表示
4) 画面コピー → 社外 SNS に貼られ漏えい
```

### 防止策

* **短命トークン（TTL 5 分以内）** に変換し、流出しても被害時間を限定
* **最小スコープ** で read / write を分離
* **ヘッダ注入はミドルウェア側** で行い、モデルに見せない

## 解決アプローチ：OAuth 2.1 ＋ Dynamic Client Registration

1. **Dynamic Client Registration (DCR)** でエージェントが自己登録
2. **最小権限スコープ** `tool:<name>:<verb>` をトークンに付与
3. **短命アクセストークン＋リフレッシュトークンローテーション**
4. **署名付き JWT & JWKS** で改ざん防止

```
Agent ── DCR ──▶ Auth Gateway ── code_exchange ──▶ IdP(Cognito等)
  │                                    ▲
  ▼  Bearer JWT (TTL<=5m)              │
MCP Server ◀─── verify (JWKS) ───────┘
```

## 権限モデルはどこで誰が管理するか

| レイヤー                  | 管理主体例               | 役割                                       |
| --------------------- | ------------------ | ---------------------------------------- |
| **ID 基盤**             | 情シス / IdP 管理者      | アカウント・ロールのライフサイクル管理 (IAM IC, Azure AD 等) |
| **Auth Gateway ポリシー** | セキュリティ／プラットフォームチーム | スコープ設計、短命トークン発行、DCR、監査 (Cedar, OPA など)   |
| **MCP サーバ側 ACL**      | アプリ開発チーム           | ツール実装とスコープ→実クエリのマッピング                    |

Auth Gateway を集中管理ハブとすることで、開発チームはツール実装に集中し、ロール追加は GitOps で一元管理できます。

## 最新仕様 (2025‑03‑26) のポイント（認証・認可関連のみ）

1. **OAuth 2.1 準拠フレームワークが正式化** – 短命 JWT と DCR を必須要件に採用。
2. **ツールアノテーション `readonly` / `destructive`** – 危険操作を Gateway で追加承認させやすく。

https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization

## 結論と次のステップ

* **認証・認可は“後付け機能”ではなく MCP 導入の前提条件**。
* PoC でも最初から **Auth Gateway + 短命 JWT + 最小スコープ** を組み込むこと。
* AWS なら *Cognito + Fargate Gateway*、全社 SSO なら *IAM Identity Center RegisterClient* が最短ルート。

> なお、同コンセプトと思われる AWS Labs が RFC として提案中（GitHub Issue #222）で、公式 Gateway 実装が OSS 化される可能性があります。

## ベストプラクティスチェックリスト

| 項目               | 推奨設定                                               |
| ---------------- | -------------------------------------------------- |
| トークン TTL         | **≤ 5 分**                                          |
| スコープ設計           | `tool:<name>:<verb>`、read/write 分離                 |
| DCR              | 必須。Cognito は Gateway、IAM IC は `RegisterClient` API |
| 監査ログ             | CloudTrail + アプリログで「誰が・何を・いつ」                      |
| Prompt Injection | 重要操作前に UI で意図確認                                    |