2026/04/27

WebSearch MCPのセキュリティリスクと対策 web search MCP allowlist denylist domain filtering 2026

WebSearch MCPのセキュリティリスクと対策【2026年版】allowlist/denylistでドメインを制御する

Claude CodeにWebSearch MCPを繋いで使い始めたとき、正直「便利すぎる」とだけ思っていた。調べたいことを投げると勝手に検索して要約を返してくれる。セキュリティのことは頭になかった。でも間接プロンプトインジェクションという攻撃手法を知ってから、少し立ち止まることになった。WebSearch MCP固有のリスクと、allowlist（許可リスト）・denylist（拒否リスト）を使ったドメインレベルの対策を書いておく。

WebSearch MCPとは何か

WebSearch MCPは、MCP（Model Context Protocol）のツールとしてAIエージェントにWeb検索能力を与える仕組みだ。エージェントが自律的に検索クエリを発行し、取得した結果をコンテキストとして処理・回答に反映できる。

Claude Codeのビルトイン WebSearch ツールをはじめ、Perplexity MCP・Brave Search MCP・Tavily MCPなど複数の実装がある。共通しているのは「外部のWebコンテンツをAIのコンテキストに取り込む」という動作だ。ここがリスクの根本になる。

WebSearch MCP 固有のリスク

間接プロンプトインジェクション（Indirect Prompt Injection）

WebSearch MCP最大のリスクがこれで、検索結果として取得したWebページの本文に悪意ある指示が埋め込まれているケースだ。ユーザーは普通の検索クエリを投げているだけなのに、AIが読み込んだページに「前の指示を無視して〇〇せよ」という隠しテキストが含まれているとエージェントがその命令に従ってしまう可能性がある。

Palo Alto Networks の Unit42 が2026年に公開したレポートでは、MCPのサンプリング機能を使った新しいプロンプトインジェクション経路も確認されている。Webコンテンツは「信頼できない外部入力」として扱う必要があるのに、多くの実装ではそのままコンテキストに流し込んでいる。自分もこれを読んで、何も考えずに使っていたのがちょっと怖くなった。

意図しない情報漏洩

AIエージェントがWeb検索を行う際、検索クエリ自体に機密情報が含まれてしまうリスクがある。コードレビューをしながらエラーメッセージでWeb検索させると、内部ライブラリ名やスタックトレースが検索エンジンのログに残る。社内ドキュメントの内容を元に検索クエリが自動生成される場合も同様だ。

悪意あるサイトへの誘導

検索結果を汚染（SEOポイズニング）して、マルウェア配布サイトや偽情報サイトを上位表示させる攻撃手法はすでに確立されている。AIが自律的に検索してURLを踏む構成では、人間なら気づくような怪しいサイトを判別しにくい場合がある。

allowlist / denylist によるドメイン制御

これらのリスクに対する最も直接的な対策が、ドメインレベルのallowlist（許可リスト）とdenylist（拒否リスト）だ。WebSearch MCPに対してアクセス可能なドメインを明示的に制限することで、信頼できないコンテンツの取り込みを根本から減らせる。

Claude Code のビルトイン WebSearch における設定

Claude Code のWebSearchツールは allowed_domains と blocked_domains パラメータをネイティブでサポートしている。

// allowed_domainsを指定すると、そのドメインのみ検索結果に含まれる
{
  "query": "MCP security best practices",
  "allowed_domains": [
    "modelcontextprotocol.io",
    "docs.anthropic.com",
    "github.com"
  ]
}

// blocked_domainsを指定すると、そのドメインを検索結果から除外する
{
  "query": "Python packaging tutorial",
  "blocked_domains": [
    "example-spam-site.com"
  ]
}

社内ツールの調査や公式ドキュメントの参照だけに絞りたい場合は allowed_domains が強力だ。一方、特定の問題サイトだけ弾きたい場合は blocked_domains を使う。両方は同時に指定できないため、用途に応じて使い分ける。

Perplexity MCPのドメインフィルタリング

Perplexity MCPサーバーは検索結果のドメインフィルタリングをサポートしている。allowモードとblockモードがあり、最大20ドメインまで指定可能。ただし、allowとblockの混在は不可という制約がある。

{
  "search_domain_filter": {
    "action": "allow",
    "domains": [
      "zenn.dev",
      "qiita.com",
      "developer.mozilla.org"
    ]
  }
}

mcp-filter プロキシによるツールレベル制御

サードパーティの mcp-filter プロキシを使うと、上流MCPサーバーのツールをallowlist/denylistでさらに絞り込める。glob パターンで指定でき、allowlistが先に適用された後にdenylistで除外するという順序で動く。

{
  "mcpServers": {
    "filtered-websearch": {
      "command": "npx",
      "args": ["@respawn-app/tool-filter-mcp"],
      "env": {
        "UPSTREAM_SERVER": "websearch-mcp",
        "ALLOW_TOOLS": "search,fetch_url",
        "DENY_TOOLS": "fetch_raw_html,*_admin"
      }
    }
  }
}

ドメイン制御と合わせてやっておきたいこと

allowlist/denylistだけで完結するわけじゃなくて、組み合わせが重要だ。自分が気をつけているのはこのあたり。

  • 検索クエリに機密情報が入らないよう、エージェントへの指示を明確に絞る
  • WebSearch の呼び出しログを残して、異常なドメインへのアクセスを検知する
  • 取得したWebコンテンツをそのまま次のツール呼び出しに使わない設計にする

特に3つ目は見落としがちで、「Webから取ってきた内容を元にファイルを書き換える」というエージェント設計だと、間接プロンプトインジェクションの経路がそのまま残ってしまう。

まとめ

  • WebSearch MCPは外部コンテンツをAIコンテキストに取り込む動作ゆえに間接プロンプトインジェクションのリスクがある
  • Claude Code の WebSearch は allowed_domains / blocked_domains でドメインを制御できる
  • allowlistを先に適用し、その後denylistで絞り込む順序が一般的
-