第12章 — プロトコルの堅牢化と防御

LLM Primer IV: MCPで設計するAI認知 のウォークスルー第12回です。前章のすべての脅威に守りを当て、どの守りも銀の弾ではなく、それらの組み合わせだけが実際に配備できる姿勢を作る、という話です。

なぜこの章があるのか

プロトコルは配備されることで安全になりません。素のプロトコルが置く前提を補うスタックの中で配備されることで安全になります。第11章は脅威を並べました; この章は工学的な深さで守りを歩きます。暗号的能力アテステーションはディスカバリと能力昇格のクラスを閉じます。ユーザー委任トークン付きのOAuth 2.1スコープ規律は代理人とパススルーのクラスを閉じます。境界付きセッション寿命はセッション乗っ取りのクラスを閉じます。サンドボックスは予防がすり抜けた侵害を封じ込めます。Human-in-the-loop の承認は、残りのスタックが有用であるために自動化しなければならなかった破壊的操作を捕まえます。各守りは残余リスクを残します — 組み合わせが残余を実用上十分に小さくします。

12.1 AttestMCP: 暗号的能力アテステーション

1つ目の守りは、ほぼすべての脅威に通底する問題 — 話している相手が名乗る通りのものか、ホストには確かめる手段がない — を扱います。AttestMCP — MCPSec、あるいは署名済み能力マニフェストとも呼ばれます — は、プロトコルのメッセージ構造の上に暗号的アテステーションの層を追加します。発行者は、ディレクトリか透明性ログに登録された長寿命の署名鍵を保持します。完全な能力マニフェストはリリース時にハッシュ化されて署名されます。ホストは initialize 時にファイル上の発行者鍵に対して署名を検証し、サーバーを受け入れるか、隔離するか、接続を拒否します。

利点は本物です。タイポスクワットは正当な発行者からの有効な署名を生成できません。list_changed 通知を通じた能力昇格は、新しいマニフェストは新しい署名を要するので検出可能になります。細粒度ポリシー — 「リポジトリには GitHub発行者を信頼するがメールには信頼しない」 — は、発行者の身元が主張ではなく検証可能になるので、強制可能になります。コストも本物です: 発行者は署名インフラを運営する必要があり、透明性ログには信頼できる運営者が必要で、ホストのポリシー層は失効を理解する必要があります。正直な枠付けは「AttestMCPは実質的なエンジニアリングで、チェックボックスではない」。そして名指す価値のある隙間: マニフェストが署名するのは サーバーが自分について言うこと で、ランタイムで何をするかではありません。良性のツールについての署名済み宣言が、漏出させる実装を出荷することはできます。アテステーションは必要ですが十分ではない — だから章の残りが存在します。

12.2 OAuth 2.1 のスコープと境界付きセッション寿命

2つ目の集まりは、認証情報とセッションのモデルを締めます。OAuth 2.1 のフローは成熟していて、エンジニアリングはそれらを正しく使うことの中にあります。最初の規律は 狭いスコープ — 宣言されたツール面が必要とするものだけを要求する。スコープがきついほど爆発半径は小さい。実は思うより難しい。上流サービスはスコープを粗く定義することが多く、狭い道は退屈で、広いスコープは初回で動いて進捗のように感じます。狭いスコープのコストはエンジニアが払い、広いスコープのコストは何かが間違ったときにユーザーが払います。

スコープ規律だけでは提供できない Confused Deputy への守りは ユーザー委任トークン。上流が対応していれば、各ユーザーが自分のOAuthフローを完了し、サーバーは自分のサービスIDではなくユーザーのトークンで動きます。サーバーが自分の権限で動いていないので代理人が消えます。Token Passthrough は別の直し方: トークンを通過させない。サーバーは登録時に確立した自前の認証情報を持ち、ホストとサーバーの境界はトークンを運びません。境界付きセッション寿命 は乗っ取りに当たります: 高リスク操作は分、定常操作は時間、複数時間のタスクは15分ごとにユーザーへ問い直さなくて済むよう、上に耐久ワークフロー・アイデンティティを重ねる。セッションごとの能力バインディング と、セッション更新時の 能力の再確認 が規律を完成します — どちらもホストが明示的に行うべき状態管理で、多くの実装が行っていません。

12.3 サンドボックスとランタイム隔離

3つ目の集まりは、すべての脅威を予防できるわけではなく、守れる姿勢は予防が失敗したときに被害を封じ込めねばならないことを認めます。ローカル・サーバー向けのプロセス・サンドボックス — Linuxではseccomp、macOSではApp Sandbox、WindowsではAppContainer、より強い隔離にはgVisor — は、ファイル・ネットワーク・プロセスへのアクセスを既定で拒否し、サーバーが必要とする特定のアクセスだけを許可します。パスワード・ファイルを読もうとする、または攻撃者エンドポイントへ漏出させようとする侵害されたサーバーは、サーバー・コードが自制したのではなくサンドボックスが拒否したからOSレベルで操作を拒否されます。リモート・サーバーへのネットワーク・ポリシー — 相互TLS、許可リスト化されたエンドポイント、egressフィルタリング — は、侵害されたリモート・サーバーが届く面を狭めます。ホスト内のコンテンツ隔離は、返ってきた内容をモデルのコンテキストに着地する前に適切に疑って扱います: 信頼できない印、HTMLサニタイズ、埋め込みURLを辿らないこと。能力認識ポリシー越しのツール呼び出しサンドボックスは、ホストが呼び出し引数を検査して許可・拒否・ユーザー承認へエスカレートできるようにします。名指す価値のある特定リスクは 正当なツールを通じたサイドチャネル漏出 — 悪意あるモデルが検索クエリに認証情報を符号化する — で、ポリシー層がエンドポイントではなく引数を検査することで捕まえます。サプライチェーン隔離がループを閉じます: バイナリのハッシュは、インストールと更新時に透明性ログ内の署名済みの値に対して検証され、マニフェストがチェックを通っても改ざんされたバイナリは動けません。

12.4 Human-in-the-loop の承認ゲート

4つ目の集まりは、自動化すべきでない操作があることを認めます。破壊的、不可逆、または影響の大きい呼び出し — 送金、ファイル削除、本番への変更 — は、起きるその瞬間に明示的な人間の判断に値します。仕組みはHITLゲートで、エンジニアリングは「使い物にしながら効かせる」ことにあります。可逆性で分類: 読み取り専用は自動で進み、状態を変える操作はゲートする。意味のある提示: 「ツール実行を許可?」というモーダルはハンコ押しで、有用なゲートはツール、完全な引数、平易な言葉での帰結、そして出所を見せる。承認疲れを避けるためのバッチ化された文脈承認 — 「前四半期の顧客に請求書を送る」を発動したユーザーが、メール20通それぞれではなくバッチを一度承認する。利害の高い操作は帯域外でルーティング — ハードウェア・トークン、第2デバイス、金融業界から借りたステップアップ認証。操作を可視に、監査可能に、取り消し可能に保つ。Sampling 起因の呼び出しはエージェント起因の呼び出しと同じゲートを通します。サーバー発推論のサイドチャネルは、ユーザーが気づかないうちに副作用へ落ちる権利を持ちません。

この章を踏まえて

工学的絵柄のセキュリティ半分は揃いました。もう半分 — フレームワーク、デプロイメント・パターン、性能特性、そしてシステムが本番で動くことを確かめるテスト — は残りの章が扱います。第13章はそのアークを、2025年と2026年に着地したフレームワークとクラウド統合 — Strands と Amazon Bedrock、AWS のステート層パターン、Microsoft Agent Framework、LangChain、Semantic Kernel — を歩くことで開きます。フレームワークが大事なのは、誰も素のプロトコルから本番MCPを作らないからで、フレームワーク間の選択はプロトコル層だけでは決まらない仕方で工学的・セキュリティ姿勢を形作ります。

次回 — 第13章: フレームワークとクラウド統合。 Bedrock と Strands、AWS のステート層、Microsoft の Agent Framework、LangChain、Semantic Kernel、そしてチームが独立にたどり着く3つの本番統合パターン。