AI Agent 一旦接入业务系统，权限问题就不能只靠“不要乱做”这类提示词来约束。真正上线以后，团队需要回答更具体的问题：这次动作代表哪个用户执行，调用了哪个工具，授权来自哪里，参数是什么，结果有没有对外可见。
权限审计的目标不是事后找人背锅，而是让 Agent 的每一次关键动作都能复盘。它和 权限矩阵、审计日志字段、工具白名单 是一套基础设施。
先分清用户身份和代理身份
用户身份说明“谁发起了任务”，代理身份说明“系统用哪个执行主体去做事”。很多事故出在这两个身份被混在一起：用户只是让 Agent 查资料，系统却用一个高权限账号执行了写入动作。
更稳的做法，是每次工具调用都记录用户、Agent、任务、会话和执行账号。只要发生异常，团队能知道到底是用户授权、管理员预授权，还是系统默认权限导致的动作。
授权来源要写进记录
权限审计不能只记录“允许”或“拒绝”。它还要记录允许的依据：来自角色权限、临时审批、客户工单、变更单，还是固定白名单。没有授权来源，审计日志只能证明系统做过事，不能证明为什么可以做。
涉及外发、删除、价格、合同和权限变更时，最好接上 客户可见动作确认，让最终确认人和确认时间一起进入证据链。
工具参数也要能回看
很多团队只记录工具名，不记录关键参数。这样复盘时会很被动，因为“调用客户系统”并不能说明 Agent 查了哪个客户、改了哪个字段、传入了什么过滤条件。
当然，参数记录要做脱敏。手机号、邮箱、合同号、客户姓名等字段可以保留哈希或部分掩码，但动作类型、字段名、影响范围和结果状态必须留住。
最小权限要跟任务绑定
长期有效的大权限账号，是 Agent 上线后的高风险点。任务只需要读库存，就不要给写订单权限；任务只需要生成草稿，就不要给自动外发权限。任务结束后，临时授权也要失效。
这可以和 任务路由 结合：低风险读动作自动跑，高风险写动作进入审批，权限不足时直接转人工，而不是让 Agent 反复尝试。
总结
AI Agent 权限审计要查清三件事：谁发起、谁执行、凭什么执行。用户身份、代理身份、授权来源、工具参数和审批记录放在一起，Agent 才能从“能做事”走向“做过的事说得清”。
