审计日志上写着我的名字：当你把凭证交给代理时，它继承了什么
内容提要
实测显示，AI代理借用人类Azure凭证访问数据库时，同一令牌在不同生产库权限差异巨大（一个仅2项，另一个达107项），且可删除数据的库缺乏审计。代理无独立身份，日志仅记录人类账号，无法区分人机操作。即使配置规范的无人代理，数据库仍使用SQL密码登录，导致归因失效。作者提出五项改进，并指出MCP规范已禁止转发客户端令牌，命令行工具应跟进。
延伸解读
权限差异与审计盲区
同一Azure凭证在访问不同生产库时权限差异巨大：一个仅2项权限，另一个达107项。更严重的是，可删除数据的库竟未开启审计，导致操作无迹可寻。这种权限与审计的反向关系，使得高权限操作反而缺乏监督，增加了数据泄露或误删的风险。
代理身份缺失的后果
AI代理借用人类凭证时，数据库日志仅记录人类账号，无法区分人机操作。这导致归因失效：无法证明某操作是人还是代理所为。同时，代理继承人类所有权限，撤销代理需撤销人类账号，且代理无独立身份，难以实施针对性的安全策略。
组权限与令牌的隐蔽性
令牌中的组声明包含37个条目，而目录直接查询仅34个，差异源于嵌套组。数据库使用较大的数字，导致实际权限超出预期。此外，组权限位于数据平面，控制平面查询无法可见，安全审查易被误导。JIT组激活后，已缓存令牌可能继续生效，增加权限滞留风险。
改进方向与规范跟进
作者提出五项改进，并指出MCP规范已禁止转发客户端令牌，以确保下游服务验证调用者身份。命令行工具应跟进此标准。当前无人代理虽配置规范，但数据库仍使用SQL密码登录，导致归因失效。根本解决需为代理提供独立身份，并统一审计与权限管理。
Q&A
AI代理使用人类Azure凭证访问数据库时，权限范围有什么问题？
同一令牌在不同生产库权限差异巨大，一个仅2项权限，另一个达107项，且可删除数据的库缺乏审计。
为什么AI代理的操作无法在审计日志中与人类操作区分？
代理没有独立身份，日志仅记录人类账号，且数据库身份字段（如login_name、program_name）不随操作者变化，无法区分人机操作。
即使配置规范的无人代理，为什么仍然无法正确归因？
因为数据库仍使用SQL密码登录，而不是使用托管身份，导致数据库无法区分不同调用者，归因失效。
作者提出了哪些改进措施来解决代理身份和归因问题？
作者提出五项核心改进，并指出MCP规范已禁止转发客户端令牌，命令行工具应跟进采用相同标准。
为什么生产环境有审计而非生产环境没有，这会导致什么风险？
非生产环境为节省成本未开启审计，但代理可能在其中执行删除等操作，且审计覆盖与凭证权限成反比，导致高风险操作无审计记录。
令牌的84分钟有效期能作为安全边界吗？为什么？
不能。CLI会自动使用刷新令牌续期，无人值守运行不会在84分钟后停止，只有刷新令牌过期或用户账户被停用才会停止。
