一份外部知识页面要求 Agent 访问客户数据，而这些工具确实存在并且当前可用。你需要在保留正常知识检索能力的同时，阻止不可信内容获得指令权力。
先处理问题，再阅读解释。
你负责 Agent 的 Trust Boundary 与 Capability Boundary。
客服 Agent 会读取外部知识来回答退款问题。其中一篇检索文档要求它读取完整 CRM Profile，并通过现有 Tool Path 发送账户标识。第二个攻击更加隐蔽；同时，还有一篇正常安全文章本身就包含看起来很像攻击的关键词。
阻止恶意指令进入敏感 Tool Path，同时保留正常外部知识能力，并控制 False Positive、人工审核与延迟。
一段文字可以长得像 Instruction，但它依然可能只是 Untrusted Data。
模型不能成为唯一的安全边界：Trust、Capability 与敏感操作必须由模型外部的 Runtime 强制执行。
把结果整理成可以复用的判断。
工程复盘
模型不能成为唯一安全边界。Trust、Capability 与敏感操作必须由 Harness / Runtime 强制执行。
Agent 在同一个工作 Context 中同时看到 System Policy、Developer Workflow 与外部内容。如果没有 Provenance-aware Trust 和 Capability Enforcement，不可信数据就可能影响真实 CRM Tool。把所有外部内容都拒绝确实能消灭攻击，却也会摧毁正常任务并制造大量 False Positive。Defense in Depth 的目标，是允许数据被读取，同时限制它能够造成什么后果。
System Policy、Developer Intent、User Request 与 Retrieved Data 的权威级别并不相同。
模型请求调用 Tool，不等于它获得了导出客户数据的权限。
如果策略靠拒绝所有外部内容来保持安全，那只是让产品失去作用。
把这次体验连接到概念、参考与迁移。
LEARNING CONTEXT
一段文字长得像 Instruction，并不会因此获得系统 Authority；Capability Policy 必须由 Runtime Boundary 执行。
Mental Model
建议补充前置
进入这起事故前，没有必须完成的已发布前置内容。
迁移这个模型
同一条恶意指令不再来自检索文档，而是来自 Tool Result。哪些防线仍然有效？
把这个判断带到另一个问题或构建中。
Retrieval、Tool Reliability 与 Security 将在同一个发布决策里发生冲突。
进入 Integrated Build