This is some text inside of a div block.
< ブログ一覧に戻る

Sysdig AI Defense のご紹介:エージェントの行動を可視化し、阻止し、証明する

清水 孝郎
Sysdig AI Defense のご紹介:エージェントの行動を可視化し、阻止し、証明する
執筆者
清水 孝郎
Subscribe to Threat Research
Sysdig AI Defense のご紹介:エージェントの行動を可視化し、阻止し、証明する
Published:
November 5, 2026
この記事の内容
TRT in your inbox

Get security briefings from the Threat Research Team

New campaigns, attacker techniques, and detection guidance — straight to your inbox.

Subscribe
シスディグによるファルコフィード

Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。

さらに詳しく
Green background with a circular icon on the left and three bullet points listing: Automatically detect threats, Eliminate rule maintenance, Stay compliant, with three black and white cursor arrows pointing at the text.

本文の内容は、2026年11月4日に Blair Howardが投稿したブログ (https://www.sysdig.com/blog/introducing-sysdig-ai-defense) を元に日本語に翻訳・再構成した内容となっております。

AIは「支援」から「実行」へと移り変わりました。エージェントは今や、ファイルを読み、コマンドを実行し、実在する人物のアクセス権限でクラウドにまで到達します。ほとんどの場合、エージェントの行動を記録したものは、エージェント自身が書いたログしかありません。「AIエージェントの実像:1か月・300台の実測データ」は、あるソフトウェア企業のエージェントが、カーネルが実際に実行を確認した7つのプロセスにつき、ツール呼び出しを1回しかログに残していなかった実態を示しています。さらに、対象はエンジニアだけではありません。経理部門の誰かが、火曜の午後にコーディングエージェントを設定してしまうこともあります。追加されるエージェント、モデル、シートはいずれも、多くの企業ではチームやタスクに紐付けられない費目になります。

すべてのエージェントを見つけ、できることを決め、記録を残す

Sysdig AI Defense は、チームが利用するすべてのAIエージェントに対するランタイムセキュリティとガバナンスを提供します。エージェントが作業を始めるノートPCから、その行動が及ぶクラウドまでをカバーします。

まず、そこに何があるのかを可視化します。従業員が使っているエージェント、MCP サーバー、スキル、プラグインを、承認されていないものも含めて検出し、それぞれをアカウントとその背後にいる人物に紐付けます。

次に、エージェントに許可する操作を決めます。ほとんどの場合、何も変わりません。ポリシーで指定していないものはすべて通常どおり実行されるため、開発者は作業を続けられます。重視する操作については、対応を選択できます。Confirm(確認)は呼び出しを一時停止し、先に開発者へ承認を求めます。Block(ブロック)は呼び出しを完全に拒否します。Kill process(プロセス終了)は、プロセスが開始された瞬間に作業を終了させます。

何が起きても、記録は残ります。Sysdig AI Defense が確認したすべてのアクションは、デバイスの外にある、エージェントが改ざんできない Sysdig テナントに保存されます。セキュリティチームは何が起きたかを証明でき、リーダーはどのチームがどのモデルをどの業務で使っているかを把握できます。

内部では、Sysdig がクラウドワークロードを保護するために構築してきたものと同じランタイムエンジンを使っています。同じセンサーのコードベース、検知のための同じ Falco ルール、同じ脅威リサーチです。新しいのは、監視する場所です。AIエージェントが作業する場所ならどこでも追跡するようになりました。

デフォルトでは、Sysdig AI Defense は従業員が入力したプロンプトやエージェントの返信を収集しません。ファイルの編集内容とツールの実行結果は、マシンから出る前に削除されます。データは、お客様が選択したリージョンの Sysdig テナント内に留まります。

チームが実行するすべてのエージェントと MCP サーバーを可視化し、利用できるものを決める

セキュリティリーダーから最もよく聞かれる質問はシンプルです。どのエージェントが動いているのか、承認されていないものはどれか、そして誰が所有しているのか、というものです。ほとんどの組織は、まだこれらに答えられません。2026年の IBM の調査では、回答した組織の77%が、AIの導入がすでにガバナンスを上回るペースで進んでいると答え、CIO と CTO の3分の2が、十分に統制できていないAIシステムについて責任を問われていると答えています。Sysdig AI Defense は、Claude Code、Codex、Cursor、GitHub Copilot などのツールをまたいで、実際に動いているものから答えを出します。さらに、従業員のワークステーション、本番環境の Linux と Kubernetes、自社で所有していないマネージド型エージェントプラットフォームまで、AIファブリック全体でエージェントを追跡します。

Sysdig AI Defense の Explorer で、1つのアイデンティティを展開し、関連する部門、デバイス、ハーネス、MCP サーバー、モデル、スキル、脅威を表示した画面。Explorer でアイデンティティを展開すると、実行された2つのハーネスと4つのモデル、使用されたスキルと MCP サーバー、そしてそれに対する検知とキル(強制終了)を確認できます。

セキュリティチームの多くは、把握している以上のエージェントを動かしている可能性があります。約300台のマシンを持つあるソフトウェア企業は、Sysdig AI Defense の導入1か月目にそれを知りました。この1か月間、すべてのポリシーを Alert(アラート)で運用していたため、ブロックされたものはありませんでした。詳しい調査結果は「AIエージェントの実像:1か月・300台の実測データ」で公開しています。それらのマシンで Sysdig AI Defense が検出したエージェントの半数は、セキュリティチームが把握していなかったインスタンスでした。従業員は会社のデバイス上で、シングルサインオンを経由せず個人のメールアドレスで登録しており、すべてのデバイスに、少なくとも1つのエージェントハーネスがインストールされ、実際に使われていました。 

シャドーAIは、未承認のエージェントだけではありません。アーリーアダプターからは、従業員のマシン上で Ollama、llama.cpp、LM Studio が動いていた、Qwen のコーディングモデルがローカルで提供されていた、モデルがノートPCに直接ダウンロードされていた、といった報告がありました。これらはどれも AI ゲートウェイを通らないため、ゲートウェイからは見えません。しかしカーネルには見えます。それぞれのインストール、起動、モデルのプルを確認し、背後にいる人物に紐付けます。

可視化できれば、何を許可するかを決められます。新しい AI ツールは、デバイス上に現れた時点でインベントリに表示されます。エージェントに MCP サーバーやそのツールを使わせたくない場合は、それを拒否してポリシーを Block に設定します。エージェントの呼び出しは実行前に拒否され、エージェントにはその理由が示されます。エージェントがデータを送信してはならないサービスがある場合は、ポリシーにそのサービスを指定すると、Kill process によって、プロセスが開始された瞬間にアップロードが終了されます。

‍

Claude Code のターミナル。Sysdig AI Defense が、未承認の宛先への顧客データのエクスポートのアップロードを終了させ、ポリシー名と例外申請のリンクを表示しています。transfer.sh への4,812件の顧客レコードのアップロードが、プロセスの開始と同時に終了されました。それを止めたポリシーと、例外を申請するためのリンクが表示されています。

エージェントには作業させ、行き過ぎた操作だけを止める

許可リストを使えば、すでに望ましくないと分かっているものを簡単に止められます。しかし、操作そのものの判断はより困難です。作業の途中、多くの場合ほんの一瞬の間に起こるためです。こうしたモデルを開発しているラボでさえ、自社のエージェントが一線を越える場面を目にしています。OpenAI と Anthropic はどちらも、テストタスクを実行していたエージェントが、他者が所有する実在のシステムに到達した事例を公表しています。そのため、確認はエージェントが行動する瞬間に行う必要があります。Block と Confirm のポリシーは、エージェントのツール呼び出しが実行される前に介入します。Kill process は、どのエージェントが起動したかにかかわらず、あらゆるプロセスを開始の瞬間に捕捉します。各ポリシーにどの対応を割り当てるかは、お客様が選択できます。

顧客レコードのファイルを例に考えてみましょう。エージェントにとって、それを開くのは通常の作業であり、ほとんどの場合は問題ありません。重要なのは、データがその次にどこへ向かうか、そしてエージェントがその過程で自らにどんな権限を与えたかです。マシンの外に出ない読み取りは、そのまま通過します。同じ読み取りの後に、自らの権限を拡大したばかりのエージェントが公開ファイル共有ホストへアップロードすれば、それはインシデントです。

Sysdig AI Defense の Threats ビュー。悪意のある顧客データのエクスポートのアップロードを開き、挙動チェーン、その背後にあるセッション、実行されたアイデンティティを表示しています。AI Defense が捉えた脅威:エクスポートのアップロード、その前にエージェントが自身の設定ファイルへ追加した広範な権限、背後にある3つのセッション、そしてエージェントが代行していた Revenue Operations のアカウント。

エージェントが拒否されると、シェルコマンドや自分で書いたスクリプトなど、別の経路を試します。フックはコマンドを見ることはできますが、スクリプトは見えません。AI Defense は両方を見ます。宛先を解析したコマンドと、開始時点のスクリプトの両方を確認します。

ポリシーをゼロから書く必要はありません。MCP サーバーとツール、シークレットとデータ、破壊的なコマンドなど、エージェントがもたらすリスクに対応する Sysdig のマネージドポリシーから始められます。それぞれ、読んで理解できる Falco ルールとして記述されています。また、初日からブロックを有効にする必要もありません。Sysdig のポリシーはすべて Alert から始まります。つまり、検出した内容を通知するだけで、何も止めません。自社の環境で何が検出されるかを確認してから、重要な操作に対して Block、Confirm、Kill process を選択します。人間による判断を挟みたい操作には、Confirm がエージェント自身の権限確認プロンプトに呼び出しを送るため、開発者は普段の作業場所でそのまま承認または拒否できます。どの操作に2度目の確認が必要かはセキュリティチームが決め、それ以外はすべて通常どおり実行されます。

すべてのリスクが、事前に書かれたルールに当てはまるわけではありません。エージェントは新しいスキルを絶えず身につけます。そのため Sysdig の脅威リサーチのルールは、認証情報のダンプ、永続化、トンネル、リモートアクセスなど、攻撃に似たエージェントの挙動も検知します。 

デモ環境では次のようになります。承認をオフにして実行されている Revenue Operations のエージェントが、顧客データのエクスポートを公開ファイルホストへ送信しようとします。Kill process ポリシーが、アップロードの開始と同時にそれを終了させ、エージェントはその理由を人に伝えます。

セキュリティチームがそこに至った経緯を確認したいときは、セッションリプレイが、そのセッションのツール呼び出しを順番にたどります。検知とキルは、隣の Events の行に表示され、それぞれ発動したルールとポリシーが示されます。

Sysdig AI Defense による1つのエージェントセッションのサマリー。実行されたコマンド、プッシュ先のリポジトリ、指定されたファイル、到達した外部ホストをまとめています。1つのセッションが触れたもの:4つのコマンド、開発者個人のリポジトリへの1回のプッシュ、指定されたファイル、そして呼び出された唯一の外部ホスト。

どのチームがどの業務でどのモデルティアを使っているかを把握する

すべてのエージェントが人に紐付いているため、エージェントが使うすべてのモデルも人に紐付きます。各セッションには、実行されたモデルと、その背後にいる人物とチームが記録されます。トラフィックが AI ゲートウェイを経由するかどうかは関係ありません。 

これは AI の支出にとって重要です。同じ調査結果では、従業員の10人に4人が Opus クラスのモデルしか使っていませんでした。Sysdig AI Defense は、チームごとに、業務の負荷の高さに照らして各人のモデルティアを評価します。軽い作業が最も高価なモデルで動いている場合は、請求書が届く前にリーダーが習慣を改められるよう、フラグを立てます。逆に、重い作業が最も安価なモデルで行われている場合もフラグを立てます。そこでは、業務に対してモデルが軽すぎて困っている人がいるかもしれません。マネージャーは、より適したモデルへ切り替えさせ、成果を高める手助けができます。

開発者を作業から外さずに監査に答える

監査人にエージェントが何をしたのか、誰が背後にいたのかを尋ねられたとき、多くのチームが確認できる場所は1つ、エージェント自身のログだけです。そのログには、多くの漏れがある可能性があります。

カーネルは、あらゆるアクションが必ず通過するオペレーティングシステムの一部であり、確認する場所として適しています。「AIエージェントの実像:1か月・300台の実測データ」では、カーネルが記録した認証情報ファイルの読み取りの82%について、エージェント自身のログにエントリがなく、エージェントのバイナリ自身が行った読み取りの95%についてもエントリがないことが判明しました。その1か月間で、カーネルは260万件のプロセスを記録したのに対し、エージェント自身のログにあったツール呼び出しは37万4,000件でした。エージェントのログは有用な背景情報ですが、単独で監査を支えるには欠落が多すぎます。

Sysdig AI Defense は、カーネルから独自の記録を、デバイスの外で、エージェントが変更できない場所に保持します。Sysdig AI Defense 自身のフックを削除しても、1時間以内に元に戻され、その間もカーネルは記録を続けます。各イベントには、エージェント、アカウント、モデル、セッションが含まれます。各検知には、その背後にあるルールとポリシーが示されます。Sysdig AI Defense があれば、監査でAIについて問われたときには、すでに証拠が保管されており、再構築のために開発者を作業から外す必要はありません。これらの記録を SIEM に転送し、他のセキュリティ証跡と並べて管理することもできます。

フラグが立てられたセッションの Sysdig AI Defense セッションリプレイ。各ステップが、ルール、ポリシー、アイデンティティ、ハーネス、モデルを示すイベントパネルの横に一覧表示されています。フラグが立てられたセッションのすべてのステップを順番に表示し、アップロードのイベントを横に並べて、ルール、ポリシー、そしてその背後のアカウント、ハーネス、モデルを示しています。

エージェントに対する説明責任はランタイムから始まる

取締役会はエージェントが何をしているのかを問い始め、規制当局も問い始めています。Sysdig の CEO である Hatem Naguib は、それをすべての経営幹部が答えられるべき3つの質問にまとめています。

  1. AIが暴走していないことを、どのようにして確認できますか?
  2. どのAIを使っており、その責任は誰にありますか?
  3. 何を証明できますか?

これらのいずれも、エージェント自身のログだけでは答えられません。

Sysdig AI Defense は、Sysdig がクラウド全体で提供しているのと同じ予防、検知、レスポンスをエージェントにもたらします。その根幹にあるのが Falco です。Falco は、Sysdig が2016年に創設したオープンソースのランタイムセキュリティプロジェクトで、2024年に CNCF の Graduated(卒業)プロジェクトとなりました。Falco は2億回以上ダウンロードされ、Fortune 500 の60%以上で使われています。

エージェントは今後も高速になり、その行動はクラウドの奥深くまで及び続けるでしょう。自信を持ってエージェントを拡大していける企業は、先にコントロールを整えた企業です。すべてのエージェントが把握され、所有者が決まり、アイデンティティに紐付いていること。リスクの高い操作が発生した時点で止められること。そして、後からも通用する記録があることです。

About the author

注目のリソース

セキュリティの専門家と一緒に、クラウド防御の最適な方法を探索しよう