3つのAIセキュリティ上の誤りが企業を危険にさらす

Google Newsは、企業がもはや理論上のAIリスクとして扱えなくなった3つの問題を指摘するInfoWorldの記事を取り上げた。信頼されたモデルが敵対的な指示を処理し、エージェントが過剰な権限を引き継ぎ、人間向けの承認画面が実際に認可しようとしている操作を覆い隠す可能性がある。

この見出しが重要なのは、企業が会話型アシスタントから、ファイルを読み、アプリケーションを呼び出し、コードを変更し、業務プロセスを起動するシステムへ移行しているためだ。この移行により、誤った回答は潜在的なセキュリティインシデントへと変わる。中心となる対立は明確である。AIの迅速な導入と、各システムが閲覧・実行できる範囲に対する強制可能な制限とのせめぎ合いだ。

問題は、すべてのモデルが突然悪意を持つようになったことではない。確率的なソフトウェアがデータ、ユーザー、認証情報、ツールの間に介在すると、従来の統制がしばしば意味を失うことにある。Microsoft、Google、Amazon、Anthropic、Cursorなどのベンダーに関する最近の事例は、この隔たりがいかに速やかに実運用上の問題へ発展し得るかを示している。

Google Newsの警告が焦点を当てるのは知能ではなく統制

企業にとって最も危険な誤りは、モデルの振る舞いを主要なセキュリティ境界として扱うことである。

Google Newsの掲載記事は、企業を悩ませる3つのセキュリティ上の誤りを扱ったInfoWorldの見出しを示している。季節的な表現以上に重要なのは、企業がこうした接続の境界を再定義する前に、言語モデルを価値の高いシステムへ接続しているという、より大きな兆候だ。

かつてチャットボットは、人が確認するためのテキストを生成していた。現在のAIエージェントは、呼び出すツールを決め、引数を組み立て、保存済みの認証情報を使い、複数のステップにまたがって処理を継続できる。この到達範囲の拡大により、モデルの誤りはアプリケーションセキュリティの問題へと変わる。

組織はしばしば、システムプロンプトにより多くの指示を追加して対応する。モデルに対し、機密情報を開示しないこと、信頼できない命令に従わないこと、危険な操作を行わないことを求める。こうした指示は振る舞いを改善し得るが、強制可能な認可境界を作るものではない。

その理由を説明するのがプロンプトインジェクションだ。プロンプトインジェクションとは、モデルに意図しない指示へ従わせる悪意ある、または誤解を招くコンテンツである。間接的なインジェクションは、メール、Webページ、文書、Issue、リポジトリなど、モデルが取得する資料を通じて侵入する。

モデルは、信頼された指示と信頼できないコンテンツの両方を、同じ自然言語インターフェースを通じて解釈しなければならない。ある文脈では文章をデータとして認識しながら、別の場所では似たテキストをコマンドとして扱うことがある。どのようなプロンプトも、周辺アプリケーションによって付与された権限を変更することはできない。

OWASPのリスク一覧は、2025年版の大規模言語モデルアプリケーションに関するリスクの最上位にプロンプトインジェクションを置いている。また、機密情報の開示、サプライチェーンの弱点、不適切な出力処理、過剰なエージェンシーも個別に挙げている。

この区分は有益な教訓を示す。プロンプトインジェクションはしばしば引き金となるが、その結果を決めるのは周辺アーキテクチャである。秘密情報も書き込み権限も持たない、インジェクションを受けたアシスタントの影響範囲は限定的だ。同じ入力でも、エージェントがメールを読み、非公開データを照会し、コードを実行し、クラウドリソースを変更できる場合には重大な問題となる。

このため、モデルの推論能力が向上しても、自動的にセキュリティが向上するわけではない。より高性能なモデルは正当な計画をより確実に実行できる。その一方で、攻撃者が計画を逸らした後には、接続されたシステムをより効果的に操作できる可能性もある。

したがって企業は、AIをより大きなセキュリティシステム内の信頼できない意思決定コンポーネントとして評価すべきである。モデルは操作を提案できるが、その操作が許可されるかどうかは決定論的な統制が判断しなければならない。こうした統制には、本人確認、ポリシーの強制、入力の分離、出力の検証が含まれる。

この原則は、チームが障害を調査する方法も変える。モデルがツールを持つ場合、不自然な回答は単なる品質問題ではない。レビュー担当者は、どのIDがリクエストを実行したのか、どのデータがコンテキストに入ったのか、どの外部状態が変更されたのかを問う必要がある。

見出しが示す3つの誤りは、この欠けた統制プレーンによってつながっている。企業はモデルを信頼し、その周囲の権限を信頼し、ユーザーに表示される承認プロセスを信頼している。各層は、正常に見えながら失敗する可能性がある。

誤りその1：モデルのガードレールをセキュリティ統制として扱う

モデルによる拒否は行動上の選好にすぎず、アクセス制御ルールは強制可能な判断である。

企業はしばしば、モデルが禁止されたリクエストを拒否するかどうかを試すことからAIセキュリティレビューを始める。この作業には、特に不正利用の防止やポリシー遵守の面で価値がある。しかし、アプリケーション全体が秘密情報を保護できるか、操作されたコンテキストに耐えられるかという問いには答えない。

モデルのガードレールは通常、トレーニング、フィルタリング、分類、または記述された指示を通じて機能する。これらの対策は応答に影響を与える。データベース権限を取り消したり、トークンの有効期間を短縮したり、アプリケーションが機密レコードをコンテキストへ渡すことを防いだりはできない。

この違いは、検索拡張生成が関与する場合に重要になる。検索拡張生成、すなわちRAGは、モデルが回答する前に選択された企業文書を提供する。モデルは検索レイヤーが渡した資料だけを基に推論できるため、検索権限はセキュリティ境界の一部となる。

そのレイヤーが意味的な関連性だけを基準に文書を返す場合、組織上の境界を越える可能性がある。有用そうに見える一節が、別の部門、顧客、または法務案件に属しているかもしれない。モデルによる流暢な要約は、その根底にある認可エラーを隠してしまう可能性がある。

同じリスクは、アプリケーションが企業外のコンテンツを取得する場合にも現れる。調査エージェントは、Webページ、添付ファイル、サポートチケット、共有文書を読むことがある。これらの情報源には、従業員にとって有用な情報ではなく、エージェントに向けた指示が含まれている可能性がある。

Microsoftが修正済みのEchoLeak脆弱性について説明した内容は、この経路の深刻さを示している。同社によれば、この攻撃は特定の条件下で、多段階のクロスプロンプトインジェクションを用い、被害者が利用可能な限定的データを流出させた。Microsoftはこの問題をCVE-2025-32711として対処した。

EchoLeakに関するガイダンスの重要性は、1つの製品にとどまらない。これは、本番環境のアシスタントが外部コンテンツ、内部アクセス、モデルの振る舞いを組み合わせ、データ流出経路になり得ることを示した。

プロンプトだけに依存する防御は、モデルに操作を見抜くよう求める。システムレベルの防御は、検出が失敗し得ることを前提とする。そのうえで、取得データを制限し、危険な出力チャネルを遮断し、すべての機密操作をモデルの外部で検証する。

米国国立標準技術研究所も同様に広い視点を取っている。同研究所の生成AIプロファイルは、設計、開発、導入、評価、利用にまたがるリスクを扱う。AIセキュリティをモデルフィルタリングだけに還元してはいない。

このライフサイクルの視点は、企業アプリケーションが多くのコンポーネントから構成されるため重要だ。そこにはモデルプロバイダー、ベクトルデータベース、IDシステム、プラグイン、API、監視ツール、ユーザーインターフェースが含まれる。モデルだけをテストするセキュリティレビューでは、その連鎖の大半が手つかずのまま残る。

実践的なテストは、コンテキストが侵害されているという前提から始めるべきだ。レビュー担当者は、アプリケーションが通常取得する文書の中に敵対的な指示を置くことができる。そして、エージェントがデータを露出させるか、目的を変更するか、未認可のツール呼び出しを試みるかを観察できる。

チームは、モデル、プロンプト、コネクター、検索設定、ツールの説明を変更した後にも、こうしたテストを繰り返すべきである。アプリケーションコードが変わっていないように見えても、AIの振る舞いは変化し得る。前四半期に成功した評価が、現在のワークフローが同一に動作する保証にはならない。

モデルのアップグレードは、誤った安心感の別の要因にもなる。ベンダーは拒否の振る舞いを改善する一方で、異なる計画パターンを導入する可能性がある。文書化されていない拒否に依存していたアプリケーションは、正式な権限変更がなくても予測可能性を失うことがある。

より安全なアーキテクチャでは、プロンプトを防御の一層として扱う。これを、モデルが書き換えられないアクセス制御と組み合わせる。機密データは、ユーザー、タスク、リソースのすべてが明示的なポリシーを満たさない限り、利用できない状態にすべきだ。

出力についても、操作になる前に検査が必要である。生成されたデータベースクエリは、認可と検証を通過すべきだ。提案されたメールは、送信先のチェックを受けるべきである。コードは、限定されたファイルシステムとネットワークアクセスを持つ隔離環境で実行すべきだ。

この構造はプロンプトインジェクションをなくすものではない。しかし、インジェクションの成功が自動的に侵害へつながることを防ぐ。それこそが企業セキュリティにとって、より現実的な目標である。

誤りその2：AIエージェントに人間と同規模の権限を与える

エージェントには、ユーザーが恒常的に持つアクセス権ではなく、1つのタスクに必要な最小限の一時的権限を付与すべきである。

第2の誤りは、企業がAIエージェントを既存の従業員認証情報へ接続する場合に生じる。この手法は、アプリケーションがすでにそれらのIDを理解しているため便利だ。しかし同時に、確率的な自動化に、人間のアカウントを中心として蓄積された到達範囲を与えてしまう。

従業員は、週を通じて担当業務が変化するため、しばしば広範なアクセスを必要とする。限定的な1件のリクエストを処理するエージェントには、同じ範囲は不要だ。アクセス可能なすべてのメールボックス、リポジトリ、顧客レコード、クラウドツールを引き継ぐなら、その影響範囲は不必要に大きくなる。

OWASPはこの問題を過剰なエージェンシーとして説明している。この脆弱性は、AIシステムが過大な機能、過剰な権限、または過度の自律性を与えられた場合に生じる。操作された出力は、機密性、完全性、可用性にまたがる有害な操作を引き起こし得る。

「エージェンシー」という言葉は、リスクを抽象的に聞こえさせるかもしれない。実際には、予測不能なプランナーに結び付いた通常の権限を意味する。モデルがツール呼び出しを選び、アプリケーションが認証情報を渡し、別のシステムがそのリクエストを認可済みとして受け入れる。

従来の最小権限の原則は、依然として正しい出発点である。各エージェントには固有のID、定義されたタスク、許可されたリソースの短い一覧が必要だ。そのIDは、開発者のシェルアクセスや役員の文書資産全体をひそかに借用すべきではない。

認証情報も迅速に失効させるべきだ。長期間有効なキーは、元のセッションが終わった後もエラーや侵害を持続させる。短期間のトークンはその期間を短縮し、各タスクについてより明確な監査記録を作る。

書き込みアクセスは、読み取りアクセスとは別に扱う必要がある。多くのアシスタントは、基幹システムを変更しなくても有用な要約を提供できる。企業はそこから始め、完全な経路をテストした後にのみ、限定的な操作を追加すべきである。

影響の大きい操作には、トランザクション境界が必要だ。顧客への返金を準備するエージェントは、証拠を集め、金額を推奨できる。実際の発行前には、別の決定論的サービスがポリシー、認可、送付先、上限を検証すべきである。

ソフトウェア開発でも同じパターンが当てはまる。エージェントは一時的なワークスペース内でパッチを提案できる。しかし、本番環境の認証情報、デプロイメントシステム、個人設定ファイル、あるいは無関係なリポジトリへのアクセスを自動的に継承すべきではない。

ネットワークアクセスにも、タスク単位の制約が必要だ。パッケージのドキュメントだけを必要とするコーディングエージェントが、任意の外部サーバーに接続できるべきではない。リサーチアシスタントは、プライベートアドレス、危険なプロトコル、信頼できないダウンロードを遮断する承認済みフェッチャーを介して動作できる。

ツールの説明は、権限制御ではない。ある関数は特定の目的にのみ使うべきだとエージェントに伝えても、権限のない呼び出しを防ぐことにはならない。呼び出し先のサービス側で、誰が呼び出せるのか、どの引数が有効なのか、どのリソースが対象範囲に含まれるのかを強制しなければならない。

ここで、多くの企業AIプログラムはデプロイ速度と衝突する。プロダクトチームは、多様なユースケースで使える単一のコネクターを求める。一方でセキュリティチームには、意味のある各アクションごとに分離されたスコープ、ID、ログ、承認ルールが必要だ。

この緊張関係は現実のものだが、広範なアクセス権だけが実現可能な設計ではない。企業は個々のタスクに対してケイパビリティを発行できる。ケイパビリティとは、限定された期間に、ひとつのリソースに対するひとつの操作を認可する、狭く定義された権限である。

このアプローチは調査も改善する。ログには、特定のエージェントインスタンスがひとつのサポート依頼のために、承認済みの3件のレコードを読み取ったことを示せる。対照的に共有ユーザー認証情報では、帰属を特定しにくい一連のアクションしか残らない。

データ最小化も同じ設計に含まれる。フィルタリングされたフィールドで質問に答えられるなら、エージェントに文書全体は不要だ。タスクで特定のアカウントが指定されているなら、すべての顧客アカウントも必要ない。

検索可能な社内システムを構築するチームは、早い段階でこの問題に直面する。安全な技術ナレッジベースは、すべてのファイルを無制限のひとつのインデックスに平坦化するのではなく、ソースごとの権限を維持しなければならない。

重要な比較対象は、エージェント対人間ではない。常設の人間アクセス権対タスク固有の機械アクセス権である。機械はより速く動作し、アクションを一貫して繰り返し、ひとつの誤りを多数のレコードに拡大できる。

企業はそれに応じて設計すべきだ。1回のセッションで数百回の操作を実行できるシステムには、ひとつの慎重な変更を行う人よりも厳しい制限が必要になる。速度は生産性と損害の両方を拡大する。

間違いその3：人間による承認がアクションを安全にすると考えること

提案されたアクションの対象、タイミング、結果をインターフェースが隠している場合、人間の関与がもたらす保護はわずかである。

多くの企業向けAI製品は、重大な操作の前に人間をプロセスへ組み込んでいる。エージェントが確認ダイアログを表示し、ユーザーが続行するかを選ぶ。この設計は、責任が目に見える形で人間に残るため、安心感を与えるように見える。

その保護は、本人が実際に何を見られるかに左右される。「この変更を許可する」といった曖昧なプロンプトでは、情報に基づく判断を支えられない。攻撃者が影響を与えられるコンテンツを基に構築された承認画面も同様である。

WizのGhostApprovalに関する研究は、この問題を6つの著名なAIコーディングアシスタントで明らかにした。影響を受けた対象には、Amazon Q Developer、Anthropic Claude Code、Augment、Cursor、Google Antigravity、Windsurfが含まれていた。

GhostApprovalの調査結果によると、悪意あるリポジトリはシンボリックリンクを利用し、一見ローカルに見えるファイル変更をワークスペース外へリダイレクトできた。シンボリックリンクとは、あるパスを別の場所へ向けるファイルシステム上の参照である。

画面上の承認では無害なプロジェクトファイルが表示される一方、解決されたパスは機密性の高いシステムファイルを標的にしている可能性がある。一部のテスト対象製品では、意味のある認可が行われる前に書き込みが発生したとWizは報告している。これにより、インターフェースはセキュリティゲートではなく、取り消しのための仕組みに変わってしまった。

この調査結果は、現在のすべてのバージョンが依然として脆弱であることを意味しない。Wizは複数ベンダーによる修正または対応を報告しており、製品の挙動は急速に変わり得る。長期的な論点は、この研究によって露呈した信頼モデルにある。

人間による承認が機能するのは、システムが正規化され、独立して検証された詳細を提示するときだけだ。ファイル操作では、そうした詳細に解決済みのパス、操作の種類、コンテンツ差分、プロセスID、対象が認可済みワークスペースの外部にあるかどうかが含まれる。

メッセージでは、ユーザーに実際の受信者、添付データ、送信IDが必要となる。支払いでは、送付先、金額、認可元、ポリシー判定が必要だ。クラウド変更では、アカウント、リソース、リージョン、想定される影響が必要となる。

アプリケーションは、これらの事実を信頼できるシステム状態から生成しなければならない。エージェントによる自然言語の要約に依存すべきではない。許可を要求するモデル自身には、意図的であれなくとも、そのアクションを有用に見せる動機がある。

タイミングも同様に重要である。承認は、システムが外部状態を変更する前に行われなければならない。ファイル書き込み、API呼び出し、メッセージ送信の後に表示されるボタンでは、その事象を防げない。

企業は承認疲れも避ける必要がある。ユーザーが無害な操作に関するリクエストを頻繁に受け取ると、詳細を確認せずに受け入れるようになる。攻撃者はその後、見慣れたプロンプトの中に危険なリクエストを隠せる。

リスクベースの承認は、より優れたパターンを提供する。影響の小さいアクションは、厳格な制限の範囲内で進められる。機密性の高い操作には、より充実した開示、より強力な認証、独立したポリシーチェックを適用する。

一部のアクションは、単一のクリックに決して依存すべきではない。本番データの削除、アクセスポリシーの変更、大規模データセットのエクスポート、デプロイメント認証情報の変更には、第二のIDまたは帯域外レビューを要求できる。

これは人をプロセスから排除するものではない。人が現実的に評価できる判断を与えるものだ。人間は、時間的制約の下で隠れた技術的状態を検証するためではなく、判断のために最も有効に活用される。

セキュリティチームは、承認画面を敵対的にテストすべきだ。長いファイル名が送付先を隠せないか、書式設定が警告を見えにくくできないか、侵害された文書が表示テキストに影響を与えられないかを検証できる。

競合状態も確認すべきである。レビューされた状態は、承認から実行までの間に変わらない必要がある。攻撃者が承認後にファイル、送付先、引数を置き換えられるなら、画面上の判断は実際のアクションをもはやカバーしない。

企業AIセキュリティに対するGoogle Newsの注目は、より広範な是正を反映している。「人間をループに入れる」という表現は、完全な制御の説明ではない。レビュー担当者は、どの人間が、どの情報を、どの時点で、どの独立して強制される境界のもとで確認するのかを知る必要がある。

なぜ企業はこの3つの間違いを繰り返すのか

導入を促すインセンティブは目に見えるAI機能に報いる一方、信頼できる境界は構築に時間がかかり、購入者にも見えにくい。

この3つの間違いが続くのは、それぞれが手軽な近道を提供するためだ。プロンプトによる指示はアクセス制御を再設計するより容易である。共有認証情報はタスク固有のIDを作るより容易だ。確認ボタンは検証可能な認可フローを構築するより容易である。

デモはこうした近道を強化する。広いアクセス権があれば、エージェントはより多くの情報を見つけ、より多くの手順を完了できるため、成功するデモにつながる。制限付きアクセスでは、拒否、セットアップ作業、表面的な摩擦が増える。

本番環境では、その計算が逆転する。接続するシステムが増えるごとに、信頼関係がひとつ増える。権限を追加するごとに、潜在的な影響も増大する。自動化される手順が増えるほど、防御側が異常な挙動に気づくまでの時間は短くなる。

組織上の責任分担も問題を加える。プロダクトチームはモデルとコネクターを選ぶ。IDチームは認証情報を管理する。セキュリティチームはイベントを監視する。法務チームはデータ制限を定める。事業部門は、どのワークフローが重要かを決める。

エージェントは、ひとつのタスクの中でこれらすべての領域をまたぐ可能性がある。完全な実行チェーンの所有者がいなければ、各グループは別の制御が失敗を止めると考えてしまう。

ベンダーの保証は、この隔たりをさらに深める場合がある。企業契約では、データ保持、モデル学習、暗号化が扱われることがある。これらの保護は重要だが、過度に広い顧客権限や安全でないワークフロー設計を修復するものではない。

プロバイダーは保存されたプロンプトを保護できても、顧客が検索を通じて社内レコードを公開する可能性は残る。モデルインフラを分離できても、企業がエージェントに過剰なクラウドアクセスを与える可能性はある。責任はスタック全体で共有されたままだ。

AIアクティビティが正当な業務に見える場合、セキュリティ製品も苦戦する。認可済みの従業員が、承認済みアシスタントに契約書の要約を依頼することはあり得る。同じワークフローでも、その契約書にエージェントを誘導する隠れた指示が含まれていれば危険になる。

従来の監視は、認証済みユーザー、承認済みアプリケーション、許可されたデータリクエストを検知する。欠けているシグナルは、信頼できないコンテキストと、その後に続いたアクションとの関係である。

企業には、その関係を示すより豊富なトレースが必要だ。有用なログは、取得したソース、モデルの判断、ツール呼び出し、ポリシー結果、承認、結果として生じた状態変更を記録する。機密コンテンツを保護しながら、調査に十分な証拠を維持できる。

目標は、従業員を無制限に監視することではない。説明責任のある自動化である。人々は、AIシステムがいつ会社のデータにアクセスし、どのアクションを自分に代わって実行するのかを理解できるべきだ。

シャドーAIは、この取り組みを複雑にする。シャドーAIとは、通常のガバナンスの外で、従業員が未承認のモデル、エージェント、コネクターを使用することを指す。すべての公開ツールを遮断すると、活動が個人アカウントや管理されていないデバイスへ流れる可能性がある。

より良い対応は、承認済みの代替手段と、ID、ブラウザ、エンドポイント、データの各レイヤーで強制可能な制御を組み合わせることだ。従業員には正当な業務のための実用的な経路が必要であり、セキュリティチームには保護情報の移動先を可視化する手段が必要となる。

企業は、実験環境と本番環境も分離すべきだ。サンドボックスでは、合成データ、使い捨ての認証情報、隔離ネットワーク、限定されたツールを提供できる。成功した実験は、その後、実際のアクセス権を得る前に明示的な脅威モデリングを経ることができる。

このプロセスには、コンプライアンスのチェックリスト以上のものが必要だ。各ワークフローには悪用ケースが必要になる。レビュー担当者は、取得したコンテンツが虚偽を含む場合、モデルが誤ったツールを選択した場合、ユーザーが誤解を招くリクエストを承認した場合に何が起こるかを問うべきである。

そのうえで、復旧もテストすべきだ。企業はエージェントIDをただちに無効化できるか。変更されたレコードを特定できるか。それらを引き起こした同じモデルを信頼せずに、アクションを取り消せるか。

最も強い反論は、こうした制御が導入を遅らせるというものだ。一部のデプロイメントについては、その通りである。しかし、未解決の権限および承認の欠陥は、インシデント対応、緊急の制限措置、信頼の喪失を通じて、後から遅延を生み出す。

もうひとつの不確実性は、モデルそのものに関するものだ。ベンダーは指示処理と攻撃検知を継続的に改善している。こうした改善は操作の成功を減らせるが、決定論的な制限を取り除く根拠にはならない。

企業セキュリティは、モデルの変化に合わせて改善すべきであり、その変化に依存すべきではない。適切に設計されたアプリケーションは、より優れたモデルによって安全性が高まる一方、そのモデルが失敗しても境界を維持する。

セキュリティリーダーが次に注視すべきこと

次の段階は、モデルの拒否スコアではなく、権限設計、独立したテスト、インシデントの透明性によって評価されるだろう。

最初のシグナルは、ベンダーがエージェントセキュリティインシデントについて意味のある事後検証を公開するかどうかである。有用な開示には、最初の入力、利用可能なツール、認証情報、封じ込めの失敗、最終的な影響が記載される。「予期しない挙動」といった曖昧な表現では、ほとんど指針にならない。

事後検証では、インシデント後に何が変わったのかも明確にすべきだ。新たなプロンプトは、取り消された権限や再設計された認可ゲートに比べれば、弱い証拠にすぎない。セキュリティリーダーは、行動のチューニングとアーキテクチャ上の是正を区別する必要がある。

第2のシグナルは、エージェント固有のアイデンティティ制御の導入だ。企業には、分離されたマシンアイデンティティ、短命な認証情報、リソース単位のスコープ、そして緊急時の失効機能が必要になる。ユーザーになりすますだけの製品では、重要な疑問に答えられない。

購買担当者は、1つのエージェントがタスクの実行中に無関係なアプリケーションへアクセスできないかを確認すべきだ。あらゆるツール呼び出しにポリシーが適用されることを示す証拠を求める必要がある。また、ログが実行された操作を、その起点となったユーザーとセッションに結び付けていることも検証すべきだ。

第3のシグナルは、再現可能なセキュリティ回帰テストだ。AI回帰テストでは、モデル、プロンプト、ツール、検索、権限に変更を加えた後、既知の攻撃が再発するかどうかを確認する。これはデプロイ前と、重要な更新のたびに実行すべきである。

こうしたテストには、現実的な悪意あるコンテンツが必要だ。チームは、メール、ウェブページ、文書、リポジトリ、ツールの応答に攻撃を埋め込むべきである。直接的なユーザープロンプトがカバーするのは、アプリケーションの入力領域の一部にすぎない。

独立した研究は今後も不可欠だ。ベンダーによる評価は、通常利用と既知の攻撃に重点を置くことが多い。EchoLeakやGhostApprovalが示すように、外部の研究者は信頼境界に異なる視点からアプローチする。

調達チームは、脆弱性開示プログラム、対応までの時間、公開された是正措置について質問することで、その取り組みを支援できる。研究への製品側の対応は、そのセキュリティマーケティングと同じくらい多くを物語る。

エージェントがより機密性の高いシステムへ到達するようになるため、Google Newsでは今後も警戒を要するAIインシデントが取り上げられ続けるだろう。有効な対応は、パニックや一律の禁止ではない。企業が安全な導入をどう定義するかを変えることだ。

モデルは信頼しないものとして扱う。エージェントに与えるアクセス権は、指示を出す人より少なくする。何かを変更する前に、承認画面で独立して検証された事実を明らかにする。

セキュリティリーダーは今、接続されたAIワークフローを1つ選び、入力から最終アクションまで追跡すべきだ。モデルが悪意ある指示に従ったとしても、どの制御が機能し続けるのか。その答えが、企業にAIセキュリティアーキテクチャがあるのか、それともAIセキュリティへの約束しかないのかを示す。