Agent Security

AIエージェントのSSRF対策|URL取得ツールを安全にする設計【2026】

AIエージェントのURL取得ツールをSSRFから守るためのURL正規化、IP検査、redirect制御、egress分離、監査を解説。

古野光太朗古野光太朗·2026.09.03·一次情報 6件
AIエージェントのURL取得を検査し内部ネットワークへの通信を遮断するSSRF対策の図

Web調査や資料取得を行うAIエージェントには、URLを受け取り、サーバー側からアクセスするツールがよく組み込まれます。ここでモデルが生成したURLや利用者の入力をそのままfetchすると、SSRFによって内部管理画面、cloud metadata、localhost、非公開APIへ到達される可能性があります。

プロンプトに「内部URLへアクセスしない」と書くだけでは防げません。モデルの判断とネットワーク境界を分離し、取得ツール側で強制する必要があります。

まず取得対象を二つに分ける

最初に、既知の取引先APIや自社ドメインだけを取得するのか、任意の公開Webへアクセスするのかを決めます。

既知の対象だけなら、scheme、hostname、port、pathをallowlistへ固定します。任意の公開Webが必要な場合は、単純なdomain allowlistだけでは足りません。DNS解決後のIP、redirect先、プロトコル、応答サイズ、Content-Typeまで検査します。

OWASPはSSRF対策を、既知の信頼先だけへ送る場合と、任意外部先へ送る場合に分け、redirectを無効化することを推奨しています。AIエージェントでも同じ境界をtool implementationへ置きます。

URL解析は文字列の前方一致で済ませない

https://example.com.evil.invalid、userinfoを含むURL、Unicodeや末尾ドット、IPv6表記など、見た目と実際の接続先が異なる入力があります。標準URL parserで正規化し、許可schemeをhttpsなど必要最小限に限定します。

file:gopher:data:ftp:など不要なschemeは拒否します。portも80/443など必要なものだけに限定し、URLに埋め込まれたcredentialは受け付けません。

DNS解決後のIPを検査する

hostnameが公開名でも、DNSがloopbackやprivate addressを返す場合があります。接続直前に解決した全IPを検査し、loopback、link-local、private、multicast、予約済み範囲を拒否します。IPv4だけでなくIPv6も対象です。

DNS rebindingを考えると、検査時と接続時に別の解決結果を使わない構成が必要です。可能なら専用egress proxyで解決と接続を一体化し、アプリ本体から内部ネットワークへ直接到達できないようにします。

redirectごとに再検査する

最初のURLが安全でも、302などで内部URLへ転送されることがあります。不要ならredirectを無効化します。必要な場合は自動追従せず、一段ごとにscheme、host、port、解決IPを再検査し、回数を制限します。

また、HTML内の画像や埋め込みをブラウザのように自動取得しないことも重要です。取得対象は主responseだけに絞ります。

資源制限と内容検査を入れる

公開URLでも、巨大ファイルや終了しないstreamは可用性を損ないます。接続・読み取りtimeout、最大redirect、最大response bytes、許可Content-Typeを設定します。PDFや画像が必要なら別経路でsandbox処理し、取得プロセスへ秘密情報や広い権限を渡しません。

外部ページは信頼できない入力です。ページ内の「この指示を実行せよ」をエージェント命令として扱わず、取得内容をデータとして隔離します。SSRF対策とprompt injection対策は別の防御層です。

監査ログとテスト

ログにはrequest ID、呼び出したtool、入力host、解決先の分類、判定、response size、redirect回数、error classを残します。URL全体にtokenや個人情報が含まれる場合があるため、query stringは既定で保存しません。

テストでは、localhost、private IPv4、IPv6 loopback、link-local、数値IP、redirect、DNS rebinding相当、巨大response、遅いresponseを含めます。正常系だけでなく、拒否がfail-closeで働くことを確認します。

海外の一次情報と適用限界

OWASPはSSRF対策として許可リスト、URL・ドメイン・IPの検証、ネットワーク層の制限を組み合わせる考え方を示しています。AWSもメタデータサービスへの防御としてIMDSv2を提供しますが、特定クラウドの設定だけで、localhost、IPv6、redirect後の再解決、社内APIへの到達を防げるわけではありません。入力検査とegress制御の片方だけに依存しないことが実務上の要点です。

AIエージェントのセキュリティを確認したい方へ

TechWorkerでは、AIエージェントのtool権限、外部通信、秘密情報、監査ログをコードと構成の両方から確認します。URL取得機能を入口に、実際に到達できるネットワークとデータ境界を棚卸しします。

外部コンテンツからの命令混入はLLMアプリのプロンプトインジェクション対策、管理画面の境界はCloudflare Accessによるゼロトラスト構成も参照してください。

一次情報と確認範囲

確認日:2026年9月3日。製品仕様・制度は更新されるため、導入時はリンク先の最新版を再確認してください。海外の制度・職業規範は日本へ直接適用せず、相違点と限界を本文に明記しています。

  1. OWASP「SSRF Prevention Cheat Sheet」
  2. IETF RFC 1918「Private Internets」
  3. IETF RFC 4291「IPv6 Addressing Architecture」
  4. IETF RFC 6890「Special-Purpose Address Registries」
  5. AWS「Configure the Instance Metadata Service」
  6. WHATWG「URL Standard」
古野光太朗
古野光太朗 / 株式会社TechWorker 代表取締役 CEO兼CTO

上場企業を含む37社・2,500名の生成AI導入・研修支援で得た実務知をもとに、導入・運用・顧客理解を扱っています。この実績はTechWorkerの生成AI支援実績であり、個別製品の導入実績を示すものではありません。

AIエージェントの外向き通信を安全にする

URL正規化、DNS・IP検査、redirect再検査、egress制御、上限、監査ログを実際のツール境界に沿ってレビューします。

AIセキュリティを相談する
← AIセキュリティ・ラボの記事一覧に戻る