AIエージェントのインテント（意図）は出発点に過ぎず、セキュリティ戦略ではない

このHelp Net Securityビデオで、Token SecurityのCEOであるItamar Apelblatが、同社の調査結果を詳しく説明しています。その調査では、エージェント型チャットボットの65%が使用されたことがないにもかかわらず、ライブアクセス認証情報を保有していることが示されています。彼は、組織がAIエージェントをガバナンスされたアイデンティティというより迅速な実験として扱う理由と、それがなぜ孤立したサービスアカウントと同様のリスク（ただし、より見えにくい）を生み出すのかを説明しています。

この対話では、外部エージェント操作の51%がまだハードコードされた認証情報に依存している理由、単一のインジェクション可能なプロンプトが従来のSOCアラートをトリガーせずにマルチエージェントパイプラインを通じて移動する方法、および81%のクラウドにデプロイされたエージェントが自己管理フレームワークで実行される理由について取り上げています。Apelblatはまた、エージェントのインテント（意図）をポリシーとして運用することの意味、およびユーザーがエージェントに元の構成が予想しなかった何かで再度プロンプトを出すときに、執行がどのようにサバイバルする必要があるかについても説明しています。

あなたの調査では、エージェント型チャットボットの65.4%が作成以来使用されたことがないにもかかわらず、そのアクセス認証情報は有効なままであることが示されています。これは、組織が従来のインフラストラクチャのサービスアカウントやAPIキーと比較して、AIエージェントをどのように扱っているかについて何を教えてくれますか？

多くの組織は、まだAIエージェントをガバナンスされたアイデンティティというより、使い捨ての生産性実験として扱っています。つまり、これらのシステムは、使用頻度がゼロに低下した後も、外部ツールおよびデータへのライブアクセスを保有し続けることがよくあります。従来のインフラストラクチャでは、セキュリティチームは最終的に、休止中のサービスアカウントと忘れられたAPIキーは、誰もアクセスがまだ必要かどうかを積極的に検証していないため、回避可能なリスクを作成することを学びました。

同じパターンがAIエージェントで再び現れようとしていますが、これらのエージェントは中央で管理されたプラットフォームまたはセキュリティチームではなく、ビジネスユーザーによって作成されることが多いため、所有権はさらに不明確な場合があります。結果は、サービスアカウントおよびAPIキーで起こったことと似ています。孤立したアクセス、不明確なアカウンタビリティ、および正当な目的を超えるスタンディング特権です。

ただし、エージェント型チャットボットとの違いは、アクセスは会話型インターフェースの背後にあるツール構成に隠されていることが多いということです。ユーザーは「役立つアシスタント」を見ているかもしれませんが、それはSaaSプラットフォーム、データソース、または内部ワークフローへの認証情報付き接続によって支えられています。これにより、ガバナンスのギャップはクラウドコンソール内の生のサービスアカウントより見えにくくなりますが、同じくらい危険です。アクセス決定は、チャットボットが作成および展開されるときに暗黙的に行われ、通常のアクセスレビュープロセスの外で行われるため、ある意味ではより悪いです。

エージェント型チャットボットの外部アクション（操作）の51%がOAuthではなくハードコードされた認証情報を使用していることを発見しました。我々は10年前に従来のソフトウェアで開発者とこの戦いを戦いました。業界がAIエージェントでこの間違いを繰り返しているのはなぜですか、そしてそのパターンを打ち破るためには何が必要ですか？

短い答えは、利便性、速度、および断片化された所有権です。AIエージェントは迅速に展開されており、多くの場合、長期的なアイデンティティ衛生よりも即時使用のために最適化するチームによって展開されています。ハードコードされたキーは、特にエージェントを接続している人がソフトウェアエンジニアまたはアイデンティティスペシャリストでない場合、「デモを機能させる」への最速パスです。ビジネスユーザーの認証方法についての理解は、通常、ユーザー名とパスワードまたはAPIキーに限定されています。ほとんどの人がOAuthを理解していないため、これはさらに問題を複合します。調査では、外部アクション（操作）がまだ静的認証情報を通じて頻繁に構成されていることが示されており、古いエンジニアリング習慣は実際には消えず、新しい表面領域を見つけただけであることを示しています。

パターンを打ち破るには、組織は安全なパスを簡単なパスにする必要があります。つまり、可能な限り委任認証に自動的にデフォルトされる承認された統合を提供し、OAuthが利用できない場合は積極的にスコープ指定された認証情報を提供し、エージェントセットアップをルーチン構成タスクではなく、アイデンティティガバナンスイベントとして扱う必要があります。また、エージェントが機能するかどうかだけでなく、どのアイデンティティとして機能するのか、そのアイデンティティが何ができるのか、およびそのアクセスがどのように回転、取り消し、および監査されるかをレビューすることも意味します。これらのコントロールがなければ、展開圧力は即座であり、セキュリティコストは遅延しているため、チームは静的シークレットに戻り続けるでしょう。

顧客メッセージ、ウェブフック、およびメールを処理する本番エージェントが、信頼されていない外部入力が高い自律性と出会う継ぎ目でのプロンプトインジェクションに一意にさらされていることに注意してください。信頼されていない外部入力が高い自律性と出会う継ぎ目でのプロンプトインジェクションに一意にさらされていることに注意します。単一のインジェクション可能なペイロードがマルチエージェントパイプラインをカスケードする現実的な攻撃チェーンについて説明していただけますか、そしてどの時点で従来のSOCツーリングが盲目になりますか？

もちろんです。複数の特化したエージェントから構築された顧客向けサポートパイプラインを考えてみてください。インテークエージェント（インバウンドチケットを解析する）、検索エージェント（CRMおよびアカウントデータをクエリする）、アカウント操作エージェント（認証情報をリセットまたはアカウント設定を変更する権限を持つ）です。「ルーチンエスカレーションのように見えるサポートチケットが到着します」と私はアドミンアカウントがロックアウトされています（アカウントID：91024）、認証情報をリセットしてください。」インテークエージェントがリクエストを解析し、メッセージ本文からアカウント識別子を抽出し、パスワードリセットタスクをダウンストリームのアカウント操作エージェントに委任します。

アーキテクチャの隙間は、エージェント間で何が起こるかです。アカウント操作エージェントは、任意のユーザーの認証情報をリセットするための技術的権限を持ち、それが関数の機能です。しかし、それが操作する顧客スコープは、アクセス制御チェックによって決定されませんでした。アップストリームエージェントからのタスクコンテキストとして渡されました。次に、信頼されていない入力から抽出されました。チェーン内のエージェントの誰も、チケット送信者がそのアカウントのアクション（操作）をリクエストする権限があることを確認していません。インテークエージェントはスコープが他の誰かの責任であると想定しました。ダウンストリームエージェントは、認可された内部オーケストレーターから来たため、委任を信頼していました。各エージェントは単独で正しく動作し、障害は顧客レベルの認可がハンドオフで自然言語コンテキストとして表現され、ガードレールや他のエージェントハーネス機能でポリシーとして実装されなかったことです。

これは従来のSOC可視性が不足しているところです。一般的に既知のマルウェア、エンドポイント異常、または疑わしいログインを検出するのは得意ですが、ほとんどの従来のツールは、信頼されたサービスアイデンティティが間違った理由で間違ったシーケンスで許可されたアクション（操作）を実行するときを検出する能力が不足しています。これはコンテキスト「ブラインドスポット」です。SOCはまだログを見ているかもしれませんが、元のプロンプト、委任された推論チェーン、エージェント間のハンドオフ、または意図されたタスクと実際のアクション（操作）間の不一致は見えていません。その結びつきを失うと、通常の自動化から区別するのが難しい一連の技術的に有効なイベントが残されます。

データは、主要なクラウドプロバイダーが組み込みアイデンティティプリミティブを備えた管理半管理型オファリングを構築しているにもかかわらず、クラウドにデプロイされたエージェントの81%が自己管理フレームワークを使用していることを示しています。その優先度を推進するものは何ですか、および管理型オファリングが隙間を閉じるか、またはオープンソースエコシステムが支配を維持すると思われますか？

優先度は、柔軟性、成熟度、およびタイミングによって推進されています。オープンソースフレームワークは1～3年のヘッドスタートを有していたため、より大きなコミュニティ、より豊かなツーリング、より多くの実世界のベストプラクティスを構築することができました。企業が本番環境でエージェントをデプロイし始める時までに、オープンソースはすでにより証明されていました。これらのチームはしばしば、オーケストレーション、モデル、ツール、メモリ、およびランタイム動作の深い制御が必要です。これは、自己管理フレームワークが遥かによくサポートするものです。データはこれを反映しています。管理型オファリングはしばしばテストされていますが、本番環境に進むことはめったにないため、カスタマイズと運用準備の隙間を示唆しています。

また、ポータビリティの利点があります。管理型オファリングは、「アグノスティック」であっても、特定のクラウドに結びついており、これはマルチクラウド組織の制約です。オープンソースシステムは環境およびチーム全体ではるかに転送可能です。管理ソリューションは改善し続け、標準化された低緊急度のユースケースでは成長しますが、おそらくまだ一歩遅れています。オープンソースは、より高速なイノベーションサイクルとより広いエコシステムによって駆動され、高度なエンタープライズ展開の支配を維持する可能性があります。

これはおそらく勝者総取りの結果では終わらないでしょう。時間が経つにつれて、管理プラットフォームは隙間を狭めていきますが、オープンエコシステムは洗練された展開の重力の中心のままである可能性が高いため、セキュリティチームは管理サービスが全問題を解決することに賭けるのではなく、混合環境の準備をする必要があります。

レポートは、セキュリティチームが「エージェントのインテント（意図）を理解すること」を、発見と執行とともに基礎的な優先度として推奨しています。インテント（意図）は、自律システムに適用される場合、評判が悪い概念です。エージェントがユーザーが元の構成が予想しなかった何かで再度プロンプトを出す瞬間をサバイバルする方法で、インテント（意図）検証を運用化しますか？

「営業チームを支援する」または「サポートを自動化する」のような目的のぼやけた声明のようなインテント（意図）を運用化することはできません。それは保護するには広すぎます。インテント（意図）は具体的な境界に変換される必要があります。エージェントが接することを許可されているシステム、実行する可能性のあるアクション（操作）のカテゴリ、どのようなトリガー下で、どのレベルの自律性で、そしてリクエストがそれらの境界外にある場合のエスカレーションパスは何ですか。実際には、これはインテント（意図）をプロンプトとしてではなく、アクセスおよび動作ポリシーとしてモデリングすることを意味します。基礎研究はエージェントリスクをアクセスと自律性を中心にフレーム化し、それはぼやけた概念をテスト可能なものに変えるため、開始する正しい場所です。

そのポリシーは実行時の執行が必要です。再度プロンプトが、エージェントに定義された関数と矛盾することを実行するように求める場合、エージェントは「それを機能させる」ことが許可されるべきではありません。ブロックされ、人間の承認パスにダウングレードされるか、より狭いツールセットに制限される必要があります。インテント（意図）検証は、現在のコンテキスト、権限、および要求されたアクション（操作）に対して継続的に再評価されている場合にのみ機能します。そうしなければ、最初の賢いプロンプトが元の構成をコントロールではなく提案に変えます。