AI Agent Readiness Brief：工具调用、RAG 信任边界和角色混淆 关注一个对 AI Agent 上线很现实的问题：模型不一定稳定地区分哪些文本是可信指令，哪些是用户意图，哪些只是来自文档、网页、工单或工具输出的不可信数据。
这不是泛泛的 AI 新闻摘要。这个栏目会把近期研究和安全讨论，转成 RAG 系统、客服 Agent、编程 Agent 和工具调用型 LLM 工作流可以执行的上线检查。
1. 提示注入越来越像“角色混淆”问题
近期论文 Prompt Injection as Role Confusion 提出一个有用视角：模型可能根据文本写法判断权威性，而不只是根据文本来自哪里判断。相关报道也把这类攻击描述为伪造推理，让不安全指令看起来像可信的内部推理。
对 Agent 构建者来说，结论很直接：system、user、tool、document 这些标签本身不够。如果检索文档或工具结果写得像指令，模型可能会把它当成比应用预期更有权威的内容。
应该检查：把恶意指令放进检索内容、客服工单、邮件和工具输出里。Agent 应该把这些内容当证据或数据，而不是当作调用工具、泄露密钥、修改政策或跳过审批的授权。
2. 单层防御很脆
论文 Which Defense Closes Which Threat? 的价值在于，它不是只给一个总体安全分，而是追问哪类防御能关闭哪类 LLM 风险。一个实用结论是：拒答、预算控制、凭证清理、速率限制和工具注册认证并不能互相替代。
这对 AI Agent 很重要，因为危险失败往往不是一句坏回答，而是过度代理：模型调用工具、无限重试、放大一个证据不足的结论，或在权限边界不稳定时直接行动。
应该检查：每个高风险工具调用至少要对应三层控制：prompt 之外的授权、参数校验，以及对高风险动作的人工审批或硬拒绝。如果唯一控制是“prompt 里写了不要做”，这个工作流还不适合生产。
3. RAG 信任边界需要固定测试集
OWASP 把 Prompt Injection 列为 LLM 应用的重要风险。对 RAG 系统来说，间接注入尤其麻烦：用户可能问的是正常问题，但被检索的文章、PDF 或工单里藏着有害指令。
正确做法不只是改 prompt。团队需要可重复的测试 fixture：被投毒的政策文档、互相冲突的来源、过期文档、恶意邮件，以及试图改写 Agent 行为的工具输出。
应该检查：每个生产 RAG Agent 都应该有一个小型回归集，覆盖直接注入、间接注入、来源冲突、无依据回答、未授权工具请求和数据外泄语言。
Builder checklist
- 测试检索文档是否能覆盖 system 或 developer 指令。
- 确认工具输出会被当作数据，而不是新的指令来源。
- 对读取、写入、发送、删除、购买、退款或修改账号的工具，使用服务端授权。
- 对影响客户、资金、账号状态或外部沟通的动作，加入人工审批。
- 把失败的提示注入案例保留为回归测试，不要只留截图。
- 监控工具调用尝试、被拒绝调用、重试、延迟和每个完成任务的成本。
可复制的审查说明
在给 AI Agent 更多工具权限前，先测试角色混淆和间接提示注入。把恶意指令放进检索文档和工具输出里。Agent 不应该把这些指令当作授权，不应该泄露隐藏上下文，并且应对高风险工具调用执行服务端检查或人工审批。相关 IBBS 资源
- Free Prompt Injection Test Set for AI Agents
- Free AI Agent Production Readiness Checklist Template
- 面向 RAG 知识库的提示注入测试用例
- AI Agent 工具调用审批策略模板
- AI Agent 就绪度自测
下一步
如果你的 AI Agent 会读取外部内容或调用工具，先运行 AI Agent 就绪度自测，然后把失败用例加入回归测试，再扩大工具权限。