Prompt注入防护：AIGC应用上线前必测项

许多人对 Prompt Injection（提示词注入）的认知仅停留在“用户让模型忽略系统规则”的层面，但这只是冰山一角。

在云上应用的真实业务场景中，攻击入口远比你想象的更广泛：用户直接输入的文本、外部网页抓取的内容、知识库里嵌入的文档、插件返回的字段、历史会话的上下文，甚至工具调用时的参数——任何一个环节都可能成为突破口。如果仅仅盯着系统 Prompt 打补丁，根本无法构建真正的防御。

因此，在上线前的测试中，核心任务就是验证整条链路是否存在真正的安全边界。

一、输入侧安全测试

输入侧是攻防对抗的第一道防线，至少要覆盖三类代表性的测试样本：

一个容易被忽略的要点：务必加入正常的业务样本。如果只追求拦截率，很容易将正常用户误伤，导致体验全面下降。

二、RAG 安全测试

RAG（检索增强生成）的安全测试需要覆盖三个关键环节，缺一不可。

入库前，要确认外部文档中是否隐藏了恶意指令、恶意链接或敏感数据。召回后，检索回来的片段是否夹带了“覆盖系统规则”这类危险内容。拼接时，上下文模板能否清晰地将资料内容与指令区分开。

衡量效果的指标体系包括：恶意文档检出率、召回片段的清洗率、对正常知识召回的影响程度，以及最终回答准确性的变化。这些量化数据比主观感受可靠得多。

三、Agent 工具安全测试

Prompt Injection 对 Agent（智能体）的威胁更加直接。因为它不仅可能让模型“说错话”，更可能让模型“做错事”。

上线前，必须重点检查以下方面：

• 工具白名单是否按用户、角色、场景做了精细化权限限制
• 参数是否进行了合法性校验
• 高危操作是否具备二次确认机制
• 越权查询、导出、删除、发送等动作能否被有效阻断
• 工具调用的日志是否完整且可追溯

简而言之，如果工具层没有权限控制，Prompt 写得再严格也形同虚设。

四、输出审核与安全代答测试

即使输入侧防护做得再完善，也不能替代输出审核。模型仍然可能生成违规、隐私泄露、误导或侵权等内容。

测试时需重点关注两个结果：高风险输出能否被准确识别并阻断；被拒绝回答后，系统能否给出合理的“安全代答”，而不是直接中断体验，让用户感到困惑。

举例来说，当用户询问安全研究类问题时，正确的做法是拒绝提供攻击步骤，但可以给出防护原则、合规测试的边界以及风险提示。这样既守住了安全底线，也没有完全堵死用户的求知欲。

五、云上性能与稳定性测试

安全能力一旦接入主业务链路，必然会对性能产生影响，这一点必须提前摸清。

此外，云上 AIGC 应用还需考虑跨区域部署、私有网络访问、数据留存周期以及合规要求。这些问题单纯靠规则无法解决。

六、POC 怎么做更有效？

进行 POC（概念验证）时，建议按照真实的业务链路构建测试数据集，而不是直接套用网上公开的 jailbreak 模板。后者与实战场景差距太大。

评估对象可以包括自研规则、模型本身的安全能力，以及一些成熟的第三方安全方案。对比时，关键是统一样本、统一指标、统一日志口径。重点考察召回与误拦之间的平衡、部署方式的灵活性、审计能力是否到位，以及运营闭环是否完整。

常见问题 FAQ

Q：Prompt Injection 测试应该由安全团队还是研发团队负责？
A：最好由双方共同承担。研发团队理解业务链路和工具权限，安全团队负责攻击样本设计、策略边界制定和风险验收。两方协作才能实现全面覆盖。

Q：安全围栏应该部署在哪些位置？
A：通常需要在模型调用前后均部署安全防护，并与 RAG、Agent、账号风控、日志审计等系统联动。单点部署就像只锁了大门却忘了关窗户，很难覆盖完整风险。

Q：上线后还需要持续测试吗？
A：非常有必要。攻击样本在不断进化，不能一劳永逸。应结合线上日志、误杀漏放情况、用户反馈以及人工复核，持续进行回归测试。