Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
はじめに：「AIがAPIを叩く」世界から、「AIが運用を動かす」世界へ
近年、LLMの活用は単なるチャットUIの枠を超え、外部ツールやデータソース、業務システムと密接に連携しながら、自律的にタスクを遂行する「AIエージェント」へと進化しつつあります。
この設計思想の文脈で注目されているのが、Anthropicが提唱した Model Context Protocol（MCP） です。
MCPは、LLMが外部リソースとやり取りする際に必要となるコンテキスト共有やツール実行の構造を整理するための、オープンな標準化アプローチとして位置づけられています。
同様の設計思想は、OpenAIやGoogleによるエージェント実装や、外部ツール連携の仕組みにも見られ、業界全体として「LLMを中心に据えた運用・業務自動化」への関心が高まっています。
本稿では、こうした MCP的アーキテクチャを採用したAIエージェント を前提に、SREおよびDevSecOpsが今後向き合うべき新しい失敗モードと、防御設計の考え方について整理します。
脅威モデルの再定義
MCPは「バックドア」ではないが、新しい攻撃面になり得る
まず明確にしておくべき点は、MCPそのものがバックドアであるとか、仕様として脆弱性を内包している、という話ではないということです。 一方で、MCP的アーキテクチャが従来のAPI連携とは異なる形で 新しい攻撃面（アタックサーフェイス）を生み出しやすい ことも事実です。
非決定論的コンポーネントが制御プレーンに入り込む
従来のCI/CDやRunbook、SOARによる自動化は、設計上は入力と結果の対応関係を明示的に定義しやすく、決定論的な挙動に寄せることが可能でした。これに対して、LLMは本質的に確率的であり、文脈に依存して振る舞います。
その結果、同じ入力でも状況に応じて異なるツール呼び出し、想定外のコンテキスト混入により、意図しない判断を行い、プロンプトインジェクションによって制御ロジックが歪められる、といった事象が起こり得ます。これは、「正しく記述したはずの自動化」が、状況次第で異なる挙動を示す可能性を意味しており、SREにとって無視できない性質の変化です。
権限の「爆発半径（Blast Radius）」が拡張されやすい
従来のAPI設計では、エンドポイントやスコープが明確に固定され、呼び出し可能な操作の範囲を事前に定義することが一般的でした。一方、AIエージェントは、1つのプロンプトを起点として複数のツールを連鎖的に実行し、その実行パスは実行時の推論によって決定されます。
このため、人間が事前にすべての分岐をレビューできずに、想定外の組み合わせで操作が実行され、影響範囲を完全に把握することが難しくなる、といった課題が生じます。 結果として、権限設計を誤ると、単一の判断ミスが広範囲に影響を及ぼす可能性があります。
「LLMは善意である」という暗黙の信頼の危険性
初期段階の実装では、LLMが生成する判断やツール呼び出しを「基本的に正しいもの」とみなしてしまいがちです。
しかし、実際にはLLMのコンテキストには、ユーザー入力、外部ドキュメント、ログやアラート、メタデータといった、必ずしも信頼できない情報が混入します。
この前提に立てば、LLMは「信頼できる制御ロジック」ではなく、常に 侵害され得る制御ロジック として扱う必要があります。
なぜ従来のAPIセキュリティだけでは不十分なのか
IAM、API Gateway、WAFといった従来のセキュリティ対策は、今後も重要であり続けます。しかし、それらだけではAIエージェント特有の失敗モードを十分にカバーすることは困難です。なぜなら、制御ポイントが 「事前設計（静的）」から「実行時の推論（動的）」へと移動しているからです。
従来のAPIは、明示的なリクエストに基づいて処理が行われるのに対し、MCP的エージェントはLLMの推論結果をもとに、実行内容そのものを動的に生成します。この違いは、単なる実装差ではなく、設計思想そのものの転換を意味します。
SRE / DevSecOpsが取るべき「4つの設計原則」
この新たなリスクに対応するため、SREおよびDevSecOpsは、以下の4つの原則を設計段階から組み込む必要があります。
1.認証情報は「使い捨て」を前提にする
静的なAPIキーや長期間有効な認証情報を前提とした設計は避けるべきです。実行単位で最小権限を付与する短寿命トークンを採用し、自動ローテーションを前提とした設計を行います。LLMに「長く使える鍵」を持たせないことが基本原則です。
2. プロンプトを「外部インターフェース」として扱う
プロンプトは単なる入力ではなく、外部から制御ロジックに影響を与えるインターフェースとして扱う必要があります。プロンプトインジェクションを想定内の攻撃ベクトルと捉え、ツール呼び出しの直前に検証・制限レイヤーを挟みます。LLMの判断をそのまま実行系に流さない構造を設計することが重要です。
3. コンテキスト分離と最小権限を徹底する
テナント、環境、ワークフロー単位でのコンテキスト分離を厳格に行い、ロールベースのアクセス制御（RBAC）をツール実行レベルまで落とし込みます。「便利だから」という理由ですべてのデータや操作権限を見せる設計は、事故の起点となります。
4. 「常時」可視化と監視を行う
どのプロンプトが、どのような判断を経て、どのツールを実行したのかを常にトレース可能にします。 AIエージェントをブラックボックスとして扱うのではなく、他の運用コンポーネントと同様に、監視とレビューの対象として管理下に置く必要があります。
実践イメージ：セキュリティ運用への応用
具体的なユースケースとして、Sysdig Secure のようなセキュリティ製品が、Kubernetesのイベントや脆弱性情報をLLM経由で自然言語検索可能にするケースを考えます。
ここで重要なのは役割の分離です。
- LLMには、膨大なデータを横断した「調査」や「相関分析」を任せる
- 実際の「実行」や「修復」は、人間や明示的に定義されたRunbookを介在させる
AIに判断の補助は任せても、最終的な実行の引き金は任せない。 この境界線を引くことが、現実的かつ安全な第一歩となります。
AIエージェントの観測可能性 ―― 「知能」をクラウドのインフラ管理に統合する
かつてInfrastructure as CodeやSOARが登場した際も、自動化の暴走やロジックミスによる障害は避けられませんでした。l自動化の歴史は、常に暴走との戦いでした。しかし、自律的に判断し、ツールを連鎖させるAIエージェントのリスクは、従来のロジックミスとは次元が異なります。
もはやAIエージェントは、「便利な道具」ではなく、サーバーやDBと同様に、SLO（サービスレベル目標）を定め、その健全性を監視すべき「主要なシステム構成要素」です。
MCPを軸とした設計思想に基づき、AIの判断に制動をかけ、そのプロセスを透明化する。この「知能のオブザーバビリティ（Observability）」をインフラに組み込むことこそ、これからのSREおよびDevSecOpsが担うべき新たな責務に他なりません。
ここでいう「知能のオブザーバビリティ」とは、ブラックボックス化しがちなAIの推論やツール実行のプロセスを、従来のメトリクスやログと同様に追跡・制御可能にすることを指します。この新しい観測可能性を実装し、AIエージェントが自律的にセキュリティリスクを評価・判断できる環境を構築する具体的な手段となるのが、Sysdig MCP サーバーです。
Sysdig MCP サーバーを介することで、AIエージェントはクラウド環境の「今」を映し出すリアルタイムの脅威検知データや、ランタイム（実行時）のコンテキストに直接アクセスできるようになります。これにより、例えばSnyk MCPサーバーが提供する「静的なリスクリスト」を、実際の稼働状況に基づいた「知能のオブザーバビリティ」へと昇華させられます。
例えば、AIが開発段階の脆弱性情報とSysdigのランタイム検知をMCPを通じて統合すれば、「どの脆弱性が、実際にインターネットから攻撃可能な状態で、かつ重要なデータにアクセス可能な権限を持って動いているか」を即座に特定できます。
AIに判断を丸投げするのではなく、Sysdig MCP サーバーによって、AIがインフラ全体のコンテキストを「エコーロケーション（反響定位）」のように描き出し、人間が迅速かつ正確な意思決定を行えるよう支援する。こうした、実効性のある「精度が高いオブザーバビリティ」の実装こそが、AI時代のクラウドセキュリティにおける強力な武器となるはずです。