『ブロックした数が多い＝安全』ではない、というAIエージェント向けセキュリティ設計

AIエージェントがMCP経由で外部ツールを呼び出すようになると、「このツール呼び出しを許可すべきか」という判断がエージェントの安全性を左右するようになる。個人開発者VinayK88氏が公開しているOSSプロジェクト「AgentShield」は、この判断を1つのモデルや1つのルールに任せず、決定論的なポリシー・学習型の異常検知・効果測定の3層に分けて設計する、という考え方を提示している。

3行まとめ

1. AgentShieldは、ツール呼び出しをALLOW/ALLOW_WITH_REDACTION(機微情報を除去した上で許可)/REQUIRE_APPROVAL(人間の承認待ち)/BLOCKの4段階で判定する決定論的ポリシーエンジンを核に置く。「学習型のモデルは説明はできるが、権限を勝手に付与したり、ハードルールを上書きしたりはできない」と設計原則に明記している。
2. ラプラス平滑化されたマルコフ連鎖モデルで、ツール呼び出しの並び(トラジェクトリ)がどれだけ「普段と違うか」をsurprisal(サプライザル、驚き度)という指標で数値化する仕組みも組み込む。単発の呼び出しではなく「順序」に着目する設計だ。
3. 開発者自身がREADMEで「すべて合成データによる評価であり、実世界での攻撃検出率・誤検知率・MCP侵害予測を確立するものではない」と明記しており、本番のMCPサーバーには接続していない、いわば設計思想のデモンストレーションだ。

「多くブロックする＝良いセキュリティ」ではない、という前提

AgentShieldのREADMEが繰り返し強調しているのは、ブロック数の多さと実際のセキュリティ向上は同じではない、という前提だ。

"Blocking more actions is not automatically better security. A useful safeguard should reduce risky outcomes without unnecessarily breaking legitimate agent work." （「アクションを多くブロックすることは、自動的に良いセキュリティを意味しない。有用な安全策とは、正当なエージェントの作業を不必要に壊すことなく、リスクのある結果を減らすものであるべきだ」）

この立場から、AgentShieldは自らを「ポリシーエンジンであると同時に、セキュリティデータサイエンスのシステム」と位置づけ、prevented-risk rate(防いだリスクの割合)・benign false-positive rate(正当な作業を不必要にブロックした割合)・approval latency(承認待ちによる遅延)などを並べて計測する仕組みを持つ。「厳格な制御」と「適応的な制御」を並べて比較する実験と、両者の効用差にブートストラップ法で信頼区間を付ける仕組みまでリポジトリに含まれている。

「順序」に着目するマルコフ連鎖モデル

もう一つの核が、ツール呼び出しの並びを状態遷移として捉える学習型モデルだ。ツール呼び出しはexternal_read・sensitive_read・external_write・destructive_writeのような行動状態に変換され、正常な合成ワークフローから遷移頻度を学習する。ある呼び出し列がどれだけ「普段と違うか」を、平均負の対数尤度であるsurprisalとして算出する。README中の例はこう示す。

sensitive_read → external_write
                ↑
          unusual transition

「機微情報を読んだ直後に外部へ書き出す」という遷移が、正常なワークフローの中では稀であれば、この一手だけで警告が上がる、という発想だ。README自身が「静的な分類器は1回の呼び出ししか見ないが、エージェントのセキュリティはしばしば“順序”に依存する」と説明しており、単発のツール呼び出し監査では拾えない挙動を狙っている。

ポリシー例ファイルには「このYAMLはランタイムには読み込まれない」と書いてある

リポジトリのpolicies/runtime-policy.example.yamlをraw取得すると、4段階判定の中身がどんなルールとして書かれうるかが具体的に分かる。

出典: policies/runtime-policy.example.yaml（GitHub raw）

ただし、このYAMLファイル自体の冒頭にはstatus: illustrativeという記載があり、ファイル内のコメントには「このファイルはPythonの決定論的エンジンが示すポリシーの意図を文書化したものであり、このportfolio labのランタイムによってパースされるわけではない（It is not parsed by the runtime in this portfolio lab）」と明記されている。つまり、実際に動くのはPythonコード側のロジックであり、このYAMLはあくまで「こういうルールが書ける」という設計意図のドキュメントという位置づけだ。

README本文にはもう1つ、実測値の表があった。

出典: README.md「Synthetic policy baseline」節。README自身が「これらは合成データによる回帰テストの結果であり、本番の有効性を主張するものではない」と付記している。

開発者自身が「実世界での効果は未確立」と明言している

README全体を上から下まで読んでいて印象に残ったのは、機能を誇る言葉遣いより「これはまだ何を証明していないか」を書く分量の方が多かったことだ。この記事を読む上で一番大事な一次情報は、README末尾の「Evaluation boundary(評価の境界)」節にある。

"All tool calls, identities, destinations, experiments, and training sequences are synthetic. The project demonstrates evaluation mechanics and runtime integration; it does not establish real-world attack recall, false-positive rate, or MCP compromise prediction." （「すべてのツール呼び出し・識別情報・宛先・実験・学習用シーケンスは合成データである。このプロジェクトは評価の仕組みと実行時統合を示すものであり、実世界での攻撃検出率・誤検知率・MCP侵害の予測を確立するものではない」）

さらに「MCP scope」節では、本番のMCPプロキシではないことも明記されている。

"This portfolio implementation is MCP-aware, not a live production MCP proxy... A production version would add authenticated server identity, signed/versioned tool manifests, transport integrity, live tool registry state, cross-agent delegation graphs, and monitored tool-definition changes." （「このポートフォリオ実装はMCPを意識してはいるが、本番稼働するMCPプロキシではない。……本番版であれば、認証されたサーバーID、署名・バージョン管理されたツールマニフェスト、トランスポートの完全性、実稼働中のツールレジストリ状態、エージェント間の委任グラフ、ツール定義変更の監視などが必要になるだろう」）

READMEが自らを「portfolio implementation(ポートフォリオ実装)」と呼んでいる通り、これは実運用のセキュリティ製品というより、個人開発者が自分のセキュリティ設計力を示すために作った、一貫した思想を持つ実装例と捉えるのが実態に近い。「シンセティック評価の6/6ケースで期待通りの判定が出た」という数字も、あくまで開発者自身が用意したベースラインに対する結果であり、本文でも「これは合成回帰テストの結果であり、本番の有効性を主張するものではない」と釘を刺されている。

GitHub上でのスター数は本記事執筆時点で0、フォークも確認できていない。作成は2026年8月16日、直近のプッシュは8月26日で、活発に更新が続いていることは確認できた。リポジトリ直下のSECURITY.mdをraw取得すると「AgentShieldは防御目的の、シミュレーションのみのポートフォリオプロジェクトである。デフォルトでは実際のMCPサーバー・本番のSaaSアカウント・非公開データベース・認証情報・稼働中のエージェント基盤には一切接続しない」と、README末尾の「Evaluation boundary」節と同じ主張が独立したファイルとして繰り返されており、開発者が一貫してこの立ち位置を明示していることが確認できた。

MCPサーバー側が仕掛けてくる攻撃そのものについては、時間差で信頼を裏切る攻撃パターン「TrustShift」を扱った別記事や、MCPセキュリティ研究5本を横断したこちらの記事も参照してほしい。AgentShieldのようなクライアント側(エージェント側)のゲートウェイ設計は、これらサーバー側の脅威研究とは補完関係にある。

関連記事

• MCPとは──AIとツールをつなぐ共通規格
• MCPサーバーは最初だけ「良い子」でいる──信頼を積んでから裏切る攻撃『TrustShift』
• 『96.89%が危険』と出たMCPスキャナーの警告のうち、本物は半分未満だった