一次工具调用的日志常常写成：助手访问了订单接口。这句话省略了所有关键主语。是哪个登录用户？哪个服务账号？哪一个 OAuth 应用？工具自己缓存的令牌？还是上一轮任务留给运行时的环境变量？
Agent 看起来像一个员工，实际上更像一条会临时借用多把钥匙的自动化流水线。
01身份被折叠之后，审计也会一起折叠
传统应用大致能回答：这个 HTTP 请求代表谁。Agent 把规划、检索、工具、记忆串起来后，代表关系会断。用户只说了“帮我看看订单”，真正打到生产接口的可能是一个拥有跨部门读权限的平台账号。
出了事，安全团队会发现：
- 应用日志记的是 Agent
- 网关日志记的是服务账号
- 模型日志记的是会话 ID
- 工具日志记的是 MCP 名称
四份记录对不上同一个人，就无法判断这是用户授意、Agent 自作主张，还是外部内容改写了目标。
02至少要拆开的四层
发起者：点了按钮或发了消息的人。
授权范围：这一次任务被允许碰哪些系统和数据。
执行身份：工具实际使用的凭证。
工具自己的身份：MCP 或插件是否还持有另一套密钥。
任何一层被共用，最小权限就只写在纸上。很多团队用一个“Agent 专用账号”打通所有工具，图的是好连。结果是每个任务都继承最大权限。
03评估时不要只问“有没有登录”
要问：这次调用能不能回溯到具体的人、具体的任务、具体的授权。回不了，就还没有身份，只有一个会行动的匿名进程。
OWASP 围绕 Agent 的讨论，把身份、权限和工具控制放在显眼位置，原因也在这里。模型可以匿名生成文字。Agent 一旦行动，必须能被指认。