Devotd Github
新着セキュリティ

ezed9/mcp-bouncer — MCP 呼び出しの宛先を防ぐ決定論的ファイアウォール

MCP クライアントとツールサーバーの間で、ツール呼び出しが向かう宛先を LLM なしで決定論的に判定するローカル stdio プロキシ ezed9/mcp-bouncer を紹介します。

リポジトリ情報ezed9/mcp-bouncer ↗

MCP クライアントとツールサーバーの間で、ツール呼び出しが向かう宛先を LLM なしで決定論的に判定するローカル stdio プロキシ ezed9/mcp-bouncer を紹介します。

GitHub の説明: A deterministic exfiltration firewall for MCP tool calls — gates the destination, not the tool. No LLM in the decision path.

スター
★ 2
フォーク
0
言語
Python
ライセンス
MIT
原文を見る ↗GitHub で見る ↗

ezed9/mcp-bouncer は MCP クライアントと既存のツールサーバーの間に入るローカル stdio プロキシです。ツールを 1:1 で再公開しながら呼び出しを検査し、その値がどの宛先へ出るかを LLM を介さずに決定論的に判定します。判定基準はツールを使えるかどうかではなく、値が出去哪_create_placehold PLACEHOLDER 先です。Python で書かれており、ライセンスは MIT です。

判定に使う材料は記録されたスキーマ、ポリシー、taint(汚染)ログです。データの出所と引数の制約、呼び出し予算をルールとして計算し、呼び出しひとつを allow、deny、ask のいずれかに分類して、結果をローカルの監査ログに残します。判定は LLM や分類器を経由しない純粋な Python のルールエンジンだけで下されるため、同じ入力には同じ判定が出て、分類器ベースのガードとは再現性と監査可能性が構造的に異なります。AgentDojo v1 workspace スイートで実際に測定した結果もケース単位が公開されています。基準の攻撃成功は 1/3 で、Bouncer を適用すると 0/3 でした。ユーザタスク效用は 0.33 から 1.00 へ、無害条件效用は 1.00 でした。

ただし、サンプルが小さいという限界は記録自身が明かしているとおりです。v1 の初期段階であり、ポリシー DSL の拡張性は検証されていません。スターは 2 つで、リリースもまだありません。提示された条件では、ブロックとタスク效用の維持が同時に現れましたが、この数値だけで一般的な MCP 環境での結果を断定するには早いのです。