围绕知识库和工具返回建立信任分层，在执行层控制模型可触发的操作。
本文于 2026-09-12 补充整理，按 2026-05 专题归档。示例为方案设计，参数用于说明方法，不代表已上线项目或实测成果。
外部文本可能看起来像系统指令
知识库助手会读取工单描述、文档正文和工具结果。这些内容可能包含“忽略前面的规则”“把所有记录导出”等文字。即使它们出现在真实文档里，也仍然只是待分析的数据，不能获得系统指令的地位。
这里讨论的是防护设计和测试边界。核心目标是让外部内容无法直接扩大工具权限、改变身份或触发未经确认的写入。
给输入标明来源与用途
可以把上下文分为：应用维护的行为规则、当前用户明确提出的任务、检索证据、工具观察结果。模型提示中说明这些来源的区别有帮助，但提示词本身不是强制访问控制。
证据对象应保留来源和版本，引用时能够追溯。来自文档的操作建议，应作为待核实的建议，不应自动转换为工具调用。例如规范中的“删除旧环境”不能绕过当前用户实际授权范围。
执行器承担最终约束
模型提出调用
→ 工具允许列表
→ 参数 schema 与业务校验
→ 当前身份和资源权限
→ 风险判断 / 具体提案审批
→ 受限执行环境
→ 输出校验与审计
其中每一步都要由代码实现明确规则。检测模型可以辅助判断可疑内容，但不应成为唯一拦截器。一个辅助模型误判“安全”，不能让越权调用通过。
对于可以访问 URL 的工具，限制目标范围和协议，处理跳转后地址，避免任意访问内部服务。对于文件工具，限定工作目录与路径解析规则。对于命令工具，更适合暴露任务特定能力，而不是默认提供无限制命令执行。
这些约束应根据工具的实际能力设置；只做知识问答时，无需为它开放本来用不到的写入或执行权限。
工具返回也需要控制
一个返回整个数据库查询结果的工具，会把权限风险和上下文成本一起放大。服务端应先做权限过滤、字段裁剪和大小限制，再把结果交给模型。
结果中出现疑似指令，不代表必须丢弃整份文档；可以保留其作为证据内容，但不赋予指令意义。对高风险操作，要求来源交叉核实或人工确认具体提案。
MCP 安全最佳实践提供协议集成层面的参考。这里的信任分层和业务执行闸门是应用需要补充实现的设计。
测试要观察系统行为
准备三份合成文档：普通操作说明；在末尾混入要求改变任务的文字；在表格中嵌入要求调用不相关工具的内容。不要只观察最终回答是否出现异常句子，还要记录中间工具请求是否被拦截。
验收包括：没有扩大检索范围；没有发送不相关外部请求；没有改变用户身份；没有新增写操作；模型若被内容影响，执行器仍然阻止越界。
只测试“忽略所有规则”这一种直白句式，覆盖面很有限。需要考虑正文、引用、工具错误消息、旧记忆和多轮对话中的间接影响。
失败之后怎么恢复
发现可疑行为时，保存经过脱敏的来源证据和拒绝原因，停止相关动作，并向用户解释不能完成哪一步。不要把带有攻击性内容的完整记录直接升级为下一轮高优先级提示。
如果一次测试没有触发非法操作，只能说明该测试下边界有效，不能宣称提示词注入已经被彻底解决。持续积累失败样本，并在工具和提示词升级后回归，才是可维护的防护方式。
