Kindo、不要なAIエージェントの実行を削減するDeep Hat Siftを発表

セキュリティアラートやログの各エントリーをすべて読み取るAIエージェントは、何も対応する必要がないと結論づけた場合でもコストが発生する。企業規模の処理量では、こうした特段の対応を要しない調査自体が、相当な業務負荷になり得る。KindoはDeep Hat Siftを発表した。これは、大規模なモデルが処理を始める前に、受信イベントのうちエージェントを実行する価値があるものを判定するためのモデルだ。

10月28日に発表されたSiftは、対象エージェントの判定結果から学習し、そのエージェントなら通常は除外するイベントをフィルタリングする。製品はイベントを除外せずに観察するところから始まり、担当者がフィルタリング案を確認してしきい値を承認するまでは、すべてのイベントが引き続きエージェントに届く。

このアプローチは、より安価な言語モデルを選ぶのとは異なるコスト管理の仕組みを導入する。個々の調査の費用を下げるのではなく、対応が必要になる可能性の低い調査を回避することをSiftは目指す。その有効性は、判定の精度と、どのイベントを除外するかを定める制御の両方に左右される。

言語モデルの前段に置く意思決定モデル

KindoはDeep Hat Siftを、システム1型の意思決定モデルと説明している。これは、応答を生成するのではなく、選別に関する問いに答える高速で低コストのモデルだ。各モデルは特定の情報源、対象エージェント、フィルタリングタスクに割り当てられ、その学習内容は、実際に対応する業務を反映する。

この個別性は重要だ。セキュリティ調査に関係するイベントでも、サービスデスクの業務には関係しない場合がある。Siftは、対象エージェントがどのイベントを除外するかを学習する。その際、エージェントが返す判定結果を学習の手掛かりとして用いる。Kindoによれば、これにより、ストリームごとに人手でラベル付けする別個のプロジェクトが不要になる。

初期導入では、シャドーモードで稼働する。エージェントがすべてのイベントを引き続き確認する間に、Siftは受信イベントをスコアリングし、システムが予測とエージェントの判定を比較できるようにする。フィルタリングを始める前に、運用担当者は自社データを使って、どのイベントが除外されるはずだったかをプレビューできる。

その後、担当者がしきい値を承認し、理由を書面で示す必要がある。これにより、モデルをインストールすれば自動的に有効化されるのではなく、許容できるフィルタリングのあり方を決める権限が、その業務を担うチームに置かれる。

サンプリングとフェイルオープン制御で見逃しに対処

フィルタリングには、難しい測定上の問題が伴う。イベントがエージェントに届かなかった場合、そのイベントを処理すべきだったかどうかをチームはどう判断すればよいのか。Siftは、通常なら除外するイベントのランダムサンプルを引き続き送信する。そのサンプルに対するエージェントの判定を、見逃し率の継続的な測定に反映できる。

製品ページでは、比較の基準が明示されている。再現率と見逃し率は、エージェントの判定を基準に測定される。これらの指標は、Siftがそのエージェントの判定をどの程度忠実に再現しているかを示す。ただし、エージェント自体があらゆるセキュリティインシデントや運用上の問題を正しく特定しているかどうかを、独立して証明するものではない。

Kindoによれば、品質が低下した場合、Siftはフェイルオープンし、イベントの抑制を続けるのではなく、エージェントによる確認に戻す。また同社は、急増時にシステムをシャドーモードへ戻せる稼働量の上限も設けている。フィルタリングされたイベントと承認の判断は記録され、チームは何が、なぜ除外されたのかを確認できる。

「担当者がしきい値を承認するまで、何もフィルタリングしません。品質が低下した場合はフェイルオープンし、すべてのイベントをLLMによる判断に回します」と、KindoのDeep Hat SiftエンジニアであるTroy Presleyは発表の中で述べた。

こうした仕組みはトレードオフをなくすのではなく、明らかにする。より保守的なフィルタリングなら、実行回数の削減は少なくなる一方で、網羅性を保てる。より積極的にフィルタリングすれば、より多くの作業を回避できる可能性があるが、その分、サンプリングやドリフト検出、後続のエージェントの品質がいっそう重要になる。

アラート、チケット、継続的なログストリーム向けに設計

今回の発表で対象となるのは、受信量が多い一方、対応を要する割合が低い業務だ。Kindoは、SIEMやエンドポイント検知のアラート、チケットキュー、報告されたフィッシングの申告、システムログやネットワークログ、Kafkaなどのプラットフォームからのストリームを挙げている。監視対象の情報源には、Splunk、Datadog、New Relicが含まれる。

Siftは、こうした情報源のシステムを置き換えるのではなく、エージェントの前段に配置される。セキュリティプラットフォームは引き続き検知結果を生成し、チケット管理システムは引き続きチケットをキューに保持する。また、エージェントは、届いたケースへの対応を引き続き担う。新たなレイヤーは、どのイベントが追加のAI処理を開始するかを判断する。

同じ仕組みは、取引やポリシーのストリームを確認する財務・コンプライアンス業務にも適用できる可能性がある。ここでも、確認対象となるイベントを選ぶことと、不正検知やコンプライアンス上の判定を行うことは別の作業だ。対象エージェントと、それを取り巻く業務プロセスも、結果を左右する重要な要素である。

SiftはKindoのエージェント管理プラットフォームにどう組み込まれるか

Kindoのより広範なプラットフォームは、セキュリティ、インフラ、IT運用のための企業システムとエージェントを連携させる。実行機能に、コンテキスト、権限、運用上の監督機能を組み合わせ、モデルの選定後にチームが業務を管理する場を提供する。

同社のウェブサイトでは、エージェント、所有者、チームごとのエージェントの所有権、アクセス方針、コストの帰属について説明しています。Siftは、そのワークフローのより早い段階に制御機能を追加し、イベントによってエージェントを実行するかどうかを判断します。これにより、技術的なフィルタリングの判断が、どのワークロードによって推論コストが発生しているかという運用上の課題と結び付きます。

発表によると、Deep Hat Siftは現在、オンプレミス、自社管理型クラウド、Kindoのクラウド、およびエアギャップ環境で利用できます。スコアリングはKindoがインストールされている場所で実行され、モデルへの呼び出しはプラットフォームを通じて管理されます。この製品はKindoのエージェントと連携します。

削減効果はイベントの流れによって異なる

Kindoは、Siftによる削減率の一般的な数値も、あらゆる状況に適用できる精度のベンチマークも提示していません。その代わり、製品ページでは、各チームが自社のイベントを使って、どのイベントが処理対象から除外されるかを事前に確認するよう案内しています。これは導入を検討する企業にとって重要な違いです。経済的な効果は、イベントの量、回避できる実行1回あたりのコスト、対応が必要なイベントの割合、そしてチームが受け入れる運用上のしきい値によって決まります。

ノイズの多いイベントストリームでは、不要なエージェントの実行を避けることで、継続的なAIレビューをより手頃なコストで実施できる可能性があります。一方、イベントを見逃した場合に重大な結果を招くストリームでは、サンプリングやエスカレーションの制御も推論コストと同じくらい重要になります。Deep Hat Siftは、こうした判断をエージェントのワークフローに組み込み、イベントをどのモデルに処理させるかではなく、そもそもそのモデルで処理する必要があるのかという問いへと焦点を移します。