Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年5月26日に Dan Belmonte が投稿したブログ (https://www.sysdig.com/blog/sysdig-mcp-server-on-amazon-bedrock-ai-powered-dspm-in-action) を元に日本語に翻訳・再構成した内容となっております。
セキュリティチームは、アラートのトリアージ、調査、修正対応といった運用ワークフローに基盤モデル（foundation model）を組み込み始めています。こうしたエージェントが効果を発揮するためには、ランタイムでの検知、アイデンティティ分析、脆弱性のコンテキスト、データセキュリティの検知結果といったセキュリティインテリジェンスへの構造化されたアクセスが必要です。
しかし、エージェント型セキュリティのスピードとスケールを活かしたいと考える多くのチームにとって、そのワークフローにはデータに関するギャップが存在します。問題はデータが手に入らないことではなく、そのデータをエージェント型のワークフローから呼び出せるようにすることです。ここで力を発揮するのが、Model Context Protocol（MCP）サーバーを活用したHeadless Cloud Securityです。
AWS Marketplaceで提供されているSysdig MCPサーバーを使えば、エージェント型AIを活用するセキュリティチームは、それぞれの要件に合わせたワークフローで、幅広いユースケースに対してSysdigのデータを利用できます。
本ブログでは、Sysdigのデータセキュリティ検知結果、すなわちBedrock Dataとの連携によりSysdigが提供するクラウドネイティブなデータセキュリティポスチャー管理（DSPM）機能に焦点を当てます。
データセキュリティ検知では、金融データ、個人を特定できる情報（PII）、個人健康情報（PHI）を発見・分類し、セキュリティチームが露出などのリスクを把握、調査、修正対応するのに役立てます。
アーキテクチャー：AWSネイティブなAIセキュリティスタック
中核となるAIスタックは完全にAWS内で動作します。つまり、モデル推論、ツールのオーケストレーション、エージェントのメモリすべてが、お客様のアカウント境界内にとどまります。
各コンポーネントは次のように組み合わさります。
- Amazon Bedrock： Amazon Bedrock上でホストされる基盤モデルが、あらゆる調査を支える自然言語理解、推論、意思決定の機能を提供します。
- Amazon Bedrock AgentCore： AgentCoreは、Sysdig MCPサーバーをマネージドなAgentCore Runtimeとしてホストし、その前段にAgentCore Gatewayを置くことで、MCP互換のどのクライアントからでも接続できるようにします。
- Sysdig MCPサーバー： LLMとSysdigのセキュリティインテリジェンスをつなぐ標準化されたブリッジです。ランタイムでの脅威検知、Kubernetesのオブザーバビリティ、脆弱性インテリジェンス、ポスチャの検知結果をエージェントに提供します。MCPサーバーは、認証付きのアウトバウンドAPIコールでSysdig Secureから検知結果を取得します。
Sysdig MCPサーバーの運用化
デモシナリオを見ていく前に、この環境で必要となるものを整理しておきます。
Headless Cloud Security：Onboarding skill
AWS環境とSysdigを接続するためには、複雑なセキュリティワークフローをAIエージェントが実行可能なアクションへとパッケージ化する、専用のスキルを使います。スキルは、従来のオンボーディングワークフローのような摩擦なしに、あらかじめ用意された専門知識を提供します。
クラウドアカウントやIAMロール、スキャンポリシーを手作業で設定する代わりに、スキルを呼び出すだけで、エンドツーエンドのセットアップを担ってくれます。
このデモでは、対象のAWSアカウントをSysdig Secureに接続するためにOnboardingスキルを利用します。エージェントがスキルを呼び出し、必要なクラウドインフラのプロビジョニングとDSPMスキャンの有効化が、すべて単一の会話プロンプトから実行されます。
Data Security Findings付きのSysdig Secure
保存されたデータの公開状況や、IAM・攻撃経路のようなリスクプロファイルをスキャン、分類、マッピングするためには、AWSストレージ（S3およびRDS）に対してData Security Findingsを有効化したSysdig Secureアカウントが必要です。
Amazon Bedrock AgentCore
3種類のAgentCoreリソースを使用します。
- Runtime： Sysdig MCPサーバーのコンテナをホストし、そのライフサイクルを管理し、Secrets Managerから資格情報を注入します。
- Gateway： サービス間でIAMベースの認証を行う安定したMCPエンドポイントを公開します。これによりMCP互換のクライアントは、インフラを管理することなく接続できます。
- Memory： 会話の継続性を提供し、複数ステップにまたがる調査の間、エージェントがコンテキストを保持できるようにします。
この構成を実用的にしているのがGatewayです。エージェントは、Sysdigのツール群にアクセスするための単一かつ安定したURLを得られる一方、AgentCoreがネットワーキング、スケーリング、Runtimeとクライアント間のIAM信頼関係を引き受けてくれます。
ローカルクライアント：お好みのAIエージェント
MCPに対応するクライアントであれば、どのようなものでもローカル側の表面として利用できます。
本ブログでは、ワークフロー全体の単一インターフェイスとしてOpenCodeを使用します。OpenCodeはユーザーの質問を受け取り、ツール呼び出しをAgentCore Gatewayへルーティングし、LLM推論をAmazon Bedrock上で実行します。
動作するワークフロー
スタックをデプロイし、Sysdig MCPサーバーを接続できたところで、実データに対していくつかのプロンプトを実行し、追跡可能でツール裏付け済みの回答を得ていきます。
機微なデータの露出：そこには何があり、誰が見られるのか？
シナリオ：セキュリティチームがデータセキュリティのレビューを開始しようとしています。修正対応の優先順位を決める前に、クラウド環境全体でどのような機微なデータが存在し、現時点でそのうちどれだけが公にアクセス可能なのかを正確に把握する必要があります。
エージェントはSysdigのDSPMグラフに直接問い合わせ、Personal dataカテゴリに絞り込んだ上で、公に露出しており、かつ分類済みの機微なデータを含むS3バケットの情報を返します。返ってくるのは、バケット名、所有アカウント、露出状況、検出された具体的なデータクラス、各検知結果の重大度を含む構造化されたインベントリです。
本シナリオでは修正対応の実施は対象外ですが、同じ会話インターフェイスは、AWS MCPサーバー、CLI駆動のスキル、あるいはチームのワークフローに合うあらゆる手段を通じて、そのままアクションへと自然に拡張できます。
解釈されたポスチャーレビュー：インベントリからインサイトへ
シナリオ：コンプライアンスチームは、Sysdig Secureが提供するデータセキュリティ検知結果の解釈を必要としています。どの検知がどの規制に対応するのか？目立たないリスクはどこに潜んでいるのか？データクラスのどの組み合わせが、単一のバケットを攻撃者にとって最優先のターゲットにしてしまうのか？
エージェントはSysdig Secureのデータに対して、データカテゴリの種別、重大度の分布、バケット単位の詳細など、複数のQLクエリを並列に実行します。そして、その出力を統合してエージェントが推論を行います。
ヘルスデータにはHIPAA、金融データにはPCI DSS／SOXといった規制フレームワークに、データクラスをマッピングします。この情報を使い、エージェントは、ラテラルムーブメントを可能にする要素となるTerraformステート内のログイン認証情報など、目立たないリスクを特定します。そして、重大度だけでは見えてこないコンテキストを与える複数の要因を用いて、これらのリスクに優先順位を付けます。
結果として得られるのは、ソーシャル・セキュリティ・ナンバーや生年月日といったPIIに加え、ヘルスデータや金融データを含む、公に露出したバケットを筆頭にしたリスクの階層的なランキングです。このランキングには、公に露出してはいないものの、規制違反リスクだけでもトップ3に入るバケットも含まれます。
検知から修正対応まで
リスクを特定するのは半分にすぎません。あとはそのギャップを塞ぐ必要があります。Sysdig MCPサーバーをAmazon Bedrock上のAWS CLI MCPサーバーと組み合わせると、同じ会話型ワークフローが、調査から修正対応まで一貫してつながります。
この例では、エージェントが機微なS3バケットへのアクセスを与えてしまっている過剰権限のIAMロールを特定します。この情報を踏まえ、エージェントは不要な権限を取り除いた、範囲を絞り込んだIAMポリシーをドラフトできます。
アクセスを制限してください。特定された3つの機微なバケットに対して、EKS-Node-PaymentsRoleにdenyポリシーを適用してください。
すべてのツール呼び出し、すべての検知結果、すべてのポリシー変更を含む調査ログは、インシデント文書化のための追跡可能な記録として残ります。
重要なポイント
上記の各シナリオでは、ストレージ構成、IAMアクセス経路、ランタイムでの検知、データの機微性といった複数のセキュリティ領域を、一つの調査で横断する必要があります。Sysdig MCPサーバーは、それぞれを独立した、問い合わせ可能なツールとして公開します。
エージェントは、調査の必要に応じてこれらの異なるシグナルを任意の順序で連鎖させることができます。各ステップは特定のツール呼び出しに対応しているため、得られる結果は幻覚的な要約ではなく、追跡可能な証拠の連鎖となります。この強力な機能により、次のことが可能になります。
- コンテキストを踏まえた修正対応： エージェントは、DSPMの分類（どの機微なデータが存在するか）、ポスチャ検知（誰がアクセスでき、露出しているか）、ランタイムシグナル（実際に不審な活動があるか）を相関させ、具体的なアクションを推奨し、承認のもとで実行します。
- 解決までのスピード： 通常は複数の画面を行き来しなければならない、時間のかかる手作業のワークフローが、エージェントとの会話インターフェイスを通じて数秒で完了します。
Headless Cloud Securityをはじめる
Skill とMCPサーバーによって実現されるHeadless Cloud Securityは、組織にとって大きな転換点です。セキュリティチームは、オペレーターからオーケストレーターへと進化していけます。本記事のDSPMシナリオは、その出発点に過ぎません。
最終的に、Headless Cloud Securityをどう活用するかは、お客様次第です。
SysdigのHeadless Cloud Securityについて詳しく知るには、最新のエージェントスキル、教育コンテンツ、実践的なガイダンスを受け取れるニュースレターにサインアップしてください。
Headless Cloud Securityを実際にご覧になりたい方は、デモをリクエストしてください。