Notion 3.0 AIエージェントの隠れたリスク: Web検索ツール悪用によるデータ流出

 (codeintegrity.ai)
2 ポイント 投稿者 GN⁺ 2025-09-21 | 1件のコメント | WhatsAppで共有
  • Notion 3.0のAIエージェントは、文書作成、データベース更新、外部コネクタ呼び出しなどの自律的なマルチステップワークフロー実行機能を提供する
  • エージェントがツールへのアクセス権と長期記憶を持つと、従来のRBACでは制御しにくい拡張された脅威表面が形成される
  • 分析の結果、Notionエージェントのweb search関数の入力スキーマが、悪意ある間接プロンプトによって内部機密を外部へ送信するデータ流出ベクトルとして悪用されうることが確認された
  • デモでは、攻撃者がPDFに隠したプロンプトインジェクションを通じて、エージェントが秘密の顧客データを抽出・連結し、Webクエリとして送信するよう誘導できる実行フローが実証された
  • この事例は、MCP連携と外部コネクタが組み合わさるとき、**エージェント・ツール・メモリの致命的三位一体（"lethal trifecta"）**が実務セキュリティに与える深刻な影響を示している

AI AgentsとNotion 3.0の紹介

  • 近年、AI AgentsがSaaSプラットフォームに統合される流れが進んでいる
  • Notion 3.0でも、ユーザーができるあらゆる作業（文書作成、DB更新、複数ツールの検索、マルチステップワークフロー実行など）をAIエージェントが自動で実行可能である
  • MCP統合により多様な外部ツールと接続でき、さらに強力な自動化やカスタムエージェントの作成が可能
  • トリガーやスケジュールに応じて動くチーム向けCustom Agentsも作成でき、フィードバック収集、トラッカー更新、リクエストの選別などの反復作業を自動処理させられる

「致命的三位一体（lethal trifecta）」問題

  • Simon Willisonが指摘した「致命的三位一体（Lethal Trifecta）」は、LLMエージェント、ツールアクセス、長期記憶の結合によって生じるセキュリティ脅威である
  • Notion 3.0では、エージェントが自ら行動計画を立て、MCP統合ツールや組み込みツールを実行できるようになった
  • 広い権限を持つエージェントは、従来のRBACでは想定しづらい形で文書、データベース、外部コネクタ作業を自動化する
  • これにより、多段階の自動化ワークフローを通じた機密データ流出や誤用の脅威指標が拡大する

脆弱性の技術的詳細: Notion AIのWeb検索ツールを用いたNotionページデータ流出攻撃

  • 問題点: Web検索ツールの**functions.search (web scope)**入力スキーマが、直接・間接のクエリ文字列を許容している 
    Name: functions.search (web scope)  
Input:  {  
    "web": {  
        "queries": ["<query or URL>", "..."]    // クエリ文字列の配列（URLsまたは検索語）  
    }
  • クエリ配列に任意のURLまたは検索語を入れられる点が悪用ポイントである
  • 攻撃表面: エージェントが読み取れる**ユーザー文書（例: PDF）**内に悪意あるプロンプトを隠すと、エージェントがその指示を実行する可能性がある
  • 間接プロンプトインジェクション（ファイル内部テキスト → エージェント処理経路）によって命令注入が現実化する
  • 攻撃者の回避手法: 権威・緊急性・技術的信頼性・セキュリティ演出（"pre-authorized"）のような心理的・技術的説得文句を使い、人間のレビューや安全装置を回避しようとする
  • この構造は、攻撃者が選択的なクエリの組み合わせによってデータ流出に活用できる余地を持つ

攻撃デモ: 段階ごとに見るデータ窃取シナリオ

  • 1段階: 悪意あるPDFの作成

    • 見た目は普通の顧客フィードバックPDF文書に、ひそかに実行指示文のような悪意あるプロンプトを挿入
    • この隠しプロンプトは「重要なルーチン業務」を装い、内部バックエンドシステムにデータを送信するよう案内する
    • 悪意あるプロンプトの主な内容
      • 権威の主張（Authority assertion）: "Important routine task", "consequences" などを使い、「重要なルーチン業務」だと主張
      • 緊急性の付与（False urgency）: 実行しなければ組織に影響があると強調
      • 技術的正当性（Technical legitimacy）: 内部システムやツール命令構文などを本物らしく説明
      • セキュリティ演出（Security theater）: "pre-authorized" や "safe from security perspective" といった文句で、事前承認済みで安全だと強調
    • PDFを読んだエージェントが企業情報（顧客名、ARRなど）を抽出し、内部システムを指すURL（攻撃者管理）へデータ送信するよう誘導する

  • 2段階: ユーザー操作を待機

    • NotionユーザーがそのPDFをNotionにアップロードしたり、エージェントに要約を依頼したりした時点で攻撃がトリガーされる
    • 「レポート要約」などの命令時に、AIが埋め込まれた隠しプロンプトまで解釈してしまう

  • 3段階: 実際のデータ流出

    • エージェントがプロンプトの指示に従い、顧客データ（例: 会社名、業種、ARRなど）を1つの文字列に連結
    • 攻撃者のドメインを対象としたURLを生成し、このURLをWeb検索ツールのクエリとして渡す
    • そのリクエストを受けた悪意あるサーバー（攻撃者が制御）が機微データを収集することになる
  • この攻撃シナリオでは、Notion AI内でClaude Sonnet 4.0モデルを使用していたにもかかわらず、セキュリティガードレールが回避されることが確認された

MCP統合がNotion AIエージェントの攻撃表面を拡大する仕組み

  • NotionはGitHub、Gmail、Jiraなど多様なソースのAI Connectorをサポートしている
  • 各コネクタがエージェントに提供するコンテキストやメタデータは追加の攻撃表面を生み、外部ソースからの間接プロンプト注入攻撃によって悪意あるプロンプトが流入する可能性を高める
  • さまざまな意図しない自動化された悪意ある挙動や、機微データ流出の試みのリスクが大きくなる
  • 例示シナリオ: 悪意あるコミットメッセージやIssue本文、外部メールが間接プロンプトとして機能し、エージェントに内部データへのアクセス・送信を命じる可能性

示唆と勧告（要約）

  • 核心的な示唆: エージェントがツールアクセス権限を持つと、文書内の悪意ある指示がツール呼び出しにつながり、機密流出に結びつく可能性がある
  • 防御ポイント（議論項目）:
    • エージェントのツール呼び出しは、出所検証・コンテキスト限定・ポリシーベースのフィルタリングを経るべき
    • 文書内の実行指示文（例: URL生成指針）は、別途の安全検査・人間の確認、または隔離された実行環境で処理すべき
    • MCPコネクタごとに最小権限の原則を適用し、呼び出しログや通知体制の強化が必要
  • 結論: Notion 3.0の機能は生産性向上の可能性が大きい一方で、エージェント・ツール・メモリの結合がもたらす新たな攻撃ベクトルは、実務セキュリティ設計の再検討を求めている

関連記事

1件のコメント

 
GN⁺ 2025-09-21
Hacker Newsの意見
  • Simon Willison が言う "lethal trifecta" とは、LLMエージェント、ツールアクセス、長期記憶の組み合わせによる強力でありながら悪用しやすい攻撃ベクトルを意味する、という説明があるが、それは誤った説明だと強調したい。実際の lethal trifecta は、私的データへのアクセス、信頼できないコンテンツへの露出、外部との通信可能性の3つである。ウェブ検索機能を持つ LLM エージェントは、信頼できないコンテンツへの露出と外部通信の両方に当てはまる。
    • TFA は最初からこの概念を誤解していると思う。Simon Willison の元の出典は この記事 だ。
    • 私の考えでは、trifecta はもっと簡単に説明できる。攻撃者が LLM に入力できさえすれば、あらゆるリソースを制御できるという概念だ。
    • trifecta という名前にふさわしくない説明だ。本当は次の3つである。信頼できない入力、特権アクセス、データ流出ベクトル。
  • プロンプトの組み立て方が、フィッシングキャンペーンの特徴と非常によく似ていると感じる。
    • 権威の主張
    • 偽りの緊急性
    • 技術的正当化
    • セキュリティのふり
      プロンプトインジェクションとは、自我や自己省察がなく、立ち止まって疑う能力のない存在を相手にしたフィッシングのようなものだと思う。
    • この現象は CSRF にも似ていると思う。どちらの攻撃も、システムが信頼する入力を利用して、特権を持つユーザーに意図しない行動を取らせる。悪意ある PDF がプロンプトインジェクションを使い、Notion エージェント（ワークスペースへのアクセス権を保有）に外部ウェブツールを呼び出させてページ内容を外部へ持ち出させる、という形だ。結局のところ本質は同じ権限濫用パターンであり、違うのは技術的な表面がプロンプトインジェクション＋ツールチェイニング（以前なら HTTP リクエスト偽造）に変わっただけだ。
    • 適切な訓練が行われれば、LLM はこうした攻撃に対して「疑う」力を持ち、耐えられるようになる可能性は十分あると思う。ただ、最近のモデルでは「ペルソナ」インジェクションへの耐性強化が対話型の使い方と矛盾している。なので、強化された「エージェント」モデルと、より開放的な対話型モデルに分かれていく可能性が高いと見ている。入力にベースコンテキストを追加して期待値を調整する方法もあり得るが、そのためにはアーキテクチャの変更が必要だと思う。
  • 実際に Notion で試してみたが、URL を検索はするものの、実際にその URL へデータを送信してはいないように見える。検索サービスへの送信部分を除けば、データ流出ポイントがどこなのか気になる。
    • Notion の AI ボットに、ある URL で新しいページを作成してほしいと依頼し、自分のサーバーログを通じて Notion がその URL に実際にアクセスすることを確認した。User-Agent は Chrome/139/Mac だった。
    • 意図としては、クエリ文字列を使って特定の URL へのリクエストを誘発することだったのだと思う。検索ツールはそのようには動作しないようで、あるいはログでは流出の有無を明確に示せないため、成功したかどうかは確定していない状態だ。
  • この攻撃はすでに2年前にデモされたことがある。新しい問題ではない。関連リンク。
    • 問題は、Notion にこの脆弱性があり、それを防止または緩和する措置がまったくなかったことだ。
    • まったく新しくない脆弱性なのに、Notion は今週これをそのまま導入した。見せかけの AI 新機能ばかりに注力した結果だ。
  • instruction/data-conflation 問題に取り組んでいる人がいるのか気になる。LLM がデータ内の指示に無条件で従う状態のままでは、実際のデータソースと外部機能をつなぐのは時期尚早だと思う。Notion は何の警告もなく、Github、GMail、Jira などをモデルに接続するようユーザーに勧めている。このレベルになると、安全な製品の機能として扱うのはほとんど犯罪的だと思う。
    • この問題については3年以上議論されているが、実質的に堅牢な解決策はまだ出ていない。現状ではシステムプロンプトとユーザープロンプトを分離し、一方をより信頼するよう訓練しているが、この方式も脆い。意欲的な攻撃者は依然として回避策を見つけ出す。最も説得力があった緩和策は DeepMind の CaMeL 論文だが、これも機能構成に多くの制約を課す。リンク。
    • 私は今回のエクスプロイトの作成者だ。CodeIntegrity.ai で、エージェント型 AI システムの実際のデータフローと制御フローを可視化し、それぞれのリスクを評価できるプラットフォームを作っている。ランタイムガードレールも提供しており、リスク許容度に応じてフローを制御できる。興味があれば abi@codeintegrity.ai までメール歓迎。
    • あなたの表現の仕方は興味深い。一度、信頼済みデータと非信頼データが明確に区別されたデータ構造を LLM フィードとして使うことを想像してみた。ウェブ検索や MCP の結果はデフォルトで非信頼（ただし、MCP を自分で書いて信頼できるなら例外）。非信頼データには純粋な変換（副作用なし）だけを許可する。たとえば要約、空白除去、float 変換などで、すべてネットワークアクセスのないサンドボックス内で実行する。たとえば「公開 GitHub issue をすべて要約して DB に保存して」といった処理も、非信頼コンテンツをサンドボックス内だけで扱えば安全にできそうだ。
    • まるで「一般ユーザーにコード実行権限を与える問題」にも似ている。実質的な解決策は簡単ではない。
    • 解決策はすでに存在する。これは特殊なデータ問題というより、従来のガードレールでも AI を制限できるという話だ。もしユーザーにデータアクセス権がなければ、LLM も同様に制限されるべきだ。これをそのまま野放しにしている企業のほうがむしろ異常だ。魔法ではない。AI セキュリティに問題のある企業は、他にも深刻な脆弱性を多く抱えていることを意味する。ただ、AI によってそれがより表面化しやすくなっているだけだ。
  • 記事本文は こちら。
    • このリンクのほうが適切だ。私のブログにも参考用のメモがある。関連リンク。
    • 以前の HN 議論へのリンク。URL が更新され、現在は単なる重複になっている（もともとはツイートへのリンクだった）。
  • 最近の Notion はだんだんスパイウェアのように感じられてきた。会議中に、Notion が会議中だと検知したと言って「ノートを取りますか？」というポップアップを何度も出してくる。
  • 「AI」という文句を掲げて公開提供されているツールで見つかる脆弱性を「隠れた」ものと呼ぶのは適切ではないと思う。
  • この記事は実際の脆弱性を具体例で示しており、説明も過度に技術的すぎず、良い記事だった。
  • 一般的なユーザーがどうやって私の Notion インスタンスに文書を入れることになるのか気になる。
    • 単に Google で "best free notion marketing templates" と検索して見つけたものをインポートするだけだ。私も何度もやったし、世界中で何千人、何万人も同じように使っている。
    • 記事では PDF が例だが、Notion エージェントがどのリンクをどう開いて保存するかによっては、クローラー／ブラウザーエージェントごとに異なるウェブページを見せることもできるので、業界で人気のある資料もフィッシングの標的になり得る。
    • 多くの企業が Zapier などの自動化ツールで請求書のような文書を直接アップロードしたり、メールでエクスプロイト文書を受け取って Notion に登録したりしている。
    • Notion には本当にありとあらゆる資料を入れている。DB としても使い、Web クリッパーでオンライン資料も保存し、コラボレーションツールとしても使う。活用方法はさまざまだ。
    • 今回のケースでは、もっともらしいタイトルを付けた PDF をメールで受け取り、同僚と共有しそうな文書に見せかける形だ。悪意ある命令は白背景に白文字などで隠しておく。今後 MCP が公開 issue トラッカーや受信メールまで見られるようになれば、これ以外にもさまざまな攻撃シナリオが出てくるだろう。