许多人对 Prompt Injection（提示词注入）的认知仅停留在“用户让模型忽略系统规则”的层面，但这只是冰山一角。
在云上应用的真实业务场景中，攻击入口远比你想象的更广泛：用户直接输入的文本、外部网页抓取的内容、知识库里嵌入的文档、插件返回的字段、历史会话的上下文，甚至工具调用时的参数——任何一个环节都可能成为突破口。如果仅仅盯着系统 Prompt 打补丁，根本无法构建真正的防御。
因此，在上线前的测试中，核心任务就是验证整条链路是否存在真正的安全边界。
一、输入侧安全测试
输入侧是攻防对抗的第一道防线，至少要覆盖三类代表性的测试样本：
样本类型 | 测试目的 |
|---|---|
直接注入攻击 | 检验模型能否识别并拦截“忽略系统规则”、“泄露提示词”、“角色越狱”等直白攻击 |
敏感意图请求 | 针对违法、隐私、欺诈、危险操作等请求，验证系统是否具备分级处置能力 |
混淆变体攻击 | 编码、翻译、拆字、多语言、长文本夹带等花招能否绕过现有防护 |
一个容易被忽略的要点：务必加入正常的业务样本。如果只追求拦截率，很容易将正常用户误伤，导致体验全面下降。
二、RAG 安全测试
RAG（检索增强生成）的安全测试需要覆盖三个关键环节，缺一不可。
入库前，要确认外部文档中是否隐藏了恶意指令、恶意链接或敏感数据。召回后，检索回来的片段是否夹带了“覆盖系统规则”这类危险内容。拼接时，上下文模板能否清晰地将资料内容与指令区分开。
衡量效果的指标体系包括：恶意文档检出率、召回片段的清洗率、对正常知识召回的影响程度，以及最终回答准确性的变化。这些量化数据比主观感受可靠得多。
三、Agent 工具安全测试
Prompt Injection 对 Agent（智能体）的威胁更加直接。因为它不仅可能让模型“说错话”，更可能让模型“做错事”。
上线前，必须重点检查以下方面：
- 工具白名单是否按用户、角色、场景做了精细化权限限制
- 参数是否进行了合法性校验
- 高危操作是否具备二次确认机制
- 越权查询、导出、删除、发送等动作能否被有效阻断
- 工具调用的日志是否完整且可追溯
简而言之，如果工具层没有权限控制，Prompt 写得再严格也形同虚设。
四、输出审核与安全代答测试
即使输入侧防护做得再完善，也不能替代输出审核。模型仍然可能生成违规、隐私泄露、误导或侵权等内容。
测试时需重点关注两个结果：高风险输出能否被准确识别并阻断；被拒绝回答后，系统能否给出合理的“安全代答”，而不是直接中断体验，让用户感到困惑。
举例来说，当用户询问安全研究类问题时，正确的做法是拒绝提供攻击步骤，但可以给出防护原则、合规测试的边界以及风险提示。这样既守住了安全底线，也没有完全堵死用户的求知欲。
五、云上性能与稳定性测试
安全能力一旦接入主业务链路，必然会对性能产生影响，这一点必须提前摸清。
关键指标 | 说明 |
|---|---|
平均延迟 | 对普通请求的整体影响，不能为了安全而拖垮用户体验 |
P95/P99 延迟 | 高峰和长尾场景下的真实体验，这个比平均值更关键 |
并发能力 | 高流量场景下系统是否仍能稳定运行 |
降级策略 | 安全服务异常时业务如何处理，不能直接崩溃 |
日志链路 | 能否按 trace_id 将整个请求链路串联，方便排查 |
告警机制 | 高风险攻击能否被及时发现并触发告警 |
此外，云上 AIGC 应用还需考虑跨区域部署、私有网络访问、数据留存周期以及合规要求。这些问题单纯靠规则无法解决。
六、POC 怎么做更有效？
进行 POC（概念验证）时，建议按照真实的业务链路构建测试数据集，而不是直接套用网上公开的 jailbreak 模板。后者与实战场景差距太大。
评估对象可以包括自研规则、模型本身的安全能力，以及一些成熟的第三方安全方案。对比时，关键是统一样本、统一指标、统一日志口径。重点考察召回与误拦之间的平衡、部署方式的灵活性、审计能力是否到位，以及运营闭环是否完整。
常见问题 FAQ
Q：Prompt Injection 测试应该由安全团队还是研发团队负责？
A：最好由双方共同承担。研发团队理解业务链路和工具权限，安全团队负责攻击样本设计、策略边界制定和风险验收。两方协作才能实现全面覆盖。
Q：安全围栏应该部署在哪些位置？
A：通常需要在模型调用前后均部署安全防护，并与 RAG、Agent、账号风控、日志审计等系统联动。单点部署就像只锁了大门却忘了关窗户，很难覆盖完整风险。
Q：上线后还需要持续测试吗？
A：非常有必要。攻击样本在不断进化，不能一劳永逸。应结合线上日志、误杀漏放情况、用户反馈以及人工复核，持续进行回归测试。
