セキュリティパイプライン

MCP Fusion はセキュリティを、各層がリクエストの中で明確な位置を持つパイプラインとして適用します。このページはその技術地図です：何が、どの順番で、どんな保証付きで実行されるか。

端から端まで、その順序

1 contextFactory      tenant and identity resolution
2 rate limiter        sliding window, key from ctx
3 input firewall      LLM-as-Judge on the arguments
4 validate            strict Zod per action, unknown keys rejected
5 middleware chain    auth, audit, custom, precompiled and frozen
6 handler             your business logic
7 Presenter           schema shape → _select → redact → serialize
8 rules and UI        computed on the full object, never on the wire copy
9 egress guard        byte budget on the text response
10 audit + telemetry  every stage emits if a sink is configured

レイヤーごとに

Rate limiter

rateLimit({ windowMs, limit, keyFn }) は、タイムスタンプのリストに対するスライディングウィンドウを使うミドルウェアです。重要なのは 2 つの呼び出しです。increment() は記録せずにカウントし、record() は受理されたリクエストのみをログに残すため、拒否されたトラフィックは自分のウィンドウを膨らませられません。keyFn(ctx) は識別用のフックです。トークン単位、テナント単位、ユーザー単位でレート制限を適用できます。ストアはインターフェースです。インメモリストアは単一プロセス専用と文書化されており、本番では同じインターフェースの裏側で、あなた自身の Redis や KV を使います。

入力ファイアウォール

inputFirewall({ judge }) は Zod 検証の後、あなたのハンドラーの前で動きます。引数は審査用プロンプトにシリアライズされ（フェンスエスケープを防ぐためバッククォートは無効化されます）、差し替え可能な SemanticProbeAdapter が { safe, threats } を返します。!safe ならハンドラーは呼び出されません。レスポンスは自己修復的な toolError('INPUT_REJECTED', ...) になります。この層はインジェクション型の入力に向けたものです。「前の指示を無視せよ」のような文句、データ持ち出しのペイロード、密輸されたファイルパスなどです。

Presenter によるマスキング（エグレス ファイアウォール）

.redactPII(paths, censor?) は fast-redact のパスを 1 つの関数にコンパイルし、Presenter にキャッシュします。Presenter.make() の中のパイプライン順序は厳密です。切り詰め、検証、_select の適用、wire 用データのクローン化、マスキング、文字列化、その後で、マスキングされていない完全なオブジェクトから UI ブロックとルールを描画します。帰結は以下の通りです：

• モデル向けのテキストにマスキングされたフィールドが含まれることは決してありません。_select で隠したキーについて [REDACTED] は wire 上にも現れません
• ui.table() のブロックは実際の値を保ちます（メモリ上の完全なオブジェクトから構築されており、wire 用のテキストはすでに凍結済みだからです）
• structuredClone またはマスキング処理が例外を投げると、パイプラインも例外を投げます：Data withheld to prevent PII leak。この時点でマスキングは fail-closed です。

プロンプトファイアウォール

ルールそのものが攻撃面です。動的ルールはデータから生成され、そのデータはエージェントの世界からやって来るからです。presenter.promptFirewall({ judge }) は、蓄積されたシステムルールを、それらのどれかがモデルに届く前に審査官に送ります。戦略は fail-closed かつルールごとです。審査官がバッチ全体を問題視して一部のルールのみ名指しした場合、名指しされていないルールもブロックされます。全員の合意を要求するコンセンサスモードに fail-open はありません。ファイアウォールを設定すると非同期パスが強制されます。make() は例外を投げ、makeAsync() が契約となります。

サンドボックス

tool への sandboxed() は計算の委任が可能であることを伝えます。エージェントが JS のアロー関数を送ると、SandboxEngine はそれを新しい isolated-vm コンテキスト内で実行します。データは外部コピーとして注入され、返されるのは戻り値だけです。既定値は、タイムアウト 5 秒、isolate 128MB、出力上限 1MB、コード上限 64KB です。process、require、fs、globalThis、Buffer はコンテキストの中に存在しません。明白なパターンを拒否するガードは DX のためのものであって境界ではないと明記されています。キャンセル時にはエンジンが isolate を破棄し（他のリクエストと共有している場合はコンテキストのみ解放）、次の呼び出し時に再生成します。

キルスイッチと halt

非常停止はコンソールにあります。Connector policy を参照してください。グローバルな halt とコネクタ単位のポリシーがあります。Edge では、halt されたコネクタは再デプロイなしに呼び出しの配信を停止します。

フレームワークがやらないこと

マーケティングより誠実さを。フレームワークの監査ミドルウェアはあなたのシンクへイベントを送ります（引数の SHA-256 ダイジェスト、ステータスの分類。署名もチェーンもありません）。改ざん耐性のある署名付き監査チェーンは Vinkius Cloud のホスティング機能です。mcpfusion deploy でデプロイすれば、プラットフォームが代わりに記録します。レート制限ストアについても同じ切り分けが当てはまります。インターフェースはあなたのもの、実働は Edge が担当します。

次のステップ

• Runtime architecture：エンジンの中で各レイヤーがどこに位置するか
• Governance：パイプラインがロックされたままだったことの証明
• Tools：tool にガードを貼り付ける