【2026年版】”放置された参照先”が乗っ取られる——AIエージェントの「ダングリング参照テイクオーバー」対策ガイド｜期限切れドメイン・廃止されたMCPエンドポイント・消えたドキュメントURL・削除されたクラウドストレージ名を攻撃者が取得し直し、エージェントが”信頼済みの参照先”として毒を読み込む手口と、参照先インベントリ・ドメイン/バケットの保有監視・参照のピン留めと署名検証・失効時の自動遮断による多層防御

はじめに——攻撃者は”侵入”せず、”持ち主のいなくなった名前”を買い直すだけ
前提——ダングリング参照テイクオーバーとは何か
エージェントの”参照先”はどこに潜んでいるか
攻撃シナリオ——4つの典型パターン
なぜエージェントでは被害が大きくなるのか
第1の防御層：参照先インベントリ
1. 参照先を機械的に抽出する
2. 台帳に持たせるべき項目
第2の防御層：ドメイン・バケットの保有状態監視
1. 監視すべきシグナル
2. “成功”を疑う監視設計
第3の防御層：参照のピン留めと署名検証
1. コンテンツのピン留め
2. 署名による出自の検証
第4の防御層：失効時の自動遮断
1. 段階的な自動レスポンス
2. fail-closedを原則にする
廃止（デコミッション）手順に”参照の掃除”を組み込む
検知→遮断→監査のインシデント連携
多層防御チェックリスト
よくある質問（Q&A）
まとめ——信頼の根拠を”名前”から”保有状態と鍵”へ
参考リンク

はじめに——攻撃者は”侵入”せず、”持ち主のいなくなった名前”を買い直すだけ

これまでのAIセキュリティ記事では、AIが存在しないパッケージ名を幻覚する「スロップスクワッティング」や、MCPサーバーの持ち主が後から中身を書き換える「ツールポイズニング／ラグプル」など、“参照先の中身”が汚染される攻撃を扱ってきました。しかし、もう一つ見落とされやすい攻撃面があります。それは、エージェントがかつて信頼していた参照先が持ち主を失い、その名前を攻撃者が取得し直すという攻撃です。

AIエージェントは、システムプロンプト、RAGの取り込み元、ツール定義、MCPエンドポイント、許可リストの中に、大量の外部URLやホスト名、ストレージ名を抱えています。プロジェクトが終わってドメインの更新を止めた、検証用のクラウドストレージを削除した、ベンダーがMCPエンドポイントを廃止した——そのとき、参照先の”名前”だけが設定ファイルの中に取り残されます。攻撃者が同じドメインを再登録し、同じバケット名を作り直せば、エージェントは「前から信頼している参照先」として攻撃者のコンテンツを読み込み、指示に従ってしまいます。

これは、Webセキュリティの世界で長年知られてきたサブドメインテイクオーバー（ダングリングDNS）のAI版です。筆者はネットワークのNOC/TACで長年DNSやドメイン、経路の運用トラブルに向き合ってきましたが、「消し忘れたCNAME」「更新切れのドメイン」が事故の起点になるのは昔から変わりません。違うのは、AIエージェントの場合、読み込んだコンテンツが”データ”ではなく”指示”として実行され得る点です。

本記事では、この攻撃を「ダングリング参照テイクオーバー（Dangling Reference Takeover）」と呼び、手口の整理と、参照先インベントリ・保有監視・ピン留めと署名検証・失効時の自動遮断による多層防御を実装の視点で解説します。想定読者は、社内外でAIエージェントやRAGを運用する情シス・セキュリティ担当者、MCPサーバーを導入している開発チーム、AIガバナンスを担うCISOの方々です。

前提——ダングリング参照テイクオーバーとは何か

サブドメインテイクオーバーとの対応関係

従来のサブドメインテイクオーバーは、shop.example.co.jp のCNAMEが削除済みのクラウドリソースを指したまま放置され、攻撃者がそのリソース名を取得して自社のサブドメイン上でコンテンツを配信できてしまう問題でした。ダングリング参照テイクオーバーは、これと同じ構造がエージェントの”参照設定”の中で起きるものです。

観点	サブドメインテイクオーバー（従来）	ダングリング参照テイクオーバー（AIエージェント）
取り残されるもの	DNSレコード（CNAME等）	プロンプト・RAG設定・ツール定義・許可リスト内のURL／ホスト名／ストレージ名
攻撃者の行動	削除済みクラウドリソース名を取得	期限切れドメインの再登録、削除済みバケット名の再作成、廃止エンドポイントの乗っ取り
被害の出方	自社ドメイン上でのフィッシング・Cookie窃取	エージェントが攻撃者のコンテンツを「信頼済み」として読み込み、指示実行・データ送信・誤回答
気づきにくさ	人がブラウザで見れば気づく場合がある	人が見ない。エージェントは200 OKが返れば黙って処理を続ける

既存の攻撃テーマとの違い

当サイトで扱ってきた関連テーマと並べると、本稿の位置づけがはっきりします。ポイントは「持ち主が入れ替わる」ことと、それが「過去に信頼された名前」で起きることです。

テーマ	参照先は実在したか	持ち主は誰か	本質
スロップスクワッティング（6/9記事）	存在しなかった（AIが幻覚）	最初から攻撃者	存在しない名前を先回りで登録
MCPツールポイズニング／ラグプル（7/28記事）	実在・信頼済み	同じ持ち主のまま	持ち主が中身を書き換える
AIサプライチェーン攻撃（6/29記事）／AI-SPM（9/3記事）	実在	（棚卸し対象）	コンポーネント・資産の把握
ダングリング参照テイクオーバー（本稿）	かつて実在・信頼済み	正規の持ち主→攻撃者へ入れ替わる	参照先の”保有状態”が切れた瞬間を突く

サプライチェーン対策やAI-SPMは「何を使っているか」を棚卸ししますが、「その名前を今も自社（または信頼する相手）が保有しているか」までは見ていないことがほとんどです。本稿はこの盲点に絞ります。

従来の世界で起きてきた”前例”

この種の攻撃は机上の空論ではありません。AI以前から、次のような事例・調査が繰り返し報告されています。

放棄されたクラウドストレージの再取得：2025年にはセキュリティ企業watchTowrが、ソフトウェアの更新処理や設定が参照したまま放置されていた約150のAmazon S3バケット名を取得し直したところ、2か月で800万件超のリクエストが届いたと公表しています。もし悪意ある攻撃者であれば、更新ファイルや設定を差し替えられた可能性がありました。
期限切れドメインによるアカウント乗っ取り：パッケージレジストリでは、メンテナーの連絡先メールアドレスのドメインが失効し、第三者が再登録してパスワードリセットを受け取れる状態になっていたことが研究者により指摘されてきました。
リポジトリジャッキング：GitHubでユーザー名やOrganization名が変更・削除された後、旧名を第三者が取得し、旧URLを参照していたビルドスクリプトが攻撃者のリポジトリを取り込む問題です。

いずれも「名前は残っているが、持ち主が変わった」という同じ構造です。AIエージェントは、この構造をより多く、より見えにくく、より実行に近い場所に抱え込みます。

エージェントの”参照先”はどこに潜んでいるか

まず、エージェントがどこに外部参照を抱えているかを整理します。多くの組織では、これらが別々のチーム・別々のファイルで管理されており、全体を一覧できる人がいません。

潜伏場所	典型的な参照の例	放置されやすい理由
システムプロンプト	「最新の料金は https://campaign-2025.example.jp/price を参照すること」	プロンプトはコード扱いされず、レビューや棚卸しの対象外になりがち
RAGの取り込み元	クロール対象URL、外部ナレッジサイト、パートナーのドキュメントサイト、ストレージのパス	定期クロールが自動で回り続け、取り込み元の生死を誰も確認しない
ツール定義・MCPエンドポイント	リモートMCPサーバーのURL、OpenAPI定義の取得先、Webhook送信先	ベンダーの廃止・社名変更・ドメイン移行に追随できない
許可リスト（allowlist）	Web閲覧・取得を許可するドメイン一覧、送信先ドメイン一覧	「追加」はされても「削除」はされない。許可リストは増える一方
エージェント間連携	A2AのAgent Card取得URL、委任先エージェントのエンドポイント	連携先の組織変更をこちらが知る手段がない
メモリ・キャッシュ・過去の会話	過去に参照したURLや「信頼できる情報源」としての記憶	設定ファイルの外にあり、棚卸しの網にかからない
モデル・データセットの取得元	モデルハブのリポジトリ名、データセットの公開ストレージ	一度ダウンロードしたら取得元への関心が薄れる

特に注意すべきは許可リストです。許可リストは「ここなら安全」という宣言なので、そこに載ったドメインが攻撃者の手に渡ると、防御の仕組みそのものが攻撃者の通り道を保証することになります。

攻撃シナリオ——4つの典型パターン

パターン1：期限切れドメインの再登録

キャンペーン用、検証用、旧ブランド名などで取得したドメインは、役目を終えると更新が止まります。しかし、システムプロンプトやRAGのクロール対象、Web閲覧の許可リストにはそのドメインが残ったままです。ドメインが失効し、猶予期間を経て一般開放されると、攻撃者は数千円で同じドメインを取得できます。

攻撃者はそのドメインに、エージェント向けの間接プロンプトインジェクションを仕込んだページを置きます。人間には普通の告知ページに見えても、エージェントには「この情報源の指示を優先せよ」「問い合わせ内容を次のフォームに送信せよ」といった指示として読まれます。エージェントにとっては”いつもの参照先”なので、警戒する理由がありません。

パターン2：廃止されたMCPエンドポイントの乗っ取り

リモートMCPサーバーを提供していたベンダーがサービスを終了したり、ドメインを移行したりすると、旧エンドポイントのホスト名が空きます。旧ドメインを攻撃者が取得してMCPサーバーを立てれば、クライアント側の設定に残った旧URLに接続した瞬間、攻撃者が定義したツール（説明文・パラメータ・返り値）がエージェントに提示されます。

ツールの説明文は、それ自体がモデルへの指示になります。ラグプルが「同じ持ち主による書き換え」だったのに対し、こちらは持ち主ごと入れ替わるため、ベンダーとの信頼関係や契約は一切効きません。

パターン3：消えたドキュメントURLへの”後入り”

パートナー企業のドキュメントサイトや、外部の技術解説ページをRAGに取り込んでいるケースです。参照先のサイトが閉鎖されると、通常はクロールが404やDNSエラーで失敗するだけです。しかし、そのドメインが第三者に渡ると、クロールが再び”成功”し始めます。取り込みパイプラインは「復旧した」と判断し、攻撃者のコンテンツを社内ナレッジとしてインデックスします。

ここで怖いのは、汚染がエラーではなく成功として記録されることです。監視が「失敗」しか見ていなければ、何も検知されません。

パターン4：削除されたクラウドストレージ名の再作成

Amazon S3、Google Cloud Storage、Azure Blob Storageなどのバケット名やストレージアカウント名は、多くの場合グローバルに一意で、削除すると第三者が同じ名前を作れるようになります。RAG用の文書置き場、プロンプトテンプレートの配布元、ツール定義のJSON置き場、モデル重みの配布元としてストレージのURLを直接参照していた場合、同名のストレージを作り直すだけで中身を差し替えられます。

公開読み取り設定のバケットを参照するRAGパイプラインは、認証なしで取り込むことが多いため、攻撃者にとって最も手軽な入口になります。

なぜエージェントでは被害が大きくなるのか

同じ”放置された名前”でも、人間が使うWebサイトとAIエージェントでは被害の構造が違います。

信頼の継承：エージェントは「設定に書いてある参照先＝信頼済み」として扱います。持ち主が変わったことを知る手段を、標準ではまったく持っていません。
人の目が入らない：人間なら「サイトの雰囲気が変わった」「証明書の発行元が違う」と違和感を持てますが、エージェントはHTTPステータスとテキストしか見ません。
コンテンツが指示になる：読み込んだテキストが間接プロンプトインジェクションとして作用し、ツール実行やデータ送信につながります。
許可リストを素通りする：外部アクセスを許可リストで制限していても、乗っ取られたドメインが許可リストに載っていれば防御は機能しません。
汚染が長く残る：RAGのインデックスやエージェントのメモリに取り込まれた内容は、参照先が元に戻っても残り続けます。

OWASPのLLMアプリケーション向けTop 10（2025年版）ではサプライチェーンやデータ・モデルポイズニング、過剰な権限（Excessive Agency）が、エージェント型アプリケーション向けのTop 10ではエージェントのサプライチェーンやメモリ・コンテキストの汚染が取り上げられています。ダングリング参照テイクオーバーは、これらのリスクに“保有状態の変化”という入口から到達する経路と位置づけられます。

第1の防御層：参照先インベントリ

監視も遮断も、「何を参照しているか」が分からなければ始まりません。最初にやるべきは、エージェントが抱える外部参照を一つの台帳にまとめることです。

参照先を機械的に抽出する

手作業の棚卸しは必ず漏れます。次のソースから、URL・ホスト名・ストレージ名を正規表現やパーサーで機械的に抽出し、定期的に台帳と突き合わせる仕組みを作ります。

システムプロンプト、プロンプトテンプレート（リポジトリ管理されていなければ、まず管理下に置く）
RAGのクロール設定、コネクタ設定、取り込みジョブの定義
MCPクライアント設定ファイル、ツール定義、OpenAPI定義
Web閲覧・外部送信の許可リスト、プロキシ設定
IaC（Terraform等）、CI/CDの設定、コンテナイメージ内の設定ファイル
エージェントの実行ログに現れた実際の外部アクセス先（設定外の参照を見つけるため）

最後の「実行ログからの逆引き」が重要です。設定に書かれていなくても、エージェントがメモリや過去の会話から参照先を持ち出していることがあるため、“設定上の参照先”と”実際のアクセス先”の差分を定期的に確認します。

台帳に持たせるべき項目

項目	内容	目的
参照先	URL、ホスト名、ストレージ名、MCPエンドポイント	監視対象の特定
参照元	どのエージェントの、どの設定・プロンプトから参照されているか	遮断時の影響範囲の把握
保有者	自社（部署・担当者）／取引先／第三者	保有状態の確認先
登録情報	ドメインの有効期限、レジストラ、ネームサーバー、ストレージのアカウント	失効の予兆検知
用途と権限	情報参照のみ／ツール実行／外部送信／許可リスト	リスクの重み付け
期待値	コンテンツのハッシュ、署名鍵、証明書の発行元、ツール定義のハッシュ	ピン留め・差分検知
レビュー期限	次回の見直し日、廃止予定日	“使われていない参照”の掃除

台帳はYAMLやJSONでリポジトリ管理し、監視ジョブが直接読める形にしておくと、後の自動化がスムーズです。

- ref: https://docs.partner-example.jp/api/
  used_by: [support-agent, sales-rag]
  owner: third_party            # self / partner / third_party
  usage: rag_ingest             # info_only / tool / egress / allowlist
  domain_expiry: 2027-03-31
  expected:
    nameservers: [ns1.partner-dns.jp, ns2.partner-dns.jp]
    cert_issuer: "Example CA"
  review_by: 2026-12-31
  on_change: quarantine         # quarantine / block / alert

第2の防御層：ドメイン・バケットの保有状態監視

台帳ができたら、各参照先が「今も正規の持ち主の手にあるか」を継続的に監視します。ここは、ネットワーク運用で培われてきた監視の発想がそのまま使える領域です。見るべきは”死活”ではなく”持ち主の変化”です。

監視すべきシグナル

シグナル	確認方法	意味するもの
ドメイン有効期限の接近	RDAP（WHOISの後継プロトコル）で定期取得	自社ドメインなら更新漏れ、他社ドメインなら廃止の予兆
ドメインのステータス変化	RDAPのステータス（失効猶予・削除待ち等）	一般開放が近い。最優先で参照を外す
登録日・レジストラの変化	RDAPの登録日が新しくなった、レジストラが変わった	再登録された可能性が高い（最重要シグナル）
ネームサーバー・Aレコードの変化	DNSの定期解決と前回値との比較	ホスティング移行または乗っ取り
NXDOMAIN・解決失敗の発生	DNS解決結果の監視	持ち主が手放した直後。”空き”の状態
証明書の発行元・発行パターンの変化	Certificate Transparencyログの監視	新しい持ち主が証明書を取得した
ストレージの存在・所有アカウントの変化	自社ストレージは所有アカウントIDの検証、外部は存在確認とレスポンスの差分	削除後の再作成
失敗していた取得が”成功”に転じた	RAGクロールやツール呼び出しの結果履歴	空き→再取得のパターン。自動復旧扱いにしない

“成功”を疑う監視設計

一般的な監視は「失敗したらアラート」です。しかしダングリング参照テイクオーバーでは、失敗が続いた後の成功こそが最も危険なシグナルです。NXDOMAINや404が一定期間続いた参照先が、ある日突然200を返し始めたら、それは「復旧」ではなく「持ち主が変わった」と見なして隔離します。

また、自社が保有するドメインやストレージについては、有効期限の90日・30日・7日前のように段階的にアラートを出し、更新判断と参照の掃除をセットで行う運用にします。ドメインの自動更新を有効にしていても、支払いカードの期限切れや担当者の退職で更新が止まる事故は珍しくありません。

第3の防御層：参照のピン留めと署名検証

保有監視は”予兆”を捉える仕組みですが、検知が間に合わないこともあります。そこで、仮に持ち主が入れ替わっても攻撃者のコンテンツを受け入れない仕組みを重ねます。

コンテンツのピン留め

ハッシュによる固定：ツール定義、プロンプトテンプレート、OpenAPI定義など、頻繁に変わらないものは取得時のハッシュを台帳に記録し、一致しない場合は読み込まない。
バージョンの固定：モデルやデータセット、MCPサーバーは「最新」ではなく、特定のバージョン・コミット・リビジョンを指定して取得する。
差分承認：RAGの取り込み元のように中身が変わるものは、前回からの差分が大きい場合や、構造（ページ構成・言語・文体）が急変した場合に取り込みを保留し、人の承認を挟む。

署名による出自の検証

ピン留めは「変わったこと」は分かっても、「正当な更新かどうか」は判断できません。そこで、参照先のコンテンツに署名を付け、署名鍵で出自を確認する方式を組み合わせます。

自社が配布するプロンプト・ツール定義・ナレッジ文書には署名を付与し、エージェント側で検証してから読み込む（Sigstoreなどの署名基盤の活用も選択肢）。
取引先のMCPサーバーやドキュメントについては、ドメイン名ではなく署名鍵や公開鍵のフィンガープリントを信頼の単位にするよう契約・連携仕様で取り決める。
リモートMCPサーバーへの接続では、OAuth等による相互認証を必須にし、「URLに到達できたら接続する」状態をなくす。

ポイントは、信頼の根拠を”名前”から”鍵”に移すことです。ドメイン名は失効すれば誰でも取れますが、署名鍵は持ち主が手放さない限り移りません。

第4の防御層：失効時の自動遮断

保有状態の変化やピン留めの不一致を検知したら、人の判断を待たずに参照を止める仕組みが必要です。エージェントは24時間動き続けるため、翌営業日の対応では間に合いません。

段階的な自動レスポンス

段階	条件の例	自動レスポンス
注意	有効期限の接近、ネームサーバーの変更	担当者へ通知、台帳のレビュー期限を前倒し
警戒	解決失敗・404の継続、ドメインが失効猶予に入った	新規の取り込み・ツール呼び出しを停止（既存データは維持）
隔離	登録日の更新、所有アカウントの変化、ハッシュ・署名の不一致、失敗→成功への転換	参照を遮断（fail-closed）、許可リストから一時除外、その参照先由来のRAGデータを検索対象から外す
復旧判断	正規の持ち主による保有と内容の正当性を確認	人の承認を経て再開。不要なら台帳・設定から完全削除

fail-closedを原則にする

参照先の検証ができない場合、「とりあえず読み込む（fail-open）」ではなく「読み込まない（fail-closed）」を既定にします。エージェントの回答品質は一時的に下がりますが、攻撃者の指示を実行するより、一時的に回答できない方がはるかに安全です。業務影響が大きい参照先については、事前に代替の参照先やキャッシュ済みの正規データを用意しておきます。

廃止（デコミッション）手順に”参照の掃除”を組み込む

ダングリング参照の多くは、攻撃ではなく廃止手順の順序ミスから生まれます。ネットワークの世界でも「機器を撤去する前に経路を消す」のが鉄則ですが、AIエージェントでも同じです。

参照を先に消す：ドメインやストレージを手放す前に、台帳で参照元を確認し、すべてのプロンプト・RAG設定・ツール定義・許可リストから参照を削除する。
実アクセスが止まったことを確認する：一定期間、実行ログ上でその参照先へのアクセスがないことを確認する。
派生データを掃除する：その参照先から取り込んだRAGのインデックス、エージェントのメモリ、キャッシュを削除または失効させる。
名前は”すぐに手放さない”：ドメインやストレージ名は、参照が完全に消えたと確認できるまで保有を続ける。外部に広く参照された可能性があるドメインは、防御的に長期保有することも検討する。
最後にリソースを解放する：上記を完了してから、ドメインの更新停止やストレージの削除を行う。

取引先や外部サービスの参照先については、相手側の廃止をこちらが知るのは困難です。連携開始時に「エンドポイントやドメインを廃止・変更する際は事前に通知する」旨を取り決めておくことが、地味ですが効果的な対策になります。

検知→遮断→監査のインシデント連携

テイクオーバーを検知したら、遮断だけでなく「すでに何を読み込んでしまったか」の調査が必要です。

影響期間の特定：保有状態が変わった時点（RDAPの登録日、CTログの初回発行日、DNSの変化時刻）を起点に、それ以降のアクセスを洗い出す。
汚染範囲の特定：その期間にRAGへ取り込まれた文書、エージェントのメモリへの書き込み、提示されたツール定義を特定し、隔離・削除する。
実行された行動の確認：エージェントのツール実行ログから、外部送信・ファイル操作・権限を伴う操作がなかったかを確認する。
再発防止：なぜ参照が残っていたのかを廃止手順・台帳管理の観点で振り返り、同種の参照を一斉点検する。

このためには、エージェントの外部アクセスとツール実行を、参照先・時刻・取得内容のハッシュ付きで記録しておくことが前提になります。ログがなければ、汚染の範囲を確定できず、インデックス全体を作り直すしかなくなります。

多層防御チェックリスト

層	対策	主に効くパターン
インベントリ	プロンプト・RAG・ツール定義・許可リスト・IaCから参照先を機械抽出し台帳化	全パターン
インベントリ	設定上の参照先と実際のアクセス先の差分を定期確認	全パターン（特にメモリ由来）
保有監視	RDAPでドメインの有効期限・ステータス・登録日を定期取得	期限切れドメイン、廃止MCPエンドポイント
保有監視	DNS・CTログ・ストレージ所有アカウントの変化を監視	全パターン
保有監視	失敗→成功への転換を”復旧”ではなく”隔離”として扱う	消えたドキュメントURL、削除されたストレージ
ピン留め・署名	ツール定義・テンプレートのハッシュ固定、バージョン固定	廃止MCPエンドポイント、削除されたストレージ
ピン留め・署名	信頼の単位を”ドメイン名”から”署名鍵”へ移行	全パターン
ピン留め・署名	リモートMCPは相互認証を必須化	廃止MCPエンドポイント
自動遮断	段階的レスポンスとfail-closedの既定化	全パターン
運用	廃止手順を「参照削除→確認→派生データ掃除→保有継続→解放」の順に標準化	期限切れドメイン、削除されたストレージ
運用	取引先とエンドポイント廃止時の事前通知を取り決め	廃止MCPエンドポイント、消えたドキュメントURL
監査	外部アクセス・ツール実行をハッシュ付きで記録	事後調査全般

よくある質問（Q&A）

Q1. 許可リストで外部アクセスを制限していれば安全ではないですか？

許可リストは「どこにアクセスしてよいか」を制限しますが、「その名前を今も誰が持っているか」は確認しません。許可リストに載ったドメインが失効して攻撃者に渡れば、許可リストはむしろ攻撃者のコンテンツへの通り道を保証してしまいます。許可リストにも有効期限とレビュー期限を設け、保有監視の対象に含めることが必要です。

Q2. HTTPSを使っていれば、ドメインが乗っ取られても気づけるのでは？

気づけません。ドメインを正規に再登録した攻撃者は、そのドメインの正当な所有者として、正規の認証局から問題なく証明書を取得できます。HTTPSは通信経路の盗聴・改ざんを防ぎますが、「相手が以前と同じ持ち主か」は保証しません。証明書の発行元や発行パターンの変化をCTログで監視するのは、あくまで”変化の兆候”を捉えるための補助手段です。

Q3. 自社のドメインは自動更新にしているので問題ないですよね？

自社ドメインの失効リスクは下がりますが、十分ではありません。支払い方法の期限切れや担当者の退職、レジストラ移管の失敗などで自動更新が止まる事故は起きます。また、エージェントが参照しているのは自社ドメインだけではありません。取引先・外部サービス・過去のキャンペーンサイトなど、自社でコントロールできない参照先こそ監視が必要です。

Q4. 中小企業でも、ここまでの対策が必要ですか？

すべてを一度に揃える必要はありません。まずは(1) エージェントが参照している外部URLの一覧を作る、(2) 自社ドメインと自社ストレージの有効期限・削除予定を把握する、(3) ドメインやストレージを手放す前に参照を消す、の3点から始めてください。この3点だけで、典型的な事故の多くは防げます。監視の自動化や署名検証は、エージェントの利用範囲が広がる段階で順次導入すれば十分です。

Q5. すでに汚染されたかどうかは、どうやって調べればよいですか？

台帳の各参照先について、RDAPの登録日やCTログの証明書発行履歴を確認し、「エージェントが参照を始めた後に、登録日が新しくなっていないか」「見慣れない証明書が発行されていないか」を確認します。該当があれば、その時点以降に取り込まれたRAGデータやツール定義、エージェントの実行ログを調査してください。ログが残っていない場合は、その参照先由来のデータを一度すべて削除し、正規のソースから再取り込みするのが確実です。

まとめ——信頼の根拠を”名前”から”保有状態と鍵”へ

AIエージェントのセキュリティは、プロンプトインジェクションやツールの悪用といった「中身」の議論が中心でした。しかし、エージェントが抱える大量の参照先は、持ち主が入れ替わった瞬間に、信頼済みのまま攻撃者の入口へと変わります。要点は3つです。

1. まず”何を参照しているか”を一か所に集める。プロンプト、RAG、ツール定義、許可リスト、実行ログから参照先を機械的に抽出し、台帳として管理します。見えない参照は守れません。

2. 死活ではなく”持ち主の変化”を監視する。ドメインの登録日やレジストラ、DNS、CTログ、ストレージの所有アカウントの変化を見ます。特に「失敗が続いた後の成功」は復旧ではなく、乗っ取りのシグナルとして扱います。

3. 名前ではなく鍵を信頼し、検証できなければ止める。ハッシュのピン留めと署名検証で信頼の根拠を移し、検証できない参照先はfail-closedで自動遮断します。そして、廃止時は「参照を消してから名前を手放す」順序を徹底します。

DNSやドメインの世界では、「消し忘れた設定」が事故の起点になることは昔から知られていました。AIエージェントの時代には、その設定がプロンプトやツール定義の中に散らばり、読み込まれたコンテンツが指示として実行されます。「かつて信頼した名前は、今も同じ持ち主とは限らない」——この前提に立って、参照先の保有状態まで含めて守ることが、エージェントを安全に運用するための基本姿勢です。

参考リンク

OWASP Top 10 for LLM Applications（2025年版）／OWASP GenAI Security Project：https://genai.owasp.org/llm-top-10/
OWASP Top 10 for Agentic Applications（OWASP GenAI Security Project）：https://genai.owasp.org/
MITRE ATLAS：https://atlas.mitre.org/
OWASP Web Security Testing Guide「Test for Subdomain Takeover」：https://owasp.org/www-project-web-security-testing-guide/
Microsoft Learn「Prevent dangling DNS entries and avoid subdomain takeover」：https://learn.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover
ICANN「Registration Data Access Protocol（RDAP）」：https://www.icann.org/rdap
Certificate Transparency：https://certificate.transparency.dev/
Model Context Protocol 公式サイト：https://modelcontextprotocol.io/
watchTowr Labs（放棄されたS3バケットの調査）：https://labs.watchtowr.com/

免責事項：本記事は2026年10月時点の公開情報および標準フレームワークに基づく一般的な情報提供であり、特定の製品・構成における安全性を保証するものではありません。また、法的助言ではありません。実際の防御実装は自社環境・脅威モデル・関連法令に照らして検討し、必要に応じてセキュリティ専門家や弁護士にご相談ください。フレームワークやガイドラインは更新されるため、最新情報は各公式ソースでご確認ください。