今回のHelp Net Securityのインタビューでは、VersaのField CISOであるPrasad Tharippala氏に話を聞きました。同氏は、組織が社内でオープンウェイトモデルを運用する際に見落としがちな点を解説します。GPUインフラのコスト、ライセンスレビュー、人員配置といった隠れたコストに触れつつ、ハードニングとインシデント対応がなぜ導入企業側の責任になるのかを語ってくれました。
さらに、AIエージェントのレッドチーミングについて、何が失敗と判断される結果なのか、そして買い手がエージェントプラットフォームに投げかけるべき5つの質問についても説明しています。90日間と限られた予算しかないチームに向けては、インベントリの整備、影響範囲(ブラストラジアス)の縮小、継続的なテストという優先順位を提示しました。
セキュリティ上の理由から顧客が自社環境でオープンウェイトモデルを運用したいと考える場合、通常見落とされがちなコストや人員要件は何でしょうか。
自社環境でモデルを運用すれば、管理性やデータ主権は向上します。しかし、それだけで導入がより安全になるわけではありません。ハードニング、パッチ適用、アクセス制御、監視、モデル評価、そしてインシデント対応の責任が、運用する組織側に移るだけなのです。
最も見落とされがちなのは、モデルの運用そのものは問題全体のごく一部に過ぎないという点です。実際の運用コストの大半は、モデルを取り巻くあらゆる要素から生じます。GPUインフラ、ネットワーキング、ストレージ、電力・冷却、キャパシティプランニング、オーケストレーション、モデルの更新、監視、セキュリティ管理、データガバナンス、監査証跡、そして継続的な最適化などです。
ライセンスとコンプライアンスのレビューも、予算に組み込まれることがめったにないコストです。オープンウェイトだからといって無制限に使えるわけではありません。多くのオープンウェイトライセンスには利用制限があり、EU AI法のような規制は、大規模モデルにさらなる義務を課します。導入前に誰かがこれをレビューする必要があり、しかもその作業はローンチ後も終わりません。モデルやアダプタが更新されるたびに再検証が必要になるため、一回限りの作業ではなく継続的なコストとなります。
スキルギャップも存在します。AI/MLインフラを理解すると同時に、セキュリティ、ネットワーキング、可観測性、本番運用にも精通した人材が必要です。実務上は、プラットフォームエンジニアリング、MLOps、GPUおよびKubernetesの専門知識、サイト信頼性エンジニアリング、AIセキュリティとレッドチーミング、ID管理とデータガバナンスと、幅広い領域にまたがります。多くの場合、組織は既存のインフラチームやセキュリティチームがこの作業を吸収できると想定してしまいます。しかし、大規模な推論を確実に運用するのはまったく別の専門分野です。これが大幅な遅延を招き、場合によってはプロジェクトが期待されたビジネス価値を一切生み出せないまま終わることもあります。
もう一つ見落とされがちなのが利用率です。GPUは高価なリソースであり、ワークロード管理が不十分だと、大幅なアイドル状態や需要急増時の予測不能なパフォーマンス低下を招きかねません。スケジューリング、クォータ、バッチ処理、キャッシング、モデルルーティング、需要予測はいずれも有効であり、量子化やマルチテナントでのGPU共有といった手法も大きな差を生み出せます。推論リソースをいかに効率的に共有・管理するかによって、経済性は大きく変わり得ます。
戦略性、規律あるプランニング、適切なスキルがあれば、これを機能させることは十分可能です。しかし、この判断を単純な自前運用か外部委託かの二択で決めるべきではありません。データの機密性、主権要件、レイテンシー要件、ワークロードの規模、社内に有するスキル、規制・コンプライアンス要件によって判断すべきです。多くの組織にとって、一部のワークロードは自社で運用し、他はマネージドサービスとして利用するハイブリッドアプローチが、結局のところ現実的な解になっています。
これは最終的に、組織のビジネス目標、セキュリティ態勢、運用の成熟度、規制・コンプライアンス要件に基づいて、CISO、CIO、その他のテクノロジーリーダーが下すべき戦略的判断です。万能な答えは存在しません。
AIエージェントは本番投入前にどのようにレッドチーミングすべきでしょうか。誰が行い、通常どれくらいの期間を要し、何が失敗と判断される結果になるのでしょうか。
エージェントのレッドチーミングは、従来のアプリケーションペネトレーションテストの枠を超える必要があります。エージェントが侵害され得るかどうかだけでなく、侵害または操作された後にそのエージェントが何を実行できるのかもテストしなければなりません。
私であれば、プロンプトインジェクション、間接的プロンプトインジェクション、過剰な権限、データ漏洩、不正なツール利用、権限昇格、安全でないアクション、メモリやコンテキストの操作、そして接続された別システムへの横展開能力をテストします。さらに、メモリやRAGの汚染、悪意あるツール出力、侵害されたコネクタ、認証情報の窃取、エージェント間の信頼関係の悪用、サプライチェーンの脆弱性、リソース枯渇攻撃もリストに加えます。この大部分は、エージェント型アプリケーションに関する現行のOWASPガイダンスやMITRE ATLASと密接に対応しているため、認知されたフレームワークに沿ってテストするのが有効です。
特に指摘しておきたいのは、あるエージェントの出力が2番目、3番目のエージェントに渡された際に何が起こるかという点です。エージェント型システムにおける真のリスクの多くは、単一のエージェントの内部には存在しません。それは受け渡しの部分に潜んでおり、単体では完全に無害に見える出力が、別のエージェントがそれを基に動くことで問題化するのです。
テストはエージェント単体にとどめるべきではありません。基盤となるインフラ、ソフトウェアコンポーネント、API、ID層、LLM、その他の支援コンポーネントについても、セキュリティテストとレッドチーミングを行い、全体のセキュリティ態勢を確立する必要があります。これには攻撃経路だけでなく、人間による承認ステップ、緊急停止やロールバックの仕組みも含めるべきです。こうした制御は、テスト条件下で実際に行使されて初めて意味を持ちます。
この演習には、AIの専門家とセキュリティの専門家、理想的にはそのエージェントを構築していない人物を関わらせるべきです。AIチームはモデルの挙動やエージェント型のワークフローを理解しており、セキュリティチームは攻撃経路、ID管理、アクセス制御、企業リスクを理解しています。
所要期間について普遍的な定義があるべきではありません。比較的単純なエージェントであれば数日で評価できる一方、機密性の高い企業システムに接続された本番エージェントは、反復的なテストに数週間を要することもあります。範囲は、エージェントの入口と出口、アクセスできるデータ、実行できるアクション、それを支えるソフトウェアやインフラのコンポーネントによって決めるべきです。モデル、システムプロンプト、ツール、権限、コネクタに変更があった場合は、その都度ターゲットを絞った再テストを行うべきです。
失敗と判断される結果とは、「モデルが不出来な回答を出した」ということではありません。真の失敗とは、攻撃者がエージェントに定義されたセキュリティ境界を破らせることができてしまう場合です。例えば、アクセス権のないデータへのアクセス、使用が許可されていないツールの呼び出し、認可の回避、機密情報の開示、必要な制御を経ずに重大な影響を持つアクションを実行させることなどです。私はもう一つ条件を加えたいと思います。もし違反が検知や監査証跡を一切トリガーせずに成功してしまうなら、それも失敗であり、むしろより悪質な失敗だと言えます。なぜなら、誰もそれが起きたことにすら気づかないからです。
重要な違いは、エージェントは確率的なモデルと、決定論的なオーケストレーション、ツール、企業の制御を組み合わせたものだという点です。モデルの挙動は確率的であるため、認可と安全性の境界はモデルの外側で強制する必要があります。巧妙に作り込まれた、あるいは操作されたプロンプトによって、エージェントが意図した境界の外で動作してしまう場合があります。まさにそこを検証するのがセキュリティ評価の役割です。
大規模に推論を運用する通信事業者が一貫して見落としていることは何でしょうか。電力か、スキルか、それとももっと分かりにくい何かでしょうか。
電力とGPUキャパシティは分かりやすい懸念事項ですが、より分かりにくい問題は運用上の予測可能性にあると思います。
通信業界の環境は非常に高い可用性と予測可能なパフォーマンスを前提に構築されており、多くの場合エッジロケーションでは電力、冷却、接続性に実質的な制約があります。AI推論は、計算要件、レイテンシー、同時実行性の観点で大きく変動し得るワークロードをもたらします。さらに、モデルとポリシーの一貫した更新を数千のサイトに展開することは、通常の企業がまず対処する必要のない難題を加えます。
課題は、予測可能なサービスレベルを維持しながら、こうしたリソースを割り当て、スケールさせられるかどうかです。AIワークロードは必ずしも予測可能とは限らず、そのことがスケーリング、ガバナンス、リソース割り当て、そして重要なユースケースへのAI採用に関して、さらなる課題を生み出します。
通信事業者は、一般的な企業よりも深刻な形で分離の問題も抱えています。インフラは多くの企業・政府系顧客間で共有されているため、AIワークロード間の分離が弱いと、顧客間でのデータ漏洩につながる現実的な経路になり得ます。さらに、通常の企業には同じ形では適用されないデータ主権や合法的傍受の義務も加わるため、一部の通信事業者がすでに主権型の展開オプションを検討しているのも理解できます。
もう一つの問題は、推論が運用インフラの一部になってしまうことです。AIがネットワーク運用、カスタマーサービス、あるいはセキュリティのワークフローに組み込まれると、障害領域そのものが変化します。
キャパシティ、分離、フェイルオーバー、可観測性、リソース競合について、他の重要なネットワークサービスと同様の考え方で臨む必要があります。同じくらい重要なのは、推論の精度が落ちたり、遅くなったり、低確信度の結果を出したりした場合にどうするかという点です。重要なネットワーク機能やセキュリティ機能については、フォールバックは明確に定義されたポリシー、あるいは人間の判断でなければなりません。運用モデルもそれに合わせて進化させる必要があります。
あるエージェントプラットフォームが「セキュア・バイ・デザイン」かどうかを見極めるために、買い手はどんな3つの質問をすべきでしょうか。
私であれば、これを5つの質問に拡張します。1つ目は「エージェントが侵害されたら何が起きるか」です。セキュリティは、モデルが常に正しく振る舞うことに依存すべきではありません。プラットフォームは、モデルとは独立して権限、分離、ポリシー境界を強制する必要があります。2つ目は「エージェントがアクセスできる対象と実行できるアクションを、正確にコントロールできるか」です。買い手は、きめ細かいID管理、認可、ツール制御、データアクセスポリシー、そしてエージェント・ユーザー・テナント間の強固な分離を求めるべきです。
ここで重要になるのが、すべてのエージェントに対して人間以外のID(ノンヒューマンアイデンティティ)を持たせるという考え方です。エージェントには専用のIDと権限が必要であり、それは特権ユーザーアカウントを管理するのと同じ方法で管理・レビューされるべきであり、そのエージェントが役目を終えた際には明確な形で失効させられるようにしておく必要があります。
3つ目は「エージェントが何をしたか証明できるか」です。エージェントの判断、ツール呼び出し、データアクセス、実行したアクションについて、十分な可視性と監査可能性が必要です。何が起きたのかを再現できなければ、本番環境でエージェントを安全に保つことは極めて困難になります。ベンダーがモデル内部の推論過程や隠れた思考の連鎖まで開示することは期待していません。重要なのは、それ以降の下流にあたる部分、つまりエージェントが行った呼び出しや実行したアクションを再現できるかどうかです。
4つ目は「エージェントのライフサイクル全体をどうガバナンスするか」です。組織は、エージェントのID、権限、RBAC、ポリシー変更、運用上の活動がどのように管理されているか、そして重要な点として、セキュリティやコンプライアンスの目的でどのような証跡が入手可能かを理解しておく必要があります。理想的には、その証跡はベンダーの言葉だけに頼るものではなく、ISO 42001やSOC 2レポートのような独立して検証可能なものであれば、買い手にとってはるかに説得力が増します。
5つ目は「どのセキュリティ責任が自分側に属し、どの責任がプラットフォームプロバイダー側に属するか」です。これはしばしば見落とされます。買い手は、プラットフォームにどのような制御が組み込まれているか、自分たちで実装することが求められているのは何か、そしてプロンプト検証、GenAIファイアウォール、データ損失防止、ID制御、監視といった機能がどのように扱われているかを理解しておく必要があります。
問うべきは「セキュリティ制御を見せてほしい、責任の所在を教えてほしい、そしてその証拠を見せてほしい」ということです。どこまで踏み込めるか、見てみましょう。
セキュリティチームに90日間と限られた予算しかないものの、環境内ではすでにエージェントが稼働している場合、何を第一に、第二に、第三に優先すべきでしょうか。
第一に、可視性とインベントリの整備です。これはほぼあらゆるセキュリティのシナリオにおける最初のステップです。インベントリを正確に把握してください。どんなエージェントが存在し、誰が所有し、どのモデルを使い、どのデータにどれくらいの期間アクセスでき、どんなツールを呼び出せ、どんな権限を持っているのかを把握します。後回しにせず、その過程でリスクに応じて優先順位を付けていきます。誰も構築を覚えていないようなエージェントが、持つべきでないアクセス権を持って見つかった場合は、他の何よりも先にまずそれを停止させてください。見えないものは守れません。そして限られた予算の中では、このステップと次のステップの大半がポリシーと設定の作業である点に注目する価値があります。どちらも新規の資本投資を必要としないからこそ、最優先に来るのです。
第二に、影響範囲(ブラストラジアス)の縮小です。最小権限の原則を適用し、エージェントを分離し、ツールやデータへのアクセスを制限し、影響の大きいアクションには制御を課してください。エージェントが取り返しのつかないアクションを実行する前に人間の承認を必須にすることは、ここで利用できる最も安価かつ迅速な制御の一つであり、見落とされがちな対策でもあります。私であれば、エージェントが実行できることそのものを絞り込むことを優先します。ここでこそ、ゼロトラストネットワークアクセスや東西トラフィック制御といった原則が特に重要になります。
適切に実装されたSASEアーキテクチャは、DLPやネットワークセグメンテーションと組み合わせることで、継続的なポリシー適用とトラフィック検証を提供し、ワークロードをセグメント化し、エージェントやその依存関係の一部が侵害された際の影響範囲を縮小できます。これは、すべてのエージェントワークフローを単独で保護する万能ツールというわけではありません。それぞれが適所にはまる一連の制御群です。目指すべきは、侵害されたエージェントが自動的に他のシステムや他のエージェントへの侵入経路になってしまわないようにすることです。
これは、私たちが「パーベイシブセキュリティ」と呼ぶ、より広範なサイバーセキュリティの変化を反映しています。組織には、エンドポイント、ID管理、クラウド、セキュリティ運用、アプリケーションセキュリティ、ネットワーク/SASEにまたがる、各領域で最良の少数精鋭のプラットフォーム群が必要です。それらが可視性とコンテキストを共有し、リアルタイムで制御を連携させることで、脅威を未然に防ぎ、突破された脅威が拡散する前に封じ込めることが可能になります。
第三に、継続的なテストと監視です。ステップ1で洗い出したリスクが最も高いエージェントから優先的にレッドチーミングを行い、ロギングと行動監視の仕組みを確立し、エージェント関連インシデントへの対応手順を定義してください。セキュリティチームは、モデル、プロンプト、ツール、連携先が変化するにつれ、エージェントの挙動も変化していくものと想定すべきです。したがって、セキュリティテストを一度きりの認証作業として扱うことはできません。それはエージェントのライフサイクルの一部として組み込まれる必要があります。
組織は、AIエージェントを単なるソフトウェアアプリケーションとして扱うのをやめるべきです。エージェントがIDを持ち、企業データへのアクセス権とアクションを実行する能力を備えた時点で、それは特権を持つデジタルワーカーにかなり近い存在になります。セキュリティアーキテクチャは、その現実を反映したものでなければなりません。
ハルシネーションや誤った判断は、今後も起こり得るものとして残り続けます。目指すべきは、誤った判断や操作されたプロンプト、あるいは侵害されたエージェントが、自動的に重大な機能障害や影響範囲の大きいセキュリティインシデントへと発展してしまわないよう、エージェントの周囲に十分な制御を構築しておくことです。
翻訳元: https://www.helpnetsecurity.com/2026/08/28/prasad-tharippala-versa-securing-ai-agents/
