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