权限问题从账号变成委托

企业接入 Agent 时，最顺手的办法是让它使用某个人的 token，或者挂在一个通用服务账号下。这个办法适合演示，不适合生产。

Agent 和普通脚本的差别在于，它会根据上下文决定下一步。它可能先读文档，再查数据库，再调用工单系统，最后写回结果。每一步都在代表某个业务意图行动。

因此，真正要管理的不是一个静态账号，而是一段委托关系：谁让 Agent 做事，它能在哪些资源上行动，这份授权什么时候结束。

委托策略要比权限提示更细

权限提示解决的是单次确认，委托策略解决的是组织规则。企业需要知道，一个销售 Agent 能不能读客户记录，能不能发邮件，能不能改报价，能不能把资料交给另一个 Agent。

这些问题不能靠用户临场判断。它们应该被写成 scope、审批规则、过期时间、撤销路径和审计记录。风险越高的动作，授权越应该短、窄、可追踪。

这也是 OWASP 和 Microsoft 这些框架反复强调身份与治理的原因。Agent 被允许做事之前，组织要先定义它以什么身份做事。

工程实现会落到三层

第一层是身份。Agent 需要一个能被目录系统识别的主体，而不是隐藏在某个人背后。

第二层是授权。每次任务都要知道 Agent 代表谁、访问哪个资源、调用哪个工具、scope 多大。

第三层是审计。任务结束后，安全团队要能追到每一次关键调用，而不是只看到一个模糊的服务账号。

成熟度的分界

如果一个 Agent 产品只能说「用户授权后即可使用」，它还停在工具阶段。成熟的企业 Agent 必须能解释授权模型，并把撤销、审计和生命周期管理交给组织。

这件事不够性感，却会决定 Agent 能不能进生产系统。委托策略越清楚，企业越敢把真实工作交出去。