記事一覧に戻る
セキュリティ動向2026年7月28日7分で読めます

CRMの中で動くAIエージェントは、監視の死角にいる

AIを活かすためにData CloudのようなSaaSへデータを集めるほど、守るべきデータの境界はSaaSの内側へ移る。それなのに監視は従来の境界に残されたまま——正規権限で読み出され、正規機能で持ち出されるデータは、SIEMにもEDRにも異常として映らない。SaaSの中で動くAIエージェントという新しい死角を、Agentforceの実例(ForcedLeak)とともに解説する。

AIを見つける方法が話題になってきた。

でも、一番見えにくいAIがある。

SaaSの中で動くAIだ。

Nudge Securityの記事では、社内で使われているAIを見つけるために、通信、端末、ブラウザ、APIキー、SaaS連携などを調べる方法が紹介されている。

どれも重要だ。

ただ、その方法でも見つけにくいAIがある。

SaaS事業者のクラウドの中で動き、SaaS内部の権限でデータへアクセスするAIだ。

従来の「見つけ方」が効かない

SaaSに組み込まれたAIエージェントは、利用者の端末で動くわけではない。

事業者のクラウドの中で動き、プラットフォームが持つ権限でデータを読み出す。

端末を監視しても、AIの処理は見えない。

ネットワークを監視しても、SaaS内部でデータを読み、加工している動きまでは見えない。

AI専用のAPIキーを持たず、SaaS内部の権限で動く場合には、認証情報を追う方法でも見つけられない。

従来の監視手法が、ちょうど交わらない場所にいる。

だが、本当の問題はそこではない。

AIを活躍させるためにデータをSaaSへ集めるほど、大事なデータを守る境界そのものが、SaaSの内側へ移っていく。これが、この記事の中心にある話だ。

AIを活躍させるほど、集まるデータは増える

その境界の移動を、いちばん大きく起こすのがData Cloudのような統合データ基盤だ。

Data Cloudに集められるのは、Salesforceの中にあるデータだけではない。

基幹システム、EC、Webサイト、サポート、マーケティング、外部データベースなど、複数のシステムに分散していたデータをSaaS側へ持ってくることができる。

なぜ集めるのか。

多くのデータを与えた方が、AIエージェントがより広い状況を理解し、より多くの仕事をできるからだ。

顧客の属性だけでなく、購買履歴、問い合わせ履歴、契約状況、Web上の行動、社内の対応履歴まで見えれば、AIはより適切に判断できる。

つまり、AIを活躍させようとするほど、SaaSの中に集める重要データは増えていく。

ここに、新しい死角が生まれる。

正規の利用にしか見えない

SaaS内部のAIが、統合されたデータへ正規の権限でアクセスする。

AIが必要な情報を抽出し、一覧やレポートを作る。

そして、権限を持つ利用者が、その結果を通常のエクスポート機能でローカルへダウンロードする。

そこに権限昇格はない。

不審な外部通信もない。

マルウェアも侵入もない。

だから、SIEMにもEDRにも、ネットワーク監視にも、異常としては現れない。SOCの画面から見ても、正規ユーザーによる普通の検索と、普通のファイル出力でしかない。

端末側で確認できるのも、利用者がSaaSからファイルをダウンロードしたという事実だけだ。

そのデータを誰が選んだのか。

どのシステムから集めたのか。

AIがどの指示に基づいて抽出したのか。

なぜ、その範囲のデータが必要だったのか。

外側の監視だけでは分からない。

しかも、対象になるのはSalesforceに最初から保存されていたデータだけではない。

AIを活躍させるために、他のシステムからData Cloudへ集めたデータも含まれる。

正規の権限で読み出され、正規の機能で持ち出される。

だから、普通にしか見えない。

これが、SaaSの中で動くAIの本当の死角だ。

これは机上の空論ではない

2025年9月にNoma Securityが公表した「ForcedLeak」は、Salesforceの自律型AIエージェント基盤「Agentforce」の脆弱性だった。

攻撃者が問い合わせフォームに文章として仕込んだ指示を、エージェントが命令として読み取り、CRMのデータを外部へ送信させるものだ。

注目すべきは、AIが権限を昇格させたわけではないことだ。

もともと与えられていた権限のまま、外部から与えられた指示に従った。

ForcedLeak自体はプロンプトインジェクションの脆弱性だが、その本質は、AIが持っていた正規の権限を悪用されたことにある。問題は特定の脆弱性ではなく、AIに広い権限を与えた構造そのものだ。

Salesforceはすでに修正し、外部へ送信できるURLを制限する対策を入れている。

しかし、外部送信先を制限すれば、すべて解決するわけではない。

AIがSaaS内部でデータを集め、その結果を利用者が正規の機能でダウンロードする経路は残る。

この動きは、攻撃通信として検知することすら難しい。

大事なデータを守る境界が移った

これは、AIやSaaSが悪いという話ではない。

大事なデータを守る境界が変わった、という話だ。

データが社内のデータベースにある間は、ネットワーク、端末、データベース監査、認証基盤を中心に守ることができた。

だが、そのデータをSaaSへ渡した瞬間、守るべき境界の一部はSaaSの内側へ移る。

さらに、AIを活躍させるために社内外のデータを統合すれば、守るべき重要データの範囲もSaaS側で広がっていく。

それなのに、監視の設計だけが従来の境界に残っていないか。

ファイアウォールを見ている。

端末を見ている。

APIキーを見ている。

しかし、大事なデータが集められ、AIに読み出され、加工される場所は、すでにその外側へ移っている。

確認すべきなのは、SaaSの管理画面の中だ。

どのデータをSaaSへ持ってきているのか。

AIは、そのうち何を参照できるのか。

誰がAIを作成し、実行できるのか。

AIが作った結果を、誰がエクスポートできるのか。

AIがどの指示を受け、どのデータを読み、何を出力したのかを記録できるのか。

顧客データをSaaSのAIに使わせる判断と、その内側で大事なデータをどう守るのかという判断は、本来セットでなければならない。前者だけが進み、後者が誰の担当でもないまま残れば、そこが死角になる。

これから重要になるのは、「AIを使うかどうか」ではない。

AIに何を見せるのか。

AIに何を持ち出させるのか。

その境界を、SaaSの管理画面で管理できているか。

そこが、新しいセキュリティの境界になる。

A

Aikido Community Japan

公開日: 2026/7/28

最終更新: 2026/7/28

シェア:

ニュースを購読

セキュリティの最新情報をお届けします。

Aikido Community Japan からのお知らせの受信に同意します。詳しくはプライバシーポリシーをご確認ください。