把 Azure 凭据交给 AI Agent 之后：审计日志写着我的名字，权限却放大到 107 项
来源The New Stack查看原文
速览
- Agent 不是「还没有身份」，它继承的是人类身份，令牌 scope 明确写着 user_impersonation。
- 授权藏在组里，标准角色分配查询只看到一行 Reader，实际令牌带 37 个组条目。
- 同一令牌一小时内在两个生产库上分别持有 2 项和 107 项权限，差两个数量级。
- 能删除安全数据库数据的环境，是唯一没有审计日志的环境。
- Agent 的操作日志写着人类的名字、机器和工具，无法区分是谁发起的。
- 84 分钟令牌有效期不是安全边界，CLI 会用刷新令牌自动续期。
- 凭据能删数据，却无权查询自己的权限是永久还是 JIT 临时。
- 给每个 Agent 单独的服务账号只改日志里的名字，不解决归因问题。
- MCP 授权规范已禁止服务器转发客户端令牌，命令行工具尚未跟进。
- 作者提出五项改造：区分 actor 与 subject、权限取交集、按操作授权、审计跟随权限、独立吊销。
The New Stack 作者 Naseeb Ahmed 做了一次实测：把自己的人类 Azure 凭据交给一个编码 Agent，然后逐项测量它到底拿到了什么。结论是，Agent 并没有「还没有身份」，它用的是作者的身份——访问令牌的 scope 字段直接写着 user_impersonation，amr 声明里带着 mfa，意味着 Agent 的每一次操作都附带「有人通过了二次验证」的背书，哪怕那次验证是几小时前为别的任务做的。授权几乎全部来自标准角色分配查询看不到的组（group）成员关系：租户级角色分配只返回一行 Reader，但令牌里带 37 个组条目，目录直接成员查询显示 34 个，数据库采用更大的那个数字。权限范围在相隔一小时访问的两个生产库之间差了两个数量级：一个库只有 CONNECT、SELECT 两项权限，另一个 lakehouse 分析端点上有 430 张表、107 项权限，横跨读、写、schema 定义和数据库管理。审计覆盖与凭据能力成反比——唯一能删除安全数据库数据的环境，恰恰是唯一没有审计的。作者还检查了自家按资源精细授权的无人值守 Agent，发现它在数据库这一层同样退化成标准 SQL 登录名加密码，机器身份在数据路径开始的地方就断了。文章最后给出五项改造要求，并指出 MCP 授权规范已明确禁止服务器转发客户端令牌，命令行工具应当跟进同一标准。
关键事实
- 作者把个人 Azure 凭据交给编码 Agent 后，解码访问令牌发现 scope 为 user_impersonation，amr 声明包含 pwd 和 mfa，groups 声明有 37 个条目，令牌有效期 exp – iat 为 84 分钟。
- 数据库会话记录只返回三个身份字段：login_name 为 naseeb.ahmed@、program_name 为 sqlcmd、host_name 为作者的工作站，没有任何字段能让 Agent 声明自己是 Agent。
- 租户内所有订阅的角色分配查询只返回一行：非生产订阅上的 Reader；但组查询显示 34 个活跃组成员关系、7 个可见订阅（含生产）。
- 令牌的 groups 声明显示 37 个条目，目录直接成员查询显示 34 个，差异来自嵌套组，数据库采用更大的数字。
- 查询哪些组是 JIT 临时权限时返回 Forbidden: PermissionScopeNotGranted，缺少 PrivilegedEligibilitySchedule.Read.AzureADGroup 与 PrivilegedAccess.Read.AzureADGroup 权限。
- 同一令牌访问两个生产库：一个可见 1382 个数据库（692 个业务层、687 个安全层），业务层只有 CONNECT、SELECT，安全层直接登录失败；另一个 lakehouse 分析端点上有 430 张表、107 项权限。
本站视角
这件事最直接的受影响者，是正在把 Agent 接进生产数据库的中文开发团队和平台工程团队。国内不少团队的做法与文中几乎一致：让 Agent 复用开发者本地的云 CLI 凭据或长期 AK/SK，图的是开箱即用。这篇文章的价值在于把「开箱即用」的代价量化了——不是理论风险，而是同一令牌在两个库上 2 项对 107 项权限的具体差距，以及唯一能删数据的环境恰好没有审计。我们认为这是目前关于 Agent 身份问题最扎实的一手测量之一，值得任何准备让 Agent 碰生产数据的团队对照自查。 我们的判断是：这不是配置错误，而是 IAM 模型缺字段。数据库会话记录只有 login_name、program_name、host_name 三个字段，没有第四个字段让 Agent 声明自己，所以任何下游管控——限流、审批、差异化保留策略——都无法以「这是 Agent 发起的」为条件。这意味着在现有云 IAM 体系下，靠应用侧打补丁解决不了归因问题，只能靠委托令牌这类协议层改动。对做 Agent 框架和 MCP 工具链的团队来说，MCP 授权规范已经禁止服务器转发客户端令牌，这是一个明确信号：谁先把委托语义做进工具链，谁就拿到了企业采购的入场券。 需要指出的可疑之处有三点。第一，样本量有限，作者自己承认测量来自单一环境、历时两天，两个库之间 2 项对 107 项的差距也可能来自平台默认值而非有意设计，把它当作普遍规律需要谨慎。第二，作者没有直接批量导出用户查询日志，而是通过会话记录和已配置的动作组来评估审计覆盖，这属于间接推断，实际审计是否真的缺失存在误差空间。第三，作者所在环境本身存在环境复制遗留的审计规范对象，说明该环境的治理成熟度参差，结论外推到治理更严格的企业时可能偏悲观。但反过来说，正因为这是一个「建得还算规范」的环境——作者特意检查了自家按资源精细授权的无人值守 Agent——问题依然出现，才更能说明这是结构性问题而非个案疏忽。对国内团队而言，最现实的行动项不是等云厂商改协议，而是先做两件低成本的事：把非生产环境的审计打开，以及停止让 Agent 复用个人凭据。
背景与影响
这篇文章讨论的是 AI Agent 落地过程中一个被普遍忽略的环节：身份与授权。当前主流做法是让 Agent 复用开发者已经登录的 CLI 凭据（例如 sqlcmd 的 ActiveDirectoryAzCli 模式），好处是不用存密码、不用在验证 Agent 是否有用之前先给它开身份，代价是 Agent 与人类在系统里完全不可区分。作者用实测把这种做法的后果量化了出来：归因坍塌、权限继承、吊销困难——这三条本是已知的坏实践，但实测显示前两条比预想的更复杂。权限继承不是简单地「Agent 拿到人的全部权限」，而是取决于访问路径：同一个令牌走不同端点，有效权限从 2 项跳到 107 项，因为安全规则配置在端点上，不会跟着数据走到另一个引擎。审计覆盖则按环境而非按权限级别配置，生产环境有审计、非生产环境为省存储和计算成本不审计，这套逻辑在人类用户前提下成立，一旦换成会无人值守跑几千条语句的 Agent 就失效了。作者还指出，即使企业认真做了机器身份——比如用托管身份加按资源显式授权——只要数据库连接仍走标准 SQL 登录，归因问题依旧存在，机器身份在数据路径开始处就断了。这意味着，对正在把 Agent 接入生产数据库的团队来说，问题不在模型能力，而在 IAM 体系本身没有为「非人类行为者」设计字段。作者给出的方向是 RFC 8693 的委托令牌（同时携带 subject 与 acting party）、权限取交集、按操作而非按主体授权、审计跟随权限级别、以及独立于人类账号的吊销机制。需要观察的是，这些改动大多要求云厂商和数据库层配合，单靠应用侧难以完成。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。
