Tenable Hexa AI のエージェントハーネス: Tenable が AI エージェントの暴走を防ぐ仕組み

Tenable がエージェント型 LLM を「信頼できない内部関係者」として位置付ける理由と、本番環境のセキュリティに変更を加える AI エージェントをどのように制御・監視しているのかをご紹介します。

キーポイント

1. AI モデルはデータを迅速に理解できますが、ビジネスまでは理解できません。 最新の AI モデルは推論に優れていますが、組織固有の環境や、誰にどのような権限があるかを自動的に理解できるわけではありません。「ハーネス」は、AI のインテリジェンスを組織に応じた安全で制御されたアクションへと変換する、専用に構築されたレイヤーです。
2. AI には監視役が必要です。 Tenable は、自社の AI エージェントを「信頼できない内部関係者」と位置づけています。AI の自己統制に頼るのではなく、ハーネスが AI の参照や実行ができる範囲を厳格に制限し、環境に変更が加えられる前に人間が必ず確認・承認する仕組みを確保しています。
3. 信頼には証拠が不可欠です。ハーネスは、AI が提案または実行するすべてのアクションを完全に記録し、監査証跡を提供することで、制御を失うことなく AI に実務を安心して任せられるようにします。

どのセキュリティベンダーも AI エージェントを提供しています。いずれも、デモでは見事に動作します。デモは壊れても問題のないデータに対して実行されるため、そうなるのも当然でしょう。

べンダーに AI エージェントについて尋ねるべき本当の質問は、デモの後にこそ出てきます。

• エージェントが誤った判断をした場合の影響は?
• エージェントを不正操作するように設計されたプロンプトが入力された場合の影響は?
• エージェントが自社の環境に変更を加えた場合、何を実行したのか、誰がそのアクションを承認したのかについて、事後にどのような証跡が残るのか?

Tenable One サイバーエクスポージャー管理プラットフォームのエージェント型 AI エンジンである Tenable Hexa AI の開発において、Tenable は見過ごされがちでありながら極めて重要な課題に取り組みました。それは、本番データをリスクにさらすことなく AI の判断を安全に実際の変更へと反映するガバナンス層、すなわち基盤インフラの構築です。

Tenable ではこの層をハーネスと呼び、モデルが動作するランタイム制御環境と位置付けています。ハーネスは次の点を決定します。

• モデルが参照できる文脈
• モデルが呼び出せるツール
• アクション実行前に検証すべき事項
• 人間による承認が必要なタイミング
• アクション実行後に記録される内容

モデルが推論を行い、ハーネスが境界を守ります。

モデルは、サブスクリプションで利用できる部分です。ハーネスは構築が必要な部分であり、エージェント型 AI 機能を構築するための作業の大部分を占めています。 

本ブログでは、Tenable Hexa AI 向けのエージェントハーネスを構築する中で当社が得た知見をご紹介します。

エージェント型 AI: ハーネスがない場合に起こる問題

AI リスクについて抽象的な警告を並べるのは簡単ですが、実感が湧かなければ無視されがちです。そこで、当社の開発現場で実際に起きた問題をご紹介します。実際の失敗は、理論上想定されるような劇的なものではなく、もっと地味でありながら、重要な教訓を示すものでした。

1. AI エージェントが権限を逸脱して動作。 エージェントに「重大項目をクリーンアップして」といった指示を出すのは、あまりに曖昧です。深刻度が「重大」の検出結果と、「重大」と評価された資産は異なるオブジェクトであり、「クリーンアップ」が意味する処理も、修復なのか、リスクの受容なのか、それとも完全な削除なのか不明瞭です。「有能」なモデルは、その中から 1 つを選択し、リクエストしたユーザーが変更はおろか閲覧すらできない資産に対しても一括変更を計画できてしまいます。モデルには、誰がリクエストしているのかという認識がないのです。組織の権限モデルを把握しておらず、それを自ら推測することもありません。
2. モデルは顧客自身の環境について、自信満々に、誤った内容を回答。 実際にはタグが存在しているにもかかわらず、タグが存在しないとユーザーに回答しました。IP アドレスによる資産の検索を見落とすこともありました。プラットフォームがコロンを想定している箇所でアンダースコアを使用するなど誤ったタグ形式を用いた上に、その失敗をデータが存在しないためだと報告。インターネット上のあらゆる情報を読み込んでいるモデルであっても、組織のテナントのデータまでは読み込んでいません。止めなければ、その知識の空白をもっともらしい作り話で埋めてしまいます。
3. 単純なクエリでのつまづき。 相対的な時間範囲がセッションをクラッシュさせました。5,000 件を超える資産を対象とするクエリでは、文脈ウィンドウの上限に達し、段階的にパフォーマンスを低下させるのではなく完全に処理が失敗しました。「ソースに ServiceNow を含むすべての資産」のような範囲指定のないフィルターは、システムのどこかが限界に達するまで実行され続けました。
4. 抽象的な要求への対応に失敗。 細かく分解されたリクエストであれば正常に処理できるのに対して、「週次のセキュリティ態勢の要約を作成して」といったリクエストは失敗しました。モデルが大まかな目的を、回答に必要な範囲を絞った一連のクエリへと確実に分解できなかったためです。返っってきたのは曖昧な拒否であり、これは誤った回答よりも厄介です。ユーザーは、製品に対応能力がないのか、リクエストの表現が不適切だったのかを判別できないからです。
5. 実行可能なタスクを拒否。 ルーティングとスコープのロジックが導入される前は、モデルは明らかに実行可能なタスクでさえ拒否していました。過剰な拒否は実際に起こり得る障害モードであり、他の問題を修正しようとする過程で容易に発生します。
6. 修正の過剰な調整による新たな障害の発生。 これは最も予測しにくい教訓であり、モデル自体からではなく、当社側の作業から生じたものでした。初期のセーフティフィルタリングは保守的に調整されており、保守的なフィルタリングは誤検知を生じさせます。また、誤検知はその原因となったリクエスト内にとどまらず、セッションの残りの処理にも引き継がれる可能性がありました。ガバナンスは厳しく調整しすぎると、存在しない場合と同様に確実に機能不全に陥ります。しかも、ユーザーは過度に慎重な制限を統制ではなく不具合として受け止めてしまうため、より混乱を招く形で失敗することになります。調整は一度設定して終わりではなく、継続的な作業です。

これらすべての上位には、セキュリティに特有のカテゴリが存在します。ホスト名、証明書フィールド、サービスバナー、検出結果の説明など、セキュリティプラットフォーム内のデータの多くは、信頼できない人物によって一部が作成されています。 

ホスト名を侵害できる攻撃者はそこに文章を含めることができ、そのフィールドを文脈として読み取るモデルは、その文章を指示として解釈してしまう可能性があります。自社環境から届くテキストは、決して中立な入力ではありません。セキュリティの世界では、セキュリティデータそのものがアタックサーフェスであり、これはエージェントが導入される他のほとんどの領域には存在しないものです。

エージェントハーネスの設計思想: 信頼を前提としない

当社は、セキュリティチームが人間やサービスアカウントに対してすでに運用している一連のコア設計原則を採用しました。常時信頼を前提としない。最小権限を付与する。 結果を伴うあらゆる操作を検証する。すべてを記録する。

これを自律型 AI エージェントに適用すると、制御機能はモデルの内部ではなく外部に配置されることを意味します。モデルに適切に動作するよう指示することは制御にはなりません。指示はあくまで入力であり、入力は上書きされたり操作されたりする可能性があるためです。そこでハーネスが境界を担います。ハーネスは、エージェントが受け取る文脈、呼び出し可能なツール、提案されたアクションの妥当性、人間による承認のタイミング、アクション実行時に記録される内容を決定します。

「常時信頼を前提としない」という設計姿勢の優れた点は、モデルの品質に依存しないため、モデルをアップグレードしても有効性を維持できることです。今後どのようなモデルが登場したとしても、アクションを実行する瞬間にその意図を検証できない主体であることに変わりはありません。

ハーネスを介したリクエストのエンドツーエンド処理

ハーネスの仕組みを説明するわかりやすい方法は、1 つのリクエストが処理される流れを順に追うことです。悪用が確認されている Chrome の脆弱性、その脆弱なバージョンの Chrome を実行している一連の Mac 端末、そしてエージェント型 LLM のプロンプトに「パッチを適用」と入力するセキュリティ担当者の例を考えてみましょう。

何よりもまずグラウンディング。 エージェントには、記憶に基づいてプラットフォームの事実を述べないよう指示されています。環境に関するすべての主張はツールの応答に基づく必要があり、ツールから返されなかった情報をエージェントが主張することはありません。前述の理由から、指示単体では統制として弱いため、指示単独に頼るのではなく、ツールにグラウンディングされた応答生成と組み合わせて使用されます。これらを組み合わせることで、確信を持って誤った情報を捏造する問題の大部分が解消されます。

ルーティングと分解。 すべてのステップに同じモデルを用いる必要はありません。低コストな分類や検索は高速なモデルに、複数ステップの計画策定は推論モデルに割り当て、目的はそれぞれが限定的な役割を担うスコープ化されたサブエージェントに分解されます。

• 影響を受ける資産の列挙
• 管理対象デバイスの特定
• CVE と修正バージョンのマッピング
• そのバージョンを提供するパッチ定義の特定

抽象的なリクエストを機能させるのはこの分解であり、これはオーケストレーションロジックであって、モデルの動作ではありません。

再帰とステップバジェット。 タスクを生成するサブエージェントには境界の設定が必要です。そうでなければ、外部から停止されるまで推論ループが時間とコストを消費し続けることになります。最大トークン数を制限し、多層的な再帰制限を適用するとともに、処理が完全に失敗するのではなく部分的な回答へと適切にフォールバックするステップバジェットを設けています。長時間待たされた後に何も返されないよりも、一部だけでも結果が返される方が優れた結果と言えます。

プロンプトではなくツール境界での承認。 ツール呼び出しはすべてパーミッションミドルウェアを経由し、実行前に不正アクセスを拒否します。AI エージェントは起動したユーザーの権限に基づいて動作し、それ以上の権限に昇格することはありません。つまり、「エージェントに何ができるか」に対する答えは、まさに「このユーザーに何ができるか」ということになります。

規模によって対応方法も変わります。単一の資産の変更と数千もの資産に及ぶ操作とではリスクが異なるため、影響範囲が広がるほどハードルが高くなります。大規模な操作では、対象範囲全体を列挙して明示的な承認を得る必要があります。管理者がそのテナントに対して有効にしていない限り利用できない機能もあるため、単にブロックされていないだけでなく、機能を明示的に許可する必要があります。

すべての呼び出しに対する双方向のガードレール。 コンテンツのチェックは呼び出しごとに 2 回実行され、モデルが入力を受け取る前に 1 回、モデルが出力を生成した後に 1 回行われます。入力時にユーザーのプロンプトのみをスクリーニングするだけでは、重要な問題の多くを見落としてしまいます。リスクの高いコンテンツは通常、入力している人物からではなく環境から届くためです。

実際に起きてみなければ想像しにくいケースもあります。検出事項を正しく要約しただけなのに、その内容がインジェクションフィルターに抵触することがあります。この場合、エージェントは自身の出力が制御によってブロックされないよう、表現を言い換える必要があります。アップロードは検証され、マクロが有効なスプレッドシートは拒否されます。

承認ゲート。 状態を変更する前に、エージェントは処理を停止し、影響を受けるデバイスの数と ID、具体的な変更ポリシー、デプロイメント期間、潜在的な影響範囲、そしてこのアクションが自動でロールバックされない旨を明記した提案を作成します。ユーザーは変更の対象範囲を絞り込んだり広げたりできるほか、すべての変更を一括して拒否することもできます。すべての変更の適用を拒否した場合、その決定は維持され、エージェントが次のターンで再度確認を求めてくることはありません。承認が得られて初めて、承認されたデバイスのみを含むグループを作成し、ポリシーを実行して、確認のための再スキャンをスケジュールします。

Tenable の承認ゲートは、お客様から最も高く評価されている機能です。早期アクセスをご利用のお客様からは、本番データをリスクにさらすことへの懸念から、Tenable Hexa AI の導入をためらっていたという声がありました。その製品を信頼できるとお客様に確信していただく決め手となったのが、この承認ゲートです。

全プロセスを通じた来歴追跡と監査。 すべての呼び出しで、トークンイベントと決定イベントが当社のストリーミングや監視パイプラインに出力されます。すべての実行をトレースし、リクエスト識別子ですべての情報を相関付けます。会話履歴は永続的に保持され、エージェントが実行したアクションには発生元のスタンプが付与されるため、記録上で人間によるアクションと区別できます。たとえば、6 週間後に誰がなぜ変更を承認したのかを確認したい場合でも、その質問に対する明確な回答が得られます。

知られざるエージェントハーネスの一面: 正常な動作を継続的に確認

どの個別統制よりもエンジニアリングのリソースを消費する問題があります。それは、モデルが常に変化することです。プロンプトの修正、ツールの変更、モデルの差し替えを行うたびに、品質や安全性が知らぬ間に低下する可能性があり、製品を使用しているだけではそれを検知できません。お客様が機能しなくなったエッジケースを発見するまでは、何の問題もないように見えてしまうのです。

進化する AI モデルによって生じる課題に対処するため、Tenable は変更ごとに、機能面と安全性に関する 2 つの独立した評価スイートを実行しています。Tenable Hexa AI で厳選された 100 件以上のケースは、決定論的なルールチェックから Model-as-a-Judge によるスコアリング、一対比較に至るまで、さまざまな測定手法を用いる約 12 種類のエバリュエーター (単一の自動チェック) 全体にわたってスコアリングされます。

すべてのケースは、分離された再現可能な環境で模擬ユーザーが実際のエージェントに対して行うマルチターンの対話です。これにより、複数回の実行結果を比較でき、ドリフトも単なる個別の体験談ではなく、固定されたベースラインに対する測定可能な低下として現れます。絶対的なルールが 1 つあります。他の項目でどれほど高いスコアを獲得していたとしても、予期しない破壊的な呼び出しを行う実行はすべて失敗と判定されます。テストは継続的インテグレーションで実行され、結果は自動的にトリアージされてチームのチャンネルに投稿されます。

2 つの要素によって、このスイートは時間の経過とともに強化されていきます。ユーザーの評価が低かった実際の対話は新しいケースとしてスイートに追加されるため、リリースごとにカバレッジが強化されます。また、このスイートはモデルに依存しないため、新しい最先端の AI モデルを一定の基準で評価し、推測ではなく確かな根拠に基づいて導入できます。

エージェントハーネスが切り拓く可能性

ハーネスは、AI の能力に対する制約のように聞こえるかもしれません。しかし実際には、これこそがタスクの委任を可能にする不可欠な要素です。

ハーネスがなければ、自律型 AI エージェントは読み取り専用のツールにすぎません。質問を投げかけ、その作業を検証することはできますが、それは有用ではあっても、優れたダッシュボードとほぼ同程度の価値しかありません。何かを変更させたいと思った瞬間、議論はもっぱらリスクの問題になり、ほとんどの組織はそこで当然ながら立ち止まってしまいます。

エージェントハーネスを導入することで、次の 3 つが実現します。

1. 重要な業務を任せることができます。トリアージや要約にとどまらず、対象範囲の特定、実行、検証まで任せられます。人間がアクションを承認するポイントが明確に定められており、モデルに遵守を求めるのではなくモデルの外部で境界線が適用されるためです。
2. 保証ではなく証拠が得られます。何が提案され、誰によって承認され、どのような結果になったかの記録は、監査人、規制当局、取締役会に提出できる証拠となります。エージェント型システムに対する信頼は、エンジニアリングの問題であると同時に、ドキュメンテーションの問題でもあります。
3. 独自のペースで自律性を拡大できます。 スコープはプラットフォーム全体ではなくタスクごとに設定されるため、全体をゼロか百かで決める必要はありません。まずは元に戻すことが可能なタスクから開始して動作を確認し、準備が整った段階で適用範囲を広げることができます。

エージェントハーネスには、見落とされがちなもう 1 つのメリットがあります。ハーネスがモデルの外部で境界を維持し、評価スイートがモデルから独立しているため、より優れたモデルへの移行は、信頼関係の再交渉ではなく単なるアップグレードとなります。Tenable Hexa AI は、お客様にゼロから信頼関係を再構築していただく必要なく、こうしたモデルを採用できます。

デモ後の質問への立ち返り 

Tenable を含むベンダーのエージェント型機能を評価する際は、以下の質問について確認することをお勧めします。

• 要求者に実行権限のないアクションを阻止する仕組みとは?
• 攻撃者の影響を受けたデータに隠された指示はどのように処理されるか? 
• クエリが大きすぎる場合や目的が曖昧すぎる場合、エージェントはどのように動作するか? 
• エージェントがアクションを実行した後、どのような証拠が残るのか?
• セキュリティベンダーが前回モデルを変更した際、品質が低下していないと、どのように確認しているのか? たとえば、エージェントは拒否すべき要求を適切に拒否し、実際のデータに基づいて回答し、変更を加える前に停止して承認を求めているか? (注意: 固定したベースラインに対するスコアで示せないなら、それは単なる希望的観測にすぎません。)

最先端の AI モデルを利用できること自体が、エージェント型セキュリティを機能させるわけではありません。それを可能にするのは、モデルを取り巻くすべての要素です。それこそがハーネスであり、単に監視するだけのエージェントと、実際に業務を任せられるエージェントの違いを生み出します。これまでご紹介したすべての仕組みは、Tenable Hexa AI を後者のエージェントにするために当社が構築したものです。

もっと詳しく

• Claude Mythos Preview を体験した 30 日間: Tenable が自社のセキュリティプログラムをどのように適応させたか、そして次は貴社の番である理由
• Tenable Hexa AI
• Tenable Hexa AI: エクスポージャー管理のための自律型 AI が登場
• Tenable Hexa AI でサイバーセキュリティに自律型 AI を導入: マシンスピードでサイバーリスク削減