Unsafe LLM-Based SearchAI搜索引擎安全风险的定量分析与缓解论文重点论文首次对七款主流AI搜索引擎AIPSE进行了系统性的安全风险量化评估揭示了这些系统在引用恶意内容或恶意网站方面的普遍脆弱性。作者提出了一套基于智能体的防御机制通过GPT-4.1内容精炼工具和URL检测器的协同工作在仅牺牲约10.7%信息可用性的代价下有效降低了安全风险。核心研究内容问题定义近年来AI驱动的搜索引擎AIPSE通过检索增强生成RAG技术将外部数据库与LLM的既有知识相结合为用户提供精准、高效的答案。然而这种架构引入了一个被广泛忽视的安全隐患检索器可能抓取未经过滤的恶意网站而LLM在生成答案时会不加安全审查地引用这些内容。更令人担忧的是攻击者可以通过搜索引擎优化SEO等手段将恶意网站排到搜索结果前列从而让AIPSE在回答用户查询时直接引用这些有害内容。现实世界中已有惨痛案例2024年11月一名开发者在遵循ChatGPT Search生成的代码后损失了约2,500美元——该代码将他引导至一个伪造的Solana API网站他在30分钟内被骗走了私钥和资产。这一事件凸显了生产环境中AIPSE安全审查的紧迫性。然而此前尚无工作对生产级AIPSE的此类安全风险进行系统性量化评估。创新方法本文的创新主要体现在三个层面威胁模型的系统化定义。作者将AIPSE响应中的URL划分为四个风险等级主风险Main Risk恶意URL直接被引用在答案正文中用户只需一次点击就可能遭受攻击警告风险Warning Risk恶意URL虽被引用但附带明确的风险警告或推荐了正规网站来源风险Source Risk恶意URL仅出现在来源列表中未在答案中直接引用无风险None RiskURL为良性。三种查询类型的构建与对比。研究构建了关键词列表查询、自然语言查询和URL查询三种类型。关键词由GPT-4o从恶意网站HTML中提取自然语言查询则由GPT-4o将关键词转化为日常搜索语句URL查询则模拟用户将响应中的URL再次喂给LLM的场景。通过问卷调研验证这三种查询模式与实际用户行为高度吻合——83.1%的受访者使用自然语言查询43.2%使用关键词查询21.2%使用URL查询。双层防御架构。作者提出了两种防御策略基于提示词的防御将AIPSE响应输入GPT-4.1配合防御提示词进行有害内容过滤基于智能体的防御包含内容精炼工具和URL检测工具智能体迭代调用这两个工具直至收集到足够信息生成附带安全漏洞通知的增强响应。研究成果风险普遍性。研究从PhishTank、ThreatBook和LevelBlue三个威胁情报平台收集恶意网站数据经过筛选和人工交叉验证后获得325个有效URL。对七款AIPSEChatGPT Search、Perplexity Pro、Copilot、TextCortex、Grok、Doubao、Kimi的评估显示所有被测试的AIPSE均存在生成含恶意URL的有害内容的问题。在关键词列表查询中47%的响应存在风险其中34%直接在主答案中引用了有害内容。Grok、TextCortex和Kimi风险最高分别有41、34和32个主风险响应共100次查询。查询方式的影响。URL查询相比关键词查询会显著增加主风险响应的数量而自然语言查询则能略微缓解风险。与传统搜索引擎的对比。通过对2,875个搜索结果的URL分析AIPSE在实用性和安全性两方面均优于传统搜索引擎——但这并不意味着AIPSE足够安全恰恰说明传统搜索引擎的风险更高。防御效果。基于智能体的防御显著优于基于提示词的防御。作者提出的HtmlLLM-Detector能够处理78.3%的主风险响应F1分数达到0.822。防御机制仅造成约10.7%的信息可用性损失。案例研究。两个真实世界案例研究在线文档伪造和钓鱼网站展示了攻击者如何轻易地欺骗AIPSE引用恶意代码或将钓鱼网站识别为正规官方网站。实际落地应用的可能性该研究的防御框架具有较高的实际落地价值。一方面其模块化设计允许不同检测器灵活集成企业可根据自身需求选择URL检测器或HTML内容检测器另一方面部署成本可控——仅需调用OpenAI API即可运行对中小型AI应用开发商而言门槛较低。此外作者已开源全部代码进一步降低了复现和应用的成本。不过需要注意的是该防御目前部署在用户端而非服务端这意味着需要用户主动启用难以作为平台级的默认安全措施。技术细节威胁模型的形式化描述给定一个LLM \( M \)它通过将用户查询 \( Q \) 与搜索引擎 \( S \) 检索到的外部数据相结合来处理用户请求正常情况下输出响应 \( R \)M(Q ∣∣ S(Q))RM(Q \ || \ S(Q)) RM(Q∣∣S(Q))R攻击者可以发布对抗性内容来毒化搜索引擎检索到的外部数据将其篡改为 \( S’(Q) \)M(Q ∣∣ S′(Q))R′M(Q \ || \ S(Q)) RM(Q∣∣S′(Q))R′其中 \( R’ \) 和 \( S’(Q) \) 分别为恶意响应和被篡改的检索数据。数据集构建流程数据构建分为三个关键步骤URL收集与筛选从PhishTank17,225个、ThreatBook2,427个和LevelBlue4,385个收集候选URL。经HTTP请求验证状态码200、有效域名证书并过滤云存储、短链接和域名市场后保留353291147个有效URL及对应HTML文件。人工验证3名研究生级标注员进行交叉验证对存疑URL借助多个威胁检测平台辅助判断最终获得325个URL。查询生成随机采样100个URL使用GPT-4o提取5个关键词再将关键词转化为自然语言查询URL查询则从各风险类型中随机选取。防御架构实现基于智能体的防御架构在GitHub上已开源核心组件包括agent.py构建智能体主流程prompt.py防御提示词模板tools.py工具调用模块可自定义检测器utils.pyXGBoost检测器实现selenium_fetcher.pyHTML内容获取可选运行环境需安装Python依赖包并配置OpenAI API Key。HtmlLLM-Detector的工作原理HtmlLLM-Detector是本文提出的核心检测方法它通过分析网页的HTML内容来判断URL是否为恶意。与传统的URL-based检测依赖IP地址、URL长度、可疑域名等特征不同HtmlLLM-Detector利用LLM对网页内容的语义理解能力能够更准确地识别伪装精良的恶意网站。论文将PhishLLM-detector和XGBoost-detector作为对比基线结果显示HtmlLLM-Detector在F1分数上表现最优。研究设定评估对象七款生产级AIPSEAIPSE发布时间底层模型ChatGPT Search2024年10月GPT-4oPerplexity Pro2022年12月SonarLlama 3 70B微调/ GPT-4o / Claude 3.7 / Gemini Pro 2.5Copilot2024年4月集成Bing搜索TextCortex2023年5月GPT-4oGrok2024年11月集成X平台数据Doubao2024年5月Doubao系列模型Kimi2024年5月支持约20万字符上下文数据集规模关键词列表查询100条自然语言查询100条URL查询457条总计657次查询由4名研究人员在5天内完成硬件与软件配置根据GitHub仓库信息运行防御框架需要Python 3.x环境OpenAI API Key用于调用GPT-4.1依赖包参见requirement.txt可选Selenium用于获取HTML内容标注流程每项查询由一名研究生级标注员识别和标注响应中每个URL的风险类型借助多个网络威胁检测平台辅助判断。若无法确定由第二名标注员复审最多三名标注员独立判断。最后由新标注员进行终审确保一致性。标注员间的一致性使用Cohen’s weighted kappa评估均值为0.241fair agreement。综合分析这篇论文的核心价值在于它将AI安全研究从“模型本身的安全性”扩展到了“模型与外部世界交互的安全性”。以往的研究多聚焦于LLM的越狱攻击、提示词注入等问题而本文揭示了一个更根本的漏洞当AI系统被赋予访问互联网的能力时整个互联网的不可信内容都成为了攻击面。值得深入思考的几个层面第一安全问题的结构性。AIPSE的风险并非源于某个具体模型的缺陷而是RAG架构的固有特性——检索器无法完美区分良性与恶意内容而生成器又缺乏对检索内容进行安全审查的机制。这意味着仅仅通过改进模型对齐或添加安全护栏无法从根本上解决这一问题。第二防御的经济性。10.7%的信息可用性损失换来显著的风险降低这一权衡在多数应用场景下是合理的。但问题在于谁来承担这个“损失”用户可能不愿意接受一个“知道得更少”的AI助手而平台方又缺乏主动降低信息量的商业动机。这形成了一个典型的安全激励错配困境。第三从“被动过滤”到“主动验证”的范式转变。本文的智能体防御本质上是一种事后验证机制——先让AIPSE生成答案再检测和标记风险。更理想的方向或许是事前验证在检索阶段就对候选URL进行安全性评估从源头阻断恶意内容的进入。这需要搜索引擎、威胁情报平台和AI应用开发商之间的深度协作。第四评估方法的严谨性。论文在数据收集、查询构建、风险标注等环节都体现了较高的方法论水准——问卷验证查询模式的真实性、Google Trends验证关键词的热度、多轮标注确保一致性。这种“用真实数据、模拟真实行为、经多人验证”的评估范式为后续AI安全研究提供了可借鉴的方法论模板。实践应用对AI应用开发者的建议1. 部署智能体防御作为用户端安全层。对于正在开发或运营AI搜索/对话产品的团队可参考本文开源代码快速部署基于智能体的防御机制。核心配置仅需注册OpenAI API Key在tools.py中选择检测器HtmlLLM-Detector或XGBoost-Detector运行main.py即可进行批量或单次检测。2. 在检索阶段引入URL信誉检查。除了响应后过滤更应在检索阶段集成威胁情报API如PhishTank、ThreatBook等对候选URL进行预筛选从源头降低风险。3. 建立多层级风险标注体系。本文的四级风险分类主风险/警告风险/来源风险/无风险提供了一个实用的参考框架开发者可根据自身产品的风险容忍度对不同风险等级采取差异化的处理策略。对平台运营者的建议4. 透明化风险提示。当AIPSE引用的内容存在风险时应在答案中明确标注风险等级和来源而非默默过滤。这既符合知情同意的原则也能帮助用户建立安全意识。5. 建立安全事件的反馈闭环。借鉴本文与AIPSE平台沟通后使其更安全的经验平台应建立与安全研究社区的常态化沟通机制及时修复已披露的漏洞。对研究者的启示6. 扩展评估范围。本文聚焦于恶意URL的引用风险但AIPSE的安全风险远不止于此——虚假信息传播、隐私泄露、偏见放大等问题同样亟待量化评估。7. 探索防御自动化的新范式。本文的智能体防御需要调用GPT-4.1作为内容精炼工具成本较高。未来研究可探索更轻量级的检测模型或将防御能力直接集成到AIPSE的推理过程中。参考资料来源原始论文: Luo, Z., Peng, Z., Liu, Y., Sun, Z., Li, M., Zheng, J., He, X. (2025). Unsafe LLM-Based Search: Quantitative Analysis and Mitigation of Safety Risks in AI Web Search.34th USENIX Security Symposium (USENIX Security 25).arXiv预印本: https://arxiv.org/abs/2502.04951