## Prompt injection stopped being a content problem — and most agent stacks haven't caught up 提示注入早已不再是一个“内容层面”的问题——但大多数 Agent 技术栈仍未跟上这一变化。

# 工具调用下的权限边界：比"内容安全"更深的问题 当下的防御讨论仍然绕着内容打转：更强的 system prompt、更好的过滤器，在模型看到之前先把恶意字符串拦截下来。但研究方向早已指向别处——尤其当 agent 手里握着真实工具时，这个差距变得相当明显。关键其实在于**信息流**。问题不该是"这个网页是不是恶意的？"，而应该是"一个不可信的来源，有没有影响到一个特权参数？"一个页面拿来摘要完全安全，但如果页面里的文字最终决定了邮件的收件人，或者给某个数据库工具拼出了参数，那它就是不安全的。 有一条序列是所有白名单都拦不住的：**允许的读工具 → 不可信输出 → 允许的写工具**。服务器白名单和工具白名单回答的是身份问题——哪台服务器、哪个工具名。它们并不告诉你参数是从哪来的，于是第二次调用可以完全符合你配置的每一条规则，却仍然做出错误的事。这就是"混淆代理"（confused deputy），而且它反复发生，因为授权绑定的是工具运行器（tool runner），而不是用户真正请求了什么。 尴尬之处在于，怎么把这个上下文带过那次"跳跃"。信任标签如果在读取之后就消失，那它毫无用处；而大多数按次调用的检查机制，在起点上根本不知道之前发生过什么。所以它必须存在于你的编排器（orchestrator）里，或者存在于调用链路上本来就有的某处——网关、安全层、或者另一个能看到这次调用的控制层。不管哪种情况，主流框架多半都不会替你携带它。 有一个问题，你必须拿来对着自己的技术栈问一遍： > 对于 agent 能够调用的每一个**写**工具：这个工具是验证了"用户确实要求了这次操作"，还是只验证了"agent 被允许调用它"？ 凡是落在后一类的，全都是等着爆的雷。 # 人们正在尝试的做法 - **按来源打信任标签**，让 system prompt、检索上下文和一次任意的网页抓取不会被当成同一种东西对待 - **只读子 agent**：凡是涉及不可信内容的场景，交给一个完全不持有副作用工具的子 agent 去处理 - **签名意图摘要（signed intent digest）**：从原始请求构建，在工具侧校验，从而让工具能判断"这次操作是否与用户所请求的内容相符" - **子 agent 获取全新的、有范围的授权**，而不是自动继承父 agent 拥有的全部权限 - 学术研究那边也在推进同一思路的形式化版本，比如 **agent-sentry**、**tokentaint**