误解一：加防护提示就够
过滤「忽略之前指令」这类关键词很容易被编码、分段、多语言绕过。提示词层面的防护只能提高攻击成本，不能当作防线，真正的约束要落在权限、工具范围与出站控制上，那才是攻击者绕不开的部分。
误解二：只有聊天框会被攻击
间接注入来自文档、网页、邮件、代码注释、图片文字与工具返回值，聊天框只是其中一个入口。只测对话界面等于只检查了前门，而真正的入口往往在文件上传与自动同步这类没人盯的地方，入口清单要按季度更新。
误解三：换更强模型就解决
模型越强，越能理解并执行复杂指令，反而可能更听话。注入是架构问题，取决于模型能触达什么数据与工具，而不只是它有多聪明。把预算全押在换模型上，通常只能改变攻击成本，改不了影响面，也换不来信任。
误解四：内部系统不用担心
内部知识库、工单与邮件同样混入外部内容，内部人员也可能误粘贴。内部系统的损失往往更大，因为权限更宽、数据更敏感，一次越权检索能同时看到多个部门的内容，内部人误操作占比并不低，这一点常被低估。
边界：残余风险要写下来
任何方案都有被绕过的可能，区别在于被绕过之后能造成多大影响、能否及时发现。把残余风险、监控手段与人工门写进设计文档，比宣称「已防护」更负责，也方便后来接手的人判断边界，评审时才不会被问住。
适用与不适用
适合谁
- 对注入风险认识还停留在提示词层面的团队
- 准备上线 Agent 与知识库的产品负责人，要能讲清边界
- 需要向管理层解释风险边界的项目负责人
不适合谁
- 完全没有外部输入、也不接工具的封闭系统
- 希望拿到「绝对安全」承诺的采购方，不接受残余风险
典型场景
某企业内部助手被认定「只在内部用，不用管注入」。一次跨部门演练中，有人把带隐藏指令的供应商报价单上传，助手把其他部门的预算区间读了出来。事后团队才把外部来源文档单独标记，并给检索加了部门范围限制，演练记录随后进了年度报告。
可执行步骤
- 收集团队里流传的防护说法，逐条标注依据、反例与验证方式，区分事实与猜测。
- 用编码、多语言、分段三类变体测试现有过滤，记录每次绕过用的具体路径。
- 盘点全部外部内容入口，含文档、邮件、网页、第三方回调与工具返回值，留一份可查版本。
- 按数据敏感度与权限宽度重新排序内部系统风险，先处理跨部门检索的场景。
- 把残余风险、监控信号与人工确认点写进设计文档，由项目负责人签字确认。
常见坑
- 把关键词过滤当防线，攻击者换种语言或编码就绕过去，团队却以为已经加固，后续不再检查，后续也不再复测。
- 只测对话界面，文档上传与工具返回完全没测，风险被系统性低估，同类问题会重复，上线后才暴露。
- 以为内部系统权限小，实际检索能跨部门取数，一次泄露的面比外网更大，事后很难向各部门解释。
- 对外宣称已经彻底防护，出事时解释不清，技术问题会变成信任问题，损失比技术缺陷更难挽回，代价更高。
自检与验收清单
- 现有防护说法是否都有验证记录与反例，含反例
- 是否用编码、多语言与分段变体验证过过滤，各测一轮
- 外部内容入口清单是否覆盖文档、邮件与工具返回，不要漏项
- 内部系统的检索范围是否按部门与角色受限，含检索范围
- 残余风险、监控信号与人工门是否书面记录，有人签字
常见问题
有没有一劳永逸的方案？
没有。可做的是把攻击成本抬高、把影响面收窄、把发现时间缩短。随着模型与工具变化，防护要持续复测，任何宣称一次配置长期有效的说法都值得怀疑，重点看自己业务的入口。
内部员工会故意攻击吗？
多数不是故意，而是误操作：把外部文档直接粘进来、把带指令的邮件转发给助手。少数是好奇尝试。两种情况都需要入口限制与行为审计，而不是只做信任假设，审计记录也要留存。
出了事该先做什么？
先固定证据：会话记录、检索结果、工具调用与出站请求，再评估影响范围并阻断相关通道。顺序反了，往往会在排查过程中把关键日志覆盖掉，日志顺序决定能否完整还原，建议写进制度。