Agent 平台里最危险的 URL，往往不是用户直接输入的那个，而是 provider 返回给你的那个。Vercel AI SDK 7.0.25 / @ai-sdk/provider-utils@5.0.9 新增 getFromApi(..., validateUrl)，把 image / video / audio 生成后的下载、轮询 URL 放进和 downloadBlob 类似的校验路径：拒绝 private、loopback、link-local、multicast、文档网段等目标，重定向每一跳都重新校验，跨 origin 时剥掉代理、metadata、cookie 和自定义凭证头。

这个变化的工程含义是：provider response 不是天然可信的“内部结果”，而是另一种外部输入。多模态 Agent 经常会把模型服务返回的 url、file_id、artifact、polling endpoint 继续交给 fetcher、sandbox、browser 或文件入库流程；如果这里不重新做边界判断，一个被污染的 provider、兼容 OpenAI 的代理、或中间层 bug，就可能把服务端拉向 metadata IP、内网控制面，或者把 API key 跟随 redirect 发给第三方域名。

更细的取舍在于，它没有把所有 URL 都一刀切。开发者配置的 provider endpoint 仍然可以 validateUrl: false；同源于可信 provider endpoint 的 response URL 可以通过 trustedOrigin 保留本地/self-hosted 场景；但凡 response body 给出的新 host，就必须显式决定是否带凭证、是否允许跳转、是否允许特殊地址。也就是说，运行时要区分“配置面 URL”和“数据面 URL”。

做 OPC 或 Agent Engineer 时，可以把这个原则落到 connector 设计里：任何来自模型、工具、MCP server、浏览器页面、第三方 webhook 的可抓取地址，都先变成 RemoteResourceRef，再经过 allowlist、IP range、redirect policy、credential scoping、content-type/size limit 和审计记录，最后才允许下载或传给下游工具。

你现在的 Agent 平台里，哪些 URL 是“代码配置的”，哪些其实是“上游响应带回来的”？它们是否走了同一套 fetch helper，还是已经悄悄绕过了边界？