AIエージェントが企業アクセスを内側からのデータリスクに変える

Google NewsはAIエージェントについて、より明確な警告を取り上げている。企業データにとって最大の脅威は、すでに有効な認証情報と承認済みのアクセス権を持っている可能性がある。

Dark Readingの報道は、単発の侵害事案を扱ったものではない。より広範なセキュリティ上の逆転を浮き彫りにしている。企業は有用な業務を自動化するため、エージェントに内部アクセスを与える。同じアクセス権があれば、エラー、悪意ある指示、過剰な権限によって、機密情報が信頼されたシステム間を移動しかねない。

従来の防御は、侵入者をネットワークの外に留めることに重点を置いてきた。AIエージェントは、正規のアイデンティティと認可済みツールを使って承認済みアプリケーション内で動作することが多く、このモデルを複雑にする。中心的な対立は、もはや防御側と明白な外部攻撃者の間ではなく、生産性と統制の間にある。

このストーリーに触れたGoogle Newsの読者は、これをアクセスガバナンスに関する警告として捉えるべきだ。企業がすでにエージェントをメール、文書、データベース、ブラウザ、外部APIに接続しているなら、エージェントは境界防御を突破する必要がない。

Google Newsの見出しが実際に示すもの

AIエージェントは、ありふれたアクセス上のミスを、複数の企業システムをまたぐ自動化された一連の行動へと変える。

AIエージェントとは、モデルを利用してタスクを計画し、ツールを選択し、限定的な人間の関与のもとで行動するソフトウェアだ。チャットボットとは異なり、単にテキストを返すだけではない。記録の取得、メッセージの送信、ファイルの編集、APIの呼び出し、ワークフローの起動まで行える。

この違いが、セキュリティ上の問題を変える。チャットボットが開示できるのは、そのコンテキストに置かれた情報だ。エージェントはさらに情報を検索し、組み合わせ、変換し、別の場所へ移動できる。

Google Newsの見出しが示す根本的な懸念は、エージェントがあらゆる企業秘密を抱え込んでいることではない。企業情報は通常、クラウドストレージ、顧客システム、コードプラットフォーム、コラボレーションツールといったリポジトリに残っている。

リスクは、それらのリポジトリとエージェントの間にある接続から生じる。責任分担に関するDark Readingの報道は、エージェント型サービスに接続されたデータとユーザーを保護する責任は、依然として企業側にあると強調している。

あるエージェントがユーザーのアクセス権を継承し、別のエージェントが汎用サービスアカウントを使用する場合、その責任は管理しにくくなる。どちらの設計も、予期しない露出経路を生み出しかねない。

ユーザー単位のエージェントは、忘れられた共有フォルダを含め、従業員がアクセスできるあらゆるものを検索する可能性がある。サービスアイデンティティは、個々のユーザーに必要な範囲を超える広範な権限を持つことがある。

またエージェントは、個別に見れば無害に見える事実を組み合わせられる。顧客リスト、社内ロードマップ、従業員名簿は、集約されると極めて機密性の高い情報になりうる。

これは重要な逆転だ。企業内検索はかつて、従業員がすでに閲覧を許可されている文書を見つける助けとなっていた。今ではエージェントがそれらの文書を見つけ、別途人間が判断しなくても後続の行動を取れる。

危険に悪意は必要ない。曖昧な依頼は過度に広範な検索を招きうる。信頼性の低い計画は、誤った宛先や送信先を選ぶ可能性がある。

侵害された文書がワークフローの方向を変えることもある。間接プロンプトインジェクションは、メールやWebページなど、エージェントが読むコンテンツの中に悪意ある指示が隠されている場合に起こる。

モデルは、そうした指示をタスクの一部として解釈する可能性がある。同じエージェントが非公開データにアクセスし、外部と通信できるなら、攻撃者は情報探索と持ち出しを結び付けたことになる。

これが、このストーリーが一つの見出しを超えて重要である理由だ。エージェントは、アイデンティティ、データ、アプリケーション、行動の交点に位置する。接続が増えるたび、一つの障害が到達できる範囲も広がる。

したがって、直ちに必要となる変化はアーキテクチャ上のものだ。企業は単にソフトウェアへデータアクセスを与えるだけでなく、そのアクセスをどう使うかについてシステムに裁量を与えている。

内側から外へ向かう露出経路

最も危険なエージェントのワークフローは、信頼できないコンテンツ、機密データ、外向きの行動を一つのアイデンティティの下で組み合わせる。

あるエージェントがアカウントレビューの作成を依頼されたとしよう。顧客記録を読み、社内メッセージを検索し、最近のサポートケースを確認し、要約を作成する。

各ステップは正当なものに見える。露出経路は、取得した項目の一つに、従業員ではなくモデルを対象とした指示が含まれているときに現れる。

悪意あるサポートチケットは、エージェントに元のタスクを無視するよう指示するかもしれない。さらに記録を探し出し、許可されたWebリクエストを通じて送信するようシステムに命じる可能性がある。

攻撃者は企業にログインする必要がない。エージェントが通常の業務チャネルを通じて入ってきた攻撃者のコンテンツを読むからだ。

この攻撃パターンは、言語モデルだけでは信頼性高く強制できない境界を悪用する。同じコンテキストには、ユーザー指示、取得された事実、システムガイダンス、攻撃者が制御するテキストが混在しうる。

モデルはこれらの要素を言語として処理する。ラベル付けやプロンプト設計は役立つが、決定論的な認可の壁を作るものではない。

エージェントのツールが、この弱点を重大なものにする。モデルが非公開データに到達できず、セッション外で行動もできないなら、汚染された指示の価値はほとんどない。

開発者が利便性のために広範なツールを提供すると、リスクは高まる。汎用ブラウザ、無制限のデータベースコネクタ、シェル、メッセージング機能は、多くのワークフローに対応できる。一方で、本来の機能が必要としなかった行動も支援できてしまう。

OWASPはこの問題を過剰なエージェンシーとして特定している。その例には、読み取り専用タスクであるにもかかわらず、情報の変更、削除、送信もできる拡張機能が使われているケースが含まれる。

権限は別の層を形成する。一つの製品テーブルを読むためのコネクタに、書き込みアクセスや無関係な記録への可視性を与えるべきではない。

汎用の特権アカウントは特に危険だ。個々のユーザーが要求できることと、エージェントのインフラストラクチャが取得できることの区別を消してしまう可能性がある。

メモリは露出の時間枠を広げる。エージェントメモリは後の利用に向けて事実やコンテキストを保存し、セッションをまたぐ継続性の維持に役立つ。

しかし、永続的なメモリには、汚染された指示、機密情報、誤ったセキュリティ上の前提が残りうる。一つのタスク中に持ち込まれた問題が、後に別のユーザーやワークフローへ影響する可能性がある。

ログは第二のデータリポジトリになりうる。詳細なトレースはチームがエージェントの判断を調査する助けになるが、プロンプト、取得文書、認証情報、個人情報を含む可能性がある。

そのためチームは、一つのリスクを下げながら別のリスクを作り出す可能性がある。保護が不十分なオブザーバビリティデータは、エージェントが何を見て何を試みたかを記録しているため、価値の高い標的となる。

マルチエージェントシステムでは、転送がさらに増える。一つのエージェントが情報を収集し、二つ目が分析し、三つ目が結果を伝達する場合がある。

あらゆる引き継ぎには、認証済みのアイデンティティ、制限された権限、検証済みのデータが必要だ。そうでなければ、侵害されたコンポーネントが、信頼された内部トラフィックを装って有害な指示を下流へ渡せてしまう。

外部の攻撃者は依然として重要な存在だが、最終行動は企業内部から起こる。それは承認済みアイデンティティを通じ、防御側が通常とみなす可能性のあるアプリケーション経路に従って到来する。

これが内側から外へ向かう問題だ。セキュリティ障害は正当なアクセスから始まり、内部データの境界を越え、許可されたツールを通じて外部へ出る。

アイデンティティチームが最初に圧力を受ける理由

AIエージェントはユーザーのように振る舞い、サービスのように認証され、そのどちらのために作られたガバナンスプロセスよりも速く動作する。

人間向けのアクセスシステムは、識別可能な従業員、職務、管理者、雇用ライフサイクルを前提としている。サービスアカウントは通常、安定した機能を持つ予測可能なソフトウェアを支える。

エージェントはどちらのカテゴリにも収まらない。その行動は、プロンプト、取得したコンテキスト、利用可能なツール、モデルバージョン、中間結果によって変化する。

エージェントはAPIトークンで認証し、従業員に代わって行動し、タスクの一部を別のエージェントに委任する可能性がある。これにより、一つのワークフローの中に複数のアイデンティティが生じる。

セキュリティチームは、誰がリクエストを開始したかを把握しなければならない。また、どのエージェントが行動し、どの認証情報を使い、誰の認可が適用されたかも知る必要がある。

最終的な行動は、それらのアイデンティティに帰属可能であるべきだ。その連鎖がなければ、インシデント対応者は認可済みのAPI呼び出しを確認しても、その背後にある推論やユーザー意図を理解できない可能性がある。

NISTはこのギャップを、2026年のエージェントアイデンティティプロジェクトで認識している。提案された取り組みは、ソフトウェアエージェントの識別、認可、監査、否認防止に焦点を当てている。

これらの要件は確立されたアイデンティティの実務に似ているが、エージェントは運用のテンポを変える。四半期ごとのアクセスレビューでは、一つのタスクの終了から数分後には不要になる可能性のある権限を抑え込めない。

常設アクセスは蓄積の問題を生む。チームはパイロットのために権限を付与し、利便性のために残し、その後エージェントを別のシステムへ接続する。

管理者が意図的に一つの特権スーパーエージェントを作らなくても、エージェントの実効的な到達範囲は広がる。個別の権限が組み合わさり、危険な経路になる可能性がある。

例えば、データベースの読み取りアクセスは、それだけなら安全に見えるかもしれない。外部Webアクセスも、正当な調査タスクを支えうる。

しかし両者を組み合わせると、機密記録が組織外へ流出することを可能にしかねない。セキュリティチームは、この組み合わせを有害と呼ぶことが多い。全体のリスクが、各権限を単独で見た場合のリスクを上回るためだ。

圧力はアプリケーション所有者にもかかる。エージェントに汎用的な管理インターフェースを渡すのではなく、より限定的な機能を公開しなければならない。

スケジューリングエージェントに必要なのは、カレンダーの仮予定を作成する権限かもしれない。すべてのイベントを削除したり、すべての参加者の非公開メモを読んだりする権限まで必要とは限らない。

データ所有者も関連する判断に直面する。ソフトウェアが機械的な速度で情報を検索、要約、再配布できるようになったとき、既存のユーザー権限が引き続き適切かどうかを判断しなければならない。

技術的には数千の文書を開ける従業員でも、それらをすべて調べることはめったにない。エージェントはそのアクセスを迅速に横断し、かつて露出を抑えていた実務上の摩擦を取り除ける。

これは、すべてのエージェントがユーザーより少ないアクセス権を持つべきだという意味ではない。認可では、要求されたタスク、送信先、データの機密性、提案された行動を考慮する必要があるということだ。

静的なロールベースアクセスでは、これらすべての条件を表現できない。企業には、特に機密情報の取得や外部通信の前に、ワークフロー全体を通じたポリシーチェックが必要となる。

Google Newsは、組織上の所有権をまたぐセキュリティ問題を拡大している。アイデンティティチームは認証情報を管理し、アプリケーションチームはツールを構築し、データチームは情報を分類する。

AIプログラムのリーダーは、しばしば導入速度を管理する。これらのグループが独立して動くと、エージェントはそれぞれの隙間を受け継ぎ、それらを一つの実行経路へ結び付ける。

生産性への期待はいまセキュリティの現実と衝突する

エージェントはコンテキストと権限を得るほど有用になるが、同じ機能が操作やエラーによる被害も拡大させる。

有用な企業向けエージェントは、実際の業務を完了するために十分な情報を知る必要がある。関連システムへのアクセス、ユーザーコンテキストの理解、承認済み行動を実行する権限が必要だ。

それらの機能を取り除けば、より安全ではあるものの、できることが限られたチャットボットになる。機能を拡張すれば、有能な作業者になる一方で、その誤りは業務上の影響を招き得る。

これがDark Readingの記事の根底にある主要なトレードオフだ。目標はエージェントの自律性をなくすことではない。自律性が無制限の権限へと変わるのを防ぐことである。

セキュリティ制御はリスクを抑えられるが、単独で完全な答えを提供するものはない。プロンプトフィルターは既知の悪意ある表現を検出できるが、攻撃者は指示を符号化したり偽装したりできる。

モデルベースのガードレールには、より深い制約がある。確率的なシステムを使って別の確率的なシステムを評価するため、同様の弱点が両方の層に影響する可能性がある。

人による承認は、行為がまれで重大な結果を伴う場合に役立つ。従業員が実質的に精査できない複雑なリクエストを日常的に承認する状況では、その有用性は低下する。

承認プロンプトにも明確な情報が必要だ。「ワークフローを続行」や「コネクターを使用」とだけ説明されても、ユーザーは行為を判断できない。

インターフェースは、リソース、操作、受信者、データ分類を示すべきである。また、要求された行為が元のタスクにどう結び付くのかも説明すべきだ。

最小権限は、起こり得る被害を抑える。ただし、変化しながら複数ステップで進むワークフローに対して最小権限を定義することは、従来の単一アプリケーションの権限範囲を定めるより難しい。

あるステップでは適切な権限でも、次のステップでは過剰になり得る。永続的なアクセスよりも、一時的でタスクに紐付いた認証情報の方が適したモデルとなる。

ランタイム監視は別の層を提供する。異常な取得量、新しい送信先、非典型的なツールの組み合わせ、エージェントのベースラインから逸脱する挙動を検出できる。

ただし異常検知には、履歴、コンテキスト、信頼できる帰属情報が必要だ。新しいエージェントには安定したベースラインがない可能性があり、正当なワークフローも大きく変動し得る。

Dark Readingは、現在のエージェントのおよそ90%が低い自律性にとどまることを示すGartnerの調査を報じた。残る10%は、より広範なツール、データアクセス、ランタイムでの裁量を持つ。

こうした高自律性のシステムには重点的な制御が必要だ。なぜなら、その障害モードは単なる誤ったテキストの生成にとどまらないからである。本番システムを変更したり、機密データを移動させたりする可能性がある。

同じ報告は、400人を超えるテクノロジーおよびセキュリティ担当リーダーを対象としたベンダー調査も引用した。その結果、84%が自社のエージェントは機密データにアクセスできると回答した。

さらに67%は、エージェントが本来到達すべきではない情報にアクセスしたと考えていた。これらの数値はセキュリティベンダーの調査に基づくため、普遍的なインシデント率ではなく、懸念の度合いを示すものだ。

それでも、この調査結果はアーキテクチャ上のリスクと整合する。企業は、ID、ツール、データ経路、継承された権限の完全な棚卸しを終える前に、エージェントを接続することが多い。

懐疑的な見方も必要である。すべてのエージェントが、新たな種類の破滅的な脅威を意味するわけではない。

多くのリスクは、サービスアカウント、過剰な権限、安全でない統合、弱いデータガバナンスに関わる既知の障害に似ている。確立された制御を改善すれば、その大部分を防げる。

変化したのは組み合わせだ。エージェントは行為を動的に選択し、攻撃者が制御する言語を処理する。一方、従来の統合はあらかじめ定められたコードパスに従う。

この違いにより、挙動は予測しにくくなる。また、初回ログイン時の品質よりも、ランタイム認可の品質が重要になる。

エージェントによるデータ露出を抑える制御

モデル内部の指示は自らの権限を強制できないため、企業にはモデルの周囲に決定論的な制御が必要である。

第一の要件は、エージェントの棚卸しだ。セキュリティチームは、存在を把握していないID、コネクター、ツール、データストアを統制できない。

棚卸しには、本番環境のエージェント、社内パイロット、ベンダーアプリケーション、従業員が導入したアシスタントを含めるべきだ。また、認証情報が有効なまま残っている放棄プロジェクトも把握する必要がある。

各エージェントには固有のIDが必要だ。共有APIキーは帰属関係を隠し、無効化も困難にする。

そのIDは、所有者、承認済みの目的、モデル、ツールセット、ライフサイクルの状態に対応付けるべきである。企業はプロジェクトの終了時や所有者の退職時に無効化すべきだ。

第二の要件は、タスク範囲に限定した認可である。アクセス判断では、ユーザーが要求した内容と、エージェントが現在提案している行為を評価すべきだ。

1つのフォルダーを要約する依頼が、すべてのリポジトリを検索する権限を与えるべきではない。メールの下書きを作成する依頼が、自動的に送信を許可するべきでもない。

第三の要件は、読み取りと実行の分離だ。信頼できないコンテンツを処理するエージェントが、高影響度のツールを自動的に制御すべきではない。

OWASPのエージェントセキュリティガイダンスは、最小限のツールアクセス、隔離されたメモリ、リスクのある行為に対する人によるレビュー、構造化された監視を推奨している。

アーキテクチャ上の選択肢の1つは、コンポーネントを分離することだ。制限されたモデルが外部コンテンツを読み取り、特権を持つコンポーネントは検証済みの構造化情報だけを受け取る。

このアプローチは操作を完全にはなくさないが、敵対的なテキストから認可済みの行為に至る直接経路を断つ。

第四の要件は、データを考慮した強制だ。ツールは、要求された情報の分類を評価してから返すべきである。

強制ポイントはモデルの外部に置くべきだ。モデルはクエリを提案できるが、どのレコードとフィールドを利用可能にするかは決定論的なポリシーが決定すべきである。

企業はユーザーのセキュリティコンテキストも維持すべきだ。ある従業員のために行動するエージェントが、より広範なサービスIDへと密かに切り替わるべきではない。

可能な限り、読み取り専用アクセスをデフォルトとすべきだ。書き込み、削除、送信、公開、決済の機能には、より限定的なスコープとより強力な検証を要求すべきである。

第五の要件は、送信先の制御だ。組織はエージェントが何を読めるかに注目しがちだが、結果をどこに送れるかを見落とすことが多い。

許可リスト化されたドメイン、承認済みの受信者、コンテンツ検査、制限されたネットワーク経路は、データ流出を抑えられる。プロンプト防御が失敗した場合でも、これらの制御は有用であり続ける。

第六の要件は、保護されたメモリだ。機密情報は、目的、保持期間、アクセス境界が定義されていない限り、長期メモリに入れるべきではない。

メモリはユーザーやワークスペースごとに隔離すべきだ。チームは保存されたコンテキストに対し、認証情報、個人情報、疑わしい指示をスキャンすべきである。

第七の要件は、有意義な可観測性だ。ログには、ユーザー要求、エージェントID、ツール呼び出し、認可判断、データ分類、行為の結果を記録すべきである。

ただし、すべての秘密情報を平文で複製すべきではない。調査記録自体が新たな露出面になり得るため、マスキングとアクセス制御が不可欠だ。

検索可能なナレッジベースにも、明確なソース権限と検索境界が必要である。検索の利便性によって、文書単位のアクセスルールが失われるべきではない。

最後に、チームは完全なワークフローをテストしなければならない。モデル評価だけでは、ID、検索、メモリ、ツール、外部コンテンツが相互作用する際に何が起こるかを明らかにできない。

レッドチームは、汚染された文書、誤解を招くメール、過剰なリクエスト、ユーザー間メモリテスト、未承認の送信先を使うべきだ。モデル、プロンプト、コネクター、ポリシーを変更するたびに、テストを繰り返すべきである。

このGoogle Newsの警告後に注目すべき3つのシグナル

次の焦点は、企業が広範かつ恒常的なエージェントアクセスを、可視的で一時的かつ強制可能な権限へ置き換えるかどうかである。

第一のシグナルは、エージェント固有のIDの採用だ。Microsoftをはじめとするプラットフォームプロバイダーは、エージェントの登録、権限の割り当て、行動の記録を可能にする仕組みを追加している。

登録だけでは不十分だ。企業がすべての行為を、エージェント、開始ユーザー、認証情報、委任されたサービスを通じて追跡できるようになったときに、意味のある変化が訪れる。

これらの記録が標準的なIDガバナンスおよびインシデント対応システムに表示されれば、内側からのリスクは調査しやすくなる。共有トークンへの依存が続けば、その進展は弱まるだろう。

第二のシグナルは、ランタイムでの強制だ。セキュリティチームには、エージェント全体を停止せずに、個別のツール呼び出しを拒否できる制御が必要である。

タスクに紐付いた認証情報、短い認可時間枠、データ認識ポリシー、提案された操作を明示する承認プロンプトに注目したい。こうした機能は、自律性と制御が共存できるという主張を強めるだろう。

「セキュアなエージェント」に関するマーケティング上の主張だけでは、ほとんど証拠にならない。購入者は、認可がモデルの外部で行われるか、ポリシーがすべての下流リクエストに適用されるかを確認すべきだ。

第三のシグナルは、公開されたインシデント証拠だ。市場には、エージェントの障害、ニアミス、データ露出について一貫した報告がまだ不足している。

有用な開示では、起点となった入力、利用可能なツール、有効な権限、失敗した保護措置、最終的な影響を説明すべきである。これらの詳細を欠く集計的な主張では、新しい制御が機能するかを示せない。

規制当局や標準化団体も重要である。NISTのエージェント標準に関する取り組みは、ID、認可、監査可能性について企業に共通の言語を提供し得る。

ベンダーがより多くのワークフローにエージェントを組み込むにつれ、Google Newsは今後も警告を取り上げ続けるだろう。読者は劇的な見出しの先を見て、各事象の背後にあるアクセス経路を検証すべきだ。

企業のエージェントを信頼する前に、3つの質問をすべきである。何を読めるのか、何ができるのか、そして結果をどこへ送れるのか。

組織が強制可能なポリシーと監査可能な記録に基づいて、この3つすべてに答えられないなら、そのエージェントは単なるアシスタントではない。誤った指示を待つ、境界のない内部IDである。