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

購読する

すべてのエージェントを把握し、できることを決め、記録を残す

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基盤全体にわたってエージェントを追跡します。

多くのセキュリティチームは、把握している以上のエージェントを運用している可能性があります。マシン約300台を抱えるあるソフトウェア企業は、Sysdig AI Defenseを導入した最初の1か月でそれに気づきました。この期間はすべてのポリシーをAlertで運用したため、ブロックされたものはありません。詳しい調査結果は「A First Look: Under the Hood of AI Agents」に掲載しています。これらのマシンでSysdig AI Defenseが見つけたエージェントの半数は、セキュリティチームが把握していないインスタンスでした。従業員は会社のデバイス上で、シングルサインオン（SSO）を介さずに個人のメールアドレスで登録していました。そしてすべてのデバイスに、少なくとも1つのエージェントハーネスがインストールされ、実際に使われていました。 

シャドーAIは、未承認のエージェントだけではありません。早期導入企業からは、従業員のマシンでOllama、llama.cpp、LM Studioが動いていた、Qwenのコーディングモデルがローカルで提供されていた、モデルがノートPCに直接ダウンロードされていた、といった報告がありました。これらはいずれもAIゲートウェイを通らないため、ゲートウェイには見えません。しかしカーネルには見えます。カーネルは、それぞれのインストール、起動、モデルの取得を捉え、背後にいる担当者に紐づけます。

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

‍

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

許可リストを使えば、あらかじめ不要とわかっているものは簡単に止められます。難しいのは操作そのものの判断です。操作は作業の途中で、しばしばコンマ数秒のうちに起きるからです。こうしたモデルを開発するラボでさえ、自社のエージェントが一線を越えるのを目の当たりにしています。OpenAIとAnthropicの両社は、テスト用のタスクを実行していたエージェントが、第三者が所有する実在のシステムに到達した事例を公表しています。そのため、チェックはエージェントが操作する瞬間に行う必要があります。BlockポリシーとConfirmポリシーは、エージェントのツール呼び出しが実行される前に介入します。Kill processは、どのエージェントが起動したかにかかわらず、あらゆるプロセスを起動の瞬間に捉えます。各ポリシーにどの対応を割り当てるかは、ユーザーが選べます。

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

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

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

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

デモ環境での様子を紹介します。承認をオフにして動いている収益オペレーション担当のエージェントが、顧客データのエクスポートを公開ファイルホストに送ろうとします。Kill processポリシーがアップロードの開始と同時に処理を終了させ、エージェントはその理由を担当者に伝えます。

セキュリティ担当者がそこに至った経緯を確認したい場合は、セッションリプレイでそのセッションのツール呼び出しを順番にたどれます。検知とKillは隣のイベント欄に表示され、それぞれ作動したルールとポリシーが示されます。

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

すべてのエージェントが担当者に紐づくため、そのエージェントが使うモデルも同様に担当者に紐づきます。各セッションには、実行に使ったモデルと、その背後にいる担当者およびチームが記録されます。トラフィックがAIゲートウェイを通るかどうかは関係ありません。 

これはAIの支出管理で重要です。同じ調査結果では、従業員の10人に4人がOpus級のモデルだけを使っていました。Sysdig AI Defenseは、各担当者のモデル階層を、チームごとの業務の負荷と照らして評価します。軽い作業が最も高価なモデルで実行されている場合はそれを指摘するため、請求書が届く前に経営層が習慣を改められます。逆に、重い作業が最も安価なモデルで実行されている場合も指摘します。担当者が、業務に対して軽すぎるモデルで行き詰まっているおそれがあるためです。マネージャーはより適したモデルに切り替えさせ、成果を高める支援ができます。

開発者を作業から外さずに監査に対応する

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

カーネルは、あらゆる操作が通過するオペレーティングシステムの中核であり、確認に適した場所です。「A First Look: Under the Hood of AI Agents」によると、カーネルが記録した認証情報ファイルの読み取りのうち82%は、エージェント自身のログに記録がありませんでした。エージェントのバイナリ自体が行った読み取りでは、95%に記録がありませんでした。この1か月でカーネルが記録したプロセスは260万件でしたが、エージェント自身のログにあるツール呼び出しは37万4,000件でした。エージェントのログは有用な背景情報ですが、欠落が多すぎるため、それだけで監査を支えることはできません。

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

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

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

1. 自社のAIが暴走していないと、どうやって確認できるのか。
2. 自社はどのAIを使っており、その責任は誰にあるのか。
3. 何を証明できるのか。

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

Sysdig AI Defenseは、Sysdigがクラウド全体で提供してきたものと同じ予防、検知、対応をエージェントにもたらします。その土台は、Sysdigが2016年に立ち上げ、2024年にCNCFのGraduatedプロジェクトとなったオープンソースのランタイムセキュリティプロジェクトFalcoです。Falcoのダウンロード数は2億回を超え、フォーチュン500の60%超が利用しています。

エージェントは今後も高速化し、その操作はクラウドのさらに深部へ及んでいきます。自信を持ってエージェントを拡大できる企業は、先にコントロールを整えた企業でしょう。すべてのエージェントを把握して管理者を決め、アイデンティティに紐づけること。危険な操作は発生した時点で止めること。そして、後から検証に耐える記録を残すことです。

自社の環境で試してみてください。無料トライアルを開始して、エージェントが実際に何をしているのかを確かめましょう。macOSとWindowsに対応しています。Sysdig AI DefenseはEDRと並行して動作し、MDMで展開できます。全体像を把握するため、少なくとも10台のマシンへの展開をお勧めします。