The Half of Agent Security You’re Not Governing
2026/05/04 SecurityBoulevard — 多くのセキュリティチームが、AI エージェント・リスクに直面しているが、そこで用いられる手法は従来のものである。具体的には、MCP サーバのスキャン／サプライチェーン監査／既知の脆弱性の検出であるが、それらが対応するのは、攻撃対象領域の可視部分に過ぎない。残る半分は、エージェントが実行するコードではなく、その推論プロセスへの対応である。この領域は、構造化されたログを生成せず、アラートも発生せず、フォレンジック痕跡もほとんど残さない。
Noma Security の “Research, Spring 2026：Lethal by Design” は、この非対称性の範囲を明確に示し、現実の世界で組織が制御できる要素に基づく、ガバナンス・フレームワークを提案している。
根本的な非対称性：MCP サーバと Skill
MCP (Model Context Protocol) サーバの動作は、決定論的なものである。それぞれのツールは、構造化されたコード関数／定義済みパラメータ／予測可能な出力／ログ化された呼び出しを持つ。それらを観測するセキュリティツールは、既知の動作へのマッピングや、事後フォレンジック分析などを実行できる。
その一方で Skill は、まったく異なる原理で動作する。具体的には、テキストベースの命令セットであり、それらがエージェントの推論コンテキストへロードされる。言語モデルによる解釈は、モデル状態／会話履歴／周辺コンテキストに基づく。
セキュリティチームは、Skill のロード自体を観測することは可能である。しかし、その後の有害な動作であるファイル削除や不正な外部書き込みなどを、特定の Skill 命令へ遡及することは不可能である。この種の因果の連鎖は、モデル内部の推論に完全に閉じており、現在の可観測性フレームワークは到達できない。
MCP 接続のみを統制する組織は、監査は可能な半分のみを保護しているに過ぎない。もう半分は、ほぼ無統制の状態にある。
既存のリスク・フレームワークの破綻
多くのエンタープライズは、 Meta の “Agents Rule of Two” に依存している。このモデルでは、以下の 3 条件のうちの 2 条件を満たすエージェントが危険だとされる：
- 未信頼の入力を処理
- 機密データへのアクセス
- 状態変更または外部通信を許す
しかし、このモデルは実運用で破綻している。
2025年7月のインシデントにおいて、攻撃者は GitHub プルリクエストを介して VS Code 用の Amazon Q エクステンションに破壊的プロンプトを注入し、ローカル・ファイルシステムの削除と AWS リソースの削除を実行させた。この攻撃では、外部通信もデータ流出も発生していない。上記の 2 条件のみでシステム破壊が成立した。
同年同月に、Replit の AI コーディング・エージェントは、攻撃者が不在の状態で、1200 件以上の役員データを含む本番データベースを削除した。これはハルシネーションによる誤動作であり、本来は許可されるべきでない操作が実行された。
これらの事例は、評価すべき指標が誤っていることを示している。問題は条件数ではなく被害範囲 (blast radius) である。前述の Rule of Two は、これを評価できない。
実環境におけるリスク規模
Noma は、多数の MCP サーバおよび Skill を分析し、8 種類のリスク分類に基づき評価した。
- 組織環境における MCP サーバの 76% が、高リスク機能を持つ。
- 人気 Skill の 62% が、少なくとも 1 つのリスク特性を持つ。
- 25% の MCP サーバが、任意のコード実行を許可する。
最も一般的なリスク・カテゴリは、”状態とデータの変更” であり、MCP の 60% に存在し、Skill の 57% に存在する。それが意味するのは、大多数のエンタープライズ・エージェントが、不可逆的な損害を引き起こす能力を持つことだ。
特に危険なのは、個別の機能ではなく組み合わせである。Noma は、以下の 5 つの危険パターンを特定している：
- 機密データ漏洩チェーン：RAG を経由する未信頼の入力から外部流出への連鎖。
- 信頼データ攻撃：信頼データ内に埋め込まれる悪意のペイロードにより前提が崩壊。
- サプライチェーン攻撃：正規ワークフローを用いた任意のコードを配布／実行。
- 自律的破壊：攻撃者が不在の状態であっても、ハルシネーションによる破壊が成立。
- 金融詐欺：永続的なメモリ改変により、徐々に被害が拡大。
重要性
Noma の No Excessive CAP フレームワークは、制御不能な要素から制御可能な増幅要因へと焦点を移す。
- Capabilities：エージェントが実行可能な機能を制御する。必要最小限のツールのみを許可し、任意のコード実行を避け、MCP バージョンを固定する。
- Autonomy：命令から結果に至る自動化の範囲を制御する。高リスク操作には、人間による承認を必ず介在させる。
- Permissions：エージェントの実行権限を制御する。最小権限／短期資格情報／ユーザースコープを徹底する。
これら 3 要素は乗算的に作用する。機能が広くても、自律性が低ければ制御は可能である。最も危険なのは、機能／自律性／権限が最大化された状態である。
組織にとって不可能なことは、エージェントの推論内容の監視と、Skill の安全性の保証である。しかし、エージェントが実行できる範囲を、制御することは可能である。
現在の環境では、すでに多くのエージェントが不可逆的な損害を引き起こす能力を持っている。この 3 つの制御軸が、現時点で最も効果的なエンタープライズ防御ポイントである。
訳者後書：AI エージェントが普及する中で、従来のセキュリティ対策では防げない新しいリスクが浮き彫りになっています。問題の原因は、AI の推論プロセスという目に見えない領域にあります。従来のツールは、プログラムの動きを記録できますが、AI エージェントが持つ Skill という自然言語の命令セットは、AI の頭の中で解釈されるため、たとえ破壊的な行動に至ったとしても、その証拠 (ログ) が残りません。例えば、悪意の指示によりファイルが削除されても、それが AI の誤解 (ハルシネーション ) なのか攻撃なのかを判別できないのです。現在の多くの AI エージェントは、データの書き換えやコード実行といった強力な権限を持っており、それらが暴走すると取り返しのつかない損害を引き起こす可能性があります。それに対抗するには、AI の考えを監視しようとするのではなく、AI に与える 機能 (Capabilities)／自律性 (Autonomy)／権限 (Permissions) 厳格に制限することが現実的で効果的な防御策となります。
IoT OT Security News 
You must be logged in to post a comment.