当人工智能代理冒用你的身份：继承的凭据混淆了人与机器

当人工智能代理使用人类用户的凭据访问数据库时，系统并不会获得一个隐藏在账户背后的“代理身份”；它看到的就是该用户本人。这是 Naseeb Ahmed Mian 在一个使用 Azure、Azure CLI 和 sqlcmd 的生产环境中进行测量后得出的核心结论。

在所检查的配置中，软件代理的技能通过 sqlcmd 命令连接数据库，并使用 Azure CLI 进行身份验证。该命令会在用户登录后提取缓存的访问令牌，然后将其提交给数据库。因此，无论查询是用户亲自编写的，还是由代理执行的，连接都显示为该用户的名义，并带有其设备名称和 sqlcmd 工具信息。

审计日志看到的是凭据，而不是意图

会话日志显示了用户登录名、工作站名称和客户端接口，但没有包含用于区分代理所执行操作的字段。因此，人工查询和自动查询在日志中完全相同，后续控制措施无法根据执行来源应用不同的请求速率限制、审批步骤或保留策略。

问题并不局限于安全调查。如果有人日后质疑几个月前执行的一条查询，日志将无法证明它究竟是用户编写的，还是由自动化工具运行的。日志能够准确地将操作归因于该凭据，但对于意图和实际执行者保持沉默。

访问令牌揭示了什么？

Azure CLI 提供的令牌包含 user_impersonation 范围，以及一项表明身份验证包含多重身份验证因素的声明。实际上，代理执行的每一项操作都带有用户已通过多重身份验证的证据，即使该验证发生在数小时前，且当时处于不同的任务场景中。

此外，令牌的 84 分钟有效期并不一定代表代理运行的结束。CLI 会使用刷新令牌自动续订该令牌，因此无人监控的运行可能会持续到刷新令牌过期或用户账户被禁用。

组成员资格扩大了访问范围

角色分配检查只显示一行：在一个非生产订阅中拥有 Reader 角色。但访问令牌包含 37 个组，而直接成员资格查询显示 34 个组，其中还存在嵌套组。与访问相关的组包括 SQL 数据库查看者、特权用户、资源贡献者和数据库管理员等角色。

危险在于，这些成员资格可能在数据层承载实际权限，而不一定会出现在控制平面角色检查中。因此，在采用传统方法审查时，代理的访问范围可能看起来很有限，但组成员资格却可能赋予它更大的能力。

实际情况会发生什么变化？

在相隔一小时的时间里，使用同一身份测试两个生产存储时，结果出现了极大差异。在其中一个存储中，该身份仅拥有 CONNECT 和 SELECT 两项权限，无法连接到安全层。而另一个生产分析端点则显示有 430 张表和 107 项权限，涵盖读取、写入、架构定义以及数据库管理。

这一比较说明，权限范围并不只由身份决定；访问路径、引擎以及与端点相关的控制措施同样是关键因素。某个端点可能根据其文档仅支持只读访问，但当通过另一个引擎调用数据时，其安全规则未必会随之转移。

certi.news 的编辑解读：问题并不是代理“没有身份”，而是人的身份被用作独立机器身份的快速替代品。这会在三个方面失效：归因、权限范围扩大和撤销。测量还显示，在一个凭据拥有从安全数据库中删除数据的能力的环境中，审计日志恰恰是唯一未启用的环境。关于组成员资格的一致性、已颁发令牌中临时权限的持续存在，以及机构能否记录执行意图而不仅仅是凭据所有者，仍有重要问题悬而未决。