1. ベースラインフィンガープリント
最初の接触で、ゲートウェイはサーバーのアドバタイズされたツールセットの正規ハッシュ を計算し、承認されたベースラインとして保存します：- ハッシュはすべてのツールの名前、説明、入力 JSON スキーマをカバーします — まさにラグプルが変えるサーフェスです（持ち出し引数を得るツール、あるいはプロンプト インジェクション向けに武器化された説明は、ハッシュを反転させます）。
- それは順序に依存しません：サーバーがツールリストを並べ替えても、スキーマ内の キーを並べ替えても、変更とは見なされません。本物の定義変更だけがハッシュを動かします。
2. スキーマステータスのライフサイクル
各登録済みサーバーはschema_status を持ちます。状態と、それがサーバーのツールが
提供されるかどうかにどう影響するか：
| ステータス | 意味 | ツール提供？ |
|---|---|---|
| (ベースライン化されていない) | 初回使用 — まだベースラインが記録されていない。 | ディスカバリー姿勢：はい（trust-on-first-use — 現在のスキーマがベースラインとして捕捉されます）。ストリクト姿勢：いいえ — 下記 pending を参照。 |
verified | ライブスキーマが承認されたベースラインに一致。 | はい |
changed | ドリフト検出 — ライブスキーマがベースラインと異なる。 | いいえ — フェイルクローズ |
pending | ストリクト（trust-on-first-use なし）姿勢下でベースライン化されていないサーバー — 承認待ち。 | いいえ — フェイルクローズ |
quarantined | 管理者がサーバーを保留した。 | いいえ — フェイルクローズ |
3 つのクローズ状態 —
changed、pending、quarantined — はすべて、サーバーの
ツールがゲートウェイ経由で提供されるのを停止します。verified は常に提供します；
ベースライン化されていないサーバーは、ディスカバリー姿勢（trust-on-first-use）の
下でのみ提供され、ストリクト姿勢の下では pending として保留されます。ドリフトが
静かに通過することは決してありません。3. ドリフト時に何が起こるか
再チェックでライブスキーマがもはやベースラインに一致しないことが判明したとき：4. ドリフトしたサーバーの再承認
再ベースライン化は単一の呼び出し（またはコンソールアクション）です：verified に戻します。（サーバーの隔離は、変更が敵対的だと
判断したときのための別個のアクションです — approve_schema は verified への
再ベースライン化だけを行います。）このアクションは監査トレイルに書き込まれます。
5. これがどこに収まるか
スキマドリフト検出は、ラグプル防御のスキーマレイヤー半分です；もう半分はmcp
サーフェス上の呼び出しごとの評価です（すべての tools/call がディスパッチ時に
あなたのポリシーに対してチェックされます）。両者は「定義が変わった」と「この特定の
呼び出しは危険だ」の両方をカバーします。
ラグプル防御
完全なラグプル像 — スキーマベースラインと呼び出しごとの評価。
MCP セキュリティ概要
MCP ゲートウェイ、スキル、クレデンシャル。
MCP ツールポイズニング
このステートマシンが防御する脅威。
MCP 監査イベント
スキーマ変更とゲートウェイ決定の監視。