AI 用谁的身份读文档：用户授权与服务账号怎样取舍
一名销售让 AI 汇总本周客户纪要，另一个后台任务每晚整理公共制度。两项任务都要读文档，却不宜共用同一种授权方式。前者需要证明“这次访问代表哪位员工”，后者需要证明“这个无人值守任务被允许处理哪些资料”。如果只给 AI 一个能读全库的账号，这两个问题就被隐藏了。
先区分身份，再讨论权限
Microsoft Foundry 的代理身份文档区分应用自身身份与委托用户身份：应用身份按自己的授权访问；委托模式同时受到应用获准范围和用户访问权约束。文档还强调，认证通过并不等于获得资源权限，下游服务仍负责授权。其中代表用户调用的能力在所引文档中仍属预览，支持范围需按具体工具确认。这也提供了一个可用于其他系统评估的检查思路：登录成功、拿到令牌、读到某份文件，应分别验证。
| 任务 | 优先评估的身份方式 | 需要回答的问题 |
|---|---|---|
| 员工当场询问自己的项目资料 | 委托用户访问 | 应用与员工的权限交集是否生效 |
| 定时处理已批准的公共资料 | 独立服务身份 | 目录、用途与有效期是否被限定 |
| 跨部门汇总敏感经营材料 | 专门审定的任务身份 | 谁批准范围，谁对结果负责 |
避免把授权扩大藏在连接器里
采购或接入时，可以用两个权限不同的测试员工查询同一份受控样本文档。一个应能读取，另一个应被拒绝。随后撤回前者的权限，再执行一次请求，检查结果是否变化。不要只测试前端页面：连接器可能使用另一个服务账号，导致页面权限正确、AI 后端却仍能访问。测试报告需要写清真实访问文档的身份，而不是只写发起聊天的人。
对于无人值守任务，建议把身份绑定到具体业务责任人，记录允许的资料集合、用途、运行时间及停用条件。服务账号不应靠共享员工密码维持运行。Microsoft Entra 的代理用户有其专门的凭证与登录限制，这也提醒团队，机器主体的生命周期应单独管理，不能简单复制一个普通员工账号后长期闲置。
日志中保留两个主体
一条可解释的访问记录，至少应能关联发起人、实际执行身份、目标文档标识、授权策略版本以及结果。使用服务身份时，不能凭日志中的“服务账号访问成功”反推具体员工拥有权限；使用委托身份时，也不能省掉应用自身的范围检查。若调用链中无法传递用户身份，应明确标为身份链缺口，限制场景，而不是补一个猜测的用户名。
落地顺序可以很小：先选一个交互查询和一个定时任务，分别画出身份链，再做允许、拒绝、撤权三组测试。通过后把结果写成连接规范，后续接入复用。这里给出的是评估方法，具体身份能力仍需由所用文档系统、模型平台和连接器共同验证，不能由其中一方的宣传页替代。
在企业文档中验证
如果要把本文方法用于企业文档，可预约演示，结合实际资料核对协作、权限与集成方式。
需要在自己的环境中验证时，可先了解私有化部署方案，再确定试用范围与验收要求。