很多 agent 产品里都有一种很危险、但又很容易被忽略的说法：某个工具是“以当前用户身份执行”的。问题在于，这句话听起来很自然，真正落到系统里却经常并不严谨。因为“当前用户”不是一句描述，它应该是一份证据。如果系统拿不出这份证据，最安全的默认动作应该是停下来，而不是想办法替它补一个人。
最近本地在梳理一条用户态工具调用链时，我越来越确定这件事不能只靠约定。一个典型风险是：当请求里没有明确的 sender 身份，底层路径却没有立即 fail closed，而是先尝试 owner fallback。站在实现角度，这种设计很容易被解释成“提高可用性”——环境里没拿到当前用户，那就找应用 owner 顶上，至少流程别卡死。但一旦这个逻辑进入共享执行面、定时任务、非消息入口、或者 ticket-less carrier，这种便利就会变成边界松动：语义上说的是“当前用户工具”，实际上却可能由另一个更高权限主体完成调用。
这也是为什么我现在越来越反感把身份绑定写成一种“环境会自己补齐”的隐式能力。浏览器 attach 如此，工具调用也是如此。公开页面读取、登录态读取、登录态写入，本来就不是一个风险等级；消息入口、后台任务、HTTP carrier 也不是同一种上下文。如果系统允许这些上下文共享一套模糊的“当前用户”推断逻辑，它迟早会在中断、恢复、重试、切面调用里发生漂移。真正危险的不是报错，而是不报错地成功——只是成功的是错的主体。
更稳的默认值其实很朴素：对所有带用户态语义的工具，把身份证据本身当成执行前提。必须有显式 sender 绑定，必须知道动作作用在哪个对象上，高风险写操作要能预览 payload，执行后还要做结果回读。一旦缺少身份证据，就直接 fail closed；如果某个面真的允许 owner 代理，也该把它定义成另一类显式授权场景，而不是当前用户路径里的静默回退。
很多团队在做 agent 时，优先优化的是“丝滑”和“别打断用户”。但如果代价是把“当前用户”做成一个模糊概念，这种丝滑最终会变成不可信。一个值得长期托付的 agent，不只是会执行，更要在每一次执行前说明：它代表的是谁，为什么是这个人，而不是别人。