提示词注入漏洞赏金：当“损坏”没有明确定义时，如何划定程序范围

你的安全团队运行着一个行之有效的漏洞赏金计划。CSRF 得到了奖金，XSS 得到了奖金，IDOR 也得到了奖金。交战规则明确，严重程度标准符合行业规范，分拣队列有序移动，该计划产出了源源不断的已修复漏洞。接着，你的 AI 团队在上个季度发布了一个功能 —— 一个聊天界面、一个调用工具的智能体（agent），或是一个从客户数据中提取信息的 RAG 流水线 —— 摆在安全团队桌面上的问题变成了：“这个东西的赏金范围是什么？”没人能回答。

没人能回答的原因是，标准的漏洞赏金准则是围绕行为确定的系统构建的。登录端点要么身份验证正确，要么不正确。访问控制检查要么生效，要么失效。你刚发布的 AI 功能没有等效的基准事实（ground truth）：其规定的行为是“对用户输入做出有帮助的响应”，而一个让它做出无用响应的研究员并不一定发现了漏洞 —— 他们可能只是发现了模型一直以来都在做的事情，只是没人知道，你不确定是否能修复，而且在第二次尝试时可能无法复现。

与此同时，研究人员群体每周都在社交媒体上发布数千个免费的“越狱”演示，而你的团队却没有资金支持的路径将这种能量引导到自己的产品上。HackerOne 2025 年的数据就是预警信号：经过验证的 AI 漏洞报告增加了 210%，提示词注入发现增加了 540%，将 AI 纳入范围的计划增加了 270%。人才和数量已经到位，缺失的是能够将其转化为修复方案而非 Twitter 截图的程序设计。

严重程度的崩溃

一个程序能采取的最具破坏性的捷径，就是将每一个 “AI 安全” 发现都归入同一个类别。这个类别通常包含四种截然不同的情况：

1. 模型说了些无礼或违背政策的话。 用户引导它使用了脏话、写出了品牌准则禁止的配方，或者扮演了一个公关团队觉得尴尬的角色。这是名誉风险，可能有内容审核成本，但没有数据丢失，没有破坏完整性。
2. 系统提示词泄露。 有人让模型逐字背诵其指令。OWASP 将其添加为 LLM07:2025，因为它可以暴露内部逻辑、工具描述、内容规则，有时还有误嵌入的凭据 —— 但就其本身而言，泄露 “你是一个 Acme 的得力助手” 更接近于信息泄露而非漏洞利用。
3. 跨租户数据通过提示词注入被窃取。 研究员在文档中嵌入了一条指令，模型执行了它，导致租户 A 的记录出现在租户 B 的响应中。这是一个真实的机密性泄露，具有可衡量的影响范围。
4. 智能体执行了破坏性操作。 研究员诱导智能体调用了一个工具 —— 删除记录、转账、发送代码、以你的域名发送电子邮件 —— 而这原本是不该调用的。CVE-2025-32711，即 Microsoft 365 Copilot 的零点击提示词注入，在 CVSS 评分中得到了 9.3 分。微软对 Semantic Kernel 的研究表明，在某些智能体框架中，提示词注入可以干净利落地转化为宿主机级别的 RCE。

这四种情况处于完整性、机密性和可用性（CIA）维度的完全不同的点上。用同样的严重程度、同样的报酬和同样的 SLA 来处理它们，会产生预见性的结果：程序被 AI 团队不想修复也不会理会的第 1 类报告淹没，第 3 类和第 4 类的发现被埋在队列后方，而原本可以寻找危险漏洞的研究员会流失到别处，因为他们能看出这个队列充满了噪音。

一个有效的严重程度准则应立足于 CIA 三要素，并为每个层级编写 AI 特有的示例。严重 (Critical)：跨租户数据窃取、未经授权的破坏性工具调用、通过模型逃逸宿主机或沙箱、攻击者指令在会话或用户间的持久化。高 (High)：用户权限范围之外的同租户数据暴露、系统提示词中嵌入的凭据或机密泄露、绕过既定内容策略并产生具有可操作性的有害输出（CSAM、恶意软件代码、武器合成）。中 (Medium)：绕过既定内容策略并产生令人尴尬但不可操作的输出、非敏感系统提示词或工具描述的泄露。低或不计入范围 (Low or out-of-scope)：模型无礼、在不该拒绝时拒绝、在良性话题上胡编乱造，或者在没有现实副作用的环境下通过“越狱”扮演虚构角色并说出禁忌语。仅靠 CVSS 无法胜任这项工作 —— OWASP 的 AIVSS 提案之所以存在，正是因为 CVSS 是为代码评分而设计的，而不是智能体行为 —— 但你主要可以通过用平实的语言编写准则并将支付金额与其挂钩来填补这一空白。

可重现性问题

传统的漏洞赏金计划要求 “功能性的、可独立重现的漏洞利用” —— 许多计划要求重现率达到 50% 以上。如果将这一要求生搬硬套到概率系统中，你就会把大多数真实的发现排除在外。

针对前沿模型有 8% 成功率的提示词注入并非 “不是漏洞”。如果你的智能体每天处理一百万次工具调用，其中一次是转账，那么针对破坏性操作注入的 8% 成功率意味着每天有 80,000 次未经授权的转账。重现要求必须从 “它是否每次都有效” 转变到 “对于能够大规模尝试的攻击者来说，它的成功率是否足以产生价值”。衡量单位是成功率，而不是“是或否”。

一个可行的可重现性条款要求提供：记录在案的提示词或输入产物、记录在案的模型版本和配置（温度、系统提示词范围、工具集）、在 N 次尝试中的记录成功率（通常 N ≥ 20），以及至少证明一次完整成功的对话记录或日志文件。这使得分拣工作从 “我在笔记本电脑上无法重现这一次” —— 这是对非确定性发现的标准拒绝理由 —— 转向 “研究员声称在带有特定工具集的模型版本 X 上有 12/50 的成功率，我们可以根据经验确认或反驳这一点”。

习惯于确定性漏洞的分拣团队会在文化上感到不适。他们想要一个总是返回 200 并在响应体中带有泄露机密的单一 curl 命令。他们必须学会评估分布。不进行这种转型的程序最终会拒绝高影响的发现，而为那些确定但微不足道的发现付费，这与他们的初衷背道而驰。

范围文档必须涵盖的内容

AI 赏金计划的范围文档比应用安全领域的同类文档承担了更多工作。它必须做出一些在传统程序中根本不会出现的决策：

• 哪些工具属于“让智能体执行破坏性操作”的范畴。 如果智能体可以访问 send_email 工具，你必须说明研究人员是否可以尝试强迫它发送邮件到攻击者控制的地址，以及发送到哪些目的地。如果它有 delete_document 工具，你必须列举测试租户并禁止触碰真实客户数据——斯坦福 HAI 的安全港工作、FAS 提案以及 2024 年来自 350 位 AI 研究人员的公开信都一致认为：如果没有明确指明测试环境的安全港语言，研究人员要么会避开危险测试（导致漏洞在被攻击者发现前一直处于隐蔽状态），要么会照常测试并给所有人带来法律责任。
• 哪些模型版本和工具配置算数。 前沿模型不断更新。针对 model-version-2026-04-15 的发现可能无法在 model-version-2026-05-10 上重现。范围文档必须承诺一个版本控制方案以及针对已废弃版本的发现的 SLA。
• 对于间接提示词注入，“在范围内”意味着什么。 研究人员上传文档以向智能体的上下文中注入指令是典型的攻击面。研究人员是否被允许向测试租户上传自己的恶意文档？如果智能体会读取电子邮件，他们是否被允许向智能体的收件箱发送邮件？他们是否被允许注册一个会被智能体的网络工具抓取的网站？范围文档必须枚举这些渠道。
• 计划不予支付的内容。 “我们不为此付费”清单是文档中杠杆率最高的部分。运作良好的程序从第一天起就会发布这份清单。常见条目包括：未超出基础模型现有公开故障模式的基础模型越狱、系统提示词不包含敏感内容的泄露、针对没有现实副作用的假设场景的输出策略绕过，以及对已披露的公开攻击模式的重新发现。

任何新的 AI 赏金计划在第一个月都会产生噪音。世界上每个研究人员都保存着一份“我让它忘记了系统提示词”的对话记录，他们都会在你上线当天提交。能熬过第一个月的计划都已经在第零天发布了不予支付清单，限制了提交速率，并使严重性准则足够具体，以便分拣人员（triage）能在几秒钟内而不是几分钟内关闭低价值报告。

跨职能协作面

要启动该计划，三个团队必须真正行动起来，其中任何一个团队都可以无限期地拖延进度。

法务 必须批准针对对抗性 AI 测试的安全港语言。大多数现有的安全港语言是为传统安全研究起草的，并不涵盖例如研究人员反复尝试通过提示词注入提取另一个（测试）租户数据的情况。历史上，《计算机欺诈与滥用法案》（CFAA）一直是法律杠杆；HackerOne 在 2026 年 1 月专门针对“善意 AI 研究”扩展的安全港是大多数计划最终会采用的模板。如果没有这一点，该计划要么在最有价值的类别上没有定义范围，要么就只能默许研究人员在安全港框架之外工作，并信任公司不会起诉。

公关传播 必须编写一份不假定模型是确定性的披露政策。传统的漏洞披露会说“我们在 Y 版本中修补了 X，这是 CVE 编号”。而 AI 披露必须承认，修复手段是针对一类输入的缓解措施，成功率现在是 Z% 而不是零，潜在的类别可能会在未来的模型版本中再次出现，以及公司是否会提交 CVE。Anthropic、Google 和 Microsoft 都在 2025 年支付了 AI 智能体赏金，并选择不对其中几个漏洞提交 CVE——这是一个合理的选择，但政策需要书面化，而不是根据每个发现临时发挥。

AI 团队 必须真正修复计划报告的问题，而不是将其标记为“预期的概率性行为”并关闭工单。这是最常见的失败模式，也是对计划杀伤力最大的。如果你的 AI 团队的态度是“模型是非确定性的，每种提示词注入在某种意义上都是预料之中的，我们将在下季度的训练中解决它”，研究人员在他们的前三个发现被贴上“不予修复”标签后就会停止提交。计划必须让 AI 团队绑定与应用安全团队相同的 SLA——不是指重新训练的时间，而是缓解的时间（输入过滤器、输出过滤器、工具使用护栏、范围削减）。

支付曲线

赏金的经济设计决定了你得到的是你想要的发现，还是没人关心的发现。以下是一些已经形成的原则：

• 为新的攻击类别付费，而不是重复发现。 发现全新注入向量（如新型编码、新型多轮操纵、新型间接渠道）的研究人员，其收入应该是应用已知模式的研究人员的 5-10 倍。重复发现仍应付费（你不希望这些发现不被报告），但倍率要足够低，以便让有才华的猎人去追踪新的攻击类别。
• 按证明的成功率成比例付费。 针对你的特定部署有 80% 成功率的发现，与只有 2% 成功率的发现有着质的区别。你的支出应该反映这一点。
• 为链式发现额外付费。 泄露系统提示词的提示词注入是一个发现。泄露系统提示词、利用泄露的工具描述构建破坏性调用并证明调用成功的提示词注入是三个发现——但对你而言，价值在于这条链路，而不是各个部分。只为末端发现付费的计划会引导研究人员在发现第一个漏洞时就止步。

促使计划落地的认知

迫使大多数安全团队资助该计划的认知在于：你交付的 AI 功能拥有一个愿意免费为其工作的安全测试社区。无论你是否制定了计划，他们每周都会进行数千次尝试。你唯一的选择是：这些尝试是带着复现步骤、成功率和联系信息进入你的处理队列，还是作为一张截图出现在 Twitter 上，让你在披露前毫无修复机会。

一个在范围不明、评分标准模糊的状态下启动的计划比没有计划更糟糕——它让研究人员社区觉得向你提交报告是在浪费时间，并迫使他们将公开披露作为让其发现得到重视的唯一机制。相反，如果一个计划配备了基于 CIA 框架的严重性评分标准、概率性复现条款、明确的工具适用范围枚举、安全港协议下的指定测试租户、“不予付费”清单，以及一个受缓解 SLA 约束的 AI 团队，那么它就近乎于一个针对安全团队原本不知如何进行渗透测试的系统类别，持续产出生产环境相关发现的生成引擎。

难点不在于赏金金额，也不在于在 HackerOne、Bugcrowd 以及 AI 垂直领域玩家之间做选择。难点在于编写一份范围文档，以反映一个指定行为是“保持有用”的系统，并让三个通常不合作的团队就“什么算作故障”达成一致。提前做好这些工作的计划会产出安全发现；而等到收到第一次提交才开始摸索的计划，产出的则是 Twitter 帖子。