提示词注入漏洞赏金:当“损坏”没有明确定义时,如何划定程序范围
· 阅读需 14 分钟
你的安全团队运行着一个行之有效的漏洞赏金计划。CSRF 得到了奖金,XSS 得到了奖金,IDOR 也得到了奖金。交战规则明确,严重程度标准符合行业规范,分拣队列有序移动,该计划产出了源源不断的已修复漏洞。接着,你的 AI 团队在上个季度发布了一个功能 —— 一个聊天界面、一个调用工具的智能体(agent),或是一个从客户数据中提取信息的 RAG 流水线 —— 摆在安全团队桌面上的问题变成了:“这个东西的赏金范围是什么?”没人能回答。
没人能回答的原因是,标准的漏洞赏金准则是围绕行为确定的系统构建的。登录端点要么身份验证正确,要么不正确。访问控制检查要么生效,要么失效。你刚发布的 AI 功能没有等效的基准事实(ground truth):其规定的行为是“对用户输入做出有帮助的响应”,而一个让它做出无用响应的研究员并不一定发现了漏洞 —— 他们可能只是发现了模型一直以来都在做的事情,只是没人知道,你不确定是否能修复,而且在第二次尝试时可能无法复现。
