AI スキルに書かれた外部ドメイン・URL を「依存」として点検する（OpenAI render-deploy 事例）

何が起きたか

• OpenAI の公式スキル集にあった Render 向けデプロイスキル render-deploy が、Render のプライベートネットワーク用ドメインとして *.render-internal.com を案内していた。実際には Render のドメインではなく、未登録だった。
• 研究者（AIR Security）が Codex でこのスキルを使ってデプロイさせると、生成コードの既定値（defaultInternalAPIURL）とデプロイ設定の環境変数に、そのドメインがそのまま入った。
• 研究者がドメインを取得して受信専用のシンクホールに向けたところ、実在の本番アプリからトークン付きのリクエストが届いた。
• 記述は 2026-01 の初回コミットから入っており、Render が 2026-08-14 に削除、OpenAI も 2026-08-26 にプラグインを取り下げ、ドメインは Render 側の管理に移された。

コードの脆弱性でもパッケージの侵害でもなく、「手順書に書かれた事実の誤り」が攻撃面になった点が新しい。

点検のしかた

1. スキル内のホスト名を抜き出す: スキルのフォルダ（SKILL.md と references/ など）から URL・ホスト名・接続文字列を一覧にする。
   bash

   rg -o --no-filename -e 'https?://[A-Za-z0-9.-]+' -e '[A-Za-z0-9-]+(\.[A-Za-z0-9-]+)+:[0-9]{2,5}' -e '\b[a-z0-9-]+\.(com|net|io|dev|app|cloud|ai)\b' path/to/skill | sort -u

2. 各ドメインの実在と所有者を確かめる:
   • dig +short NS <domain> や whois <domain> で登録されているか、登録者が公式ベンダーと一致するか。
   • ベンダーの公式ドキュメントに同じドメインが出てくるか（今回の render-internal.com は Render のドキュメントのどこにもなかった）。
   • 未登録・期限切れ・最近の登録者変更は危険信号。
3. 生成物に既定値として残っていないか見る: エージェントが書いたコードや IaC で、内部 API の URL・DB 接続先がハードコードされた既定値になっていないか。既定値は空にして、未設定なら起動時に失敗させるほうが安全。
4. 外向き通信を許可リストで縛る: 本番の出口通信を既知のドメインだけに絞っておけば、誤った宛先への送信はそもそも通らない（サプライチェーン侵害の「いつもと違う外向き通信」を DNS＋VPC フローで拾うも参照）。
5. スキルもバージョン固定して差分を見る: スキルは公式でも誤りや脆弱性を含みうる。コミットを固定し、更新時は差分のホスト名を同じ手順で確認する（AI エージェント向け RE スキル集を入れる前に確認する（reverse-skill）と同じ考え方）。

注意点

• 「公式」「認証済みベンダー」はレビューを省く理由にならない。スキルが参照するドメイン・リポジトリ・API・アカウントは、すべてサプライチェーンの依存として扱う。
• 社内でスキルを配るときも、架空の例示ドメインは example.com など予約済みのものだけを使う（RFC 2606）。

出典

• @MalwareBibleJP · 2026-10-17
• AIR Security の報告: air.security