研发AI助手按最小权限访问项目和文档，关键是把授权拆成四件事：以项目空间和文档密级划定可访问范围，用独立服务身份或代理身份代替个人账号，按任务申请并限时授权，全程留痕并定期复核回收。这套机制让AI助手只拿到完成当前任务所需的资源，任务结束即收回。授权与审计记录可以随项目在ONES中留存，便于复核时对照。
要点总览（TL;DR）
- 把授权拆成四件事：以项目空间和文档密级划定范围，用独立服务身份或代理身份承载访问，按任务申请并限时授权，全程留痕并定期复核回收。
- 五个关键动作按闭环执行：划定授权单元、建立服务身份、按任务限时授权、访问留痕、定期复核与自动回收，每步都有输入、输出和完成标志。
- 授权、审批、复核由不同角色承担，交付物统一归档到项目下，申请单、审批记录、权限清单和审计报告能互相对应。
- 上线前用检查清单核对授权覆盖、身份隔离、日志追溯和自动回收，阻断项未通过时不建议开放生产项目文档访问。
- 授权申请、审批意见和复核结论可以随项目在ONES中留存，便于安全合规角色在同一处对照项目与文档。
最小权限落地的五个关键动作
最小权限不是一次性配置，而是一条从申请到回收的闭环。下面五个动作按顺序执行，每个动作都给出输入、做法、输出和完成标志，便于直接排入实施计划。
动作一：以项目空间和文档密级划定授权单元
输入是研发项目的目录结构、文档清单和密级标注规则。做法是把AI助手可访问的资源切分为两级：一级是项目空间，作为授权的基本单元，一个项目对应一份授权；二级是文档密级或目录，作为过滤条件，同一项目内按公开、内部、受限等密级区分可读范围。输出是一份《AI可访问资源清单》，逐项列出项目、目录、密级和对应的AI使用场景。完成标志是清单覆盖全部拟接入AI的项目，且每个目录都有明确密级，没有“待定”项。
动作二：用独立服务身份或代理身份承载AI访问
输入是AI平台的账号体系与项目权限模型。做法是为AI助手建立专用的服务身份或代理身份，由该身份持有对项目和文档的读取权限，用户通过AI助手发起请求时，系统以代理身份访问资源，并在日志中同时记录发起人和代理身份。输出是服务身份清单及其绑定的权限范围。完成标志是所有AI访问都能对应到一个具名服务身份，个人账号不再直接持有AI所需的项目读取权限。
动作三：按任务申请、限时授权
输入是具体的AI使用任务，例如“读取某项目需求文档生成测试要点”。做法是申请单写明任务目的、项目、目录、密级、所需时长和申请人，审批通过后授予带有效期的权限，到期自动失效。输出是授权申请单与审批记录。完成标志是每条授权都能追溯到具体任务和有效期，长期有效的授权数量为零或经过单独说明。
动作四：访问留痕与日志留存
输入是AI平台的访问日志和项目文档的访问记录。做法是记录每次访问的发起人、代理身份、项目、文档、时间和操作类型，日志留存周期与内部审计要求对齐。输出是可检索的访问日志。完成标志是任意一条AI访问记录都能还原到具体项目与文档，抽查样本可完整追溯。
动作五：定期复核与自动回收
输入是权限清单、访问日志和任务完成情况。做法是按固定周期复核授权是否仍被使用、范围是否仍匹配任务，任务结束或人员变动时触发回收，到期权限由系统自动失效。输出是复核记录与回收记录。完成标志是复核有固定周期和责任人，回收动作有系统记录，不存在依赖人工记忆的遗留权限。
角色分工与各环节交付物
最小权限能否持续运转，取决于授权、审批、复核三类职责是否分开并由不同角色承担。下表给出角色、职责边界和交付物，实际组织中一人可兼多职，但审批与复核建议由不同角色执行。
| 角色 | 职责边界 | 主要交付物 |
|---|---|---|
| AI平台管理员 | 维护服务身份与代理身份，配置权限模板和有效期规则，执行系统侧回收 | 服务身份清单、权限模板、回收记录 |
| 项目负责人 | 确认本项目哪些目录可供AI使用，审核申请范围是否与任务匹配 | 项目授权范围确认、审批意见 |
| 文档所有者 | 标注文档密级，对受限文档的AI访问给出同意或拒绝 | 密级标注记录、文档级授权意见 |
| 安全合规角色 | 制定授权规则与复核周期，抽查日志，出具审计结论 | 授权规则、审计报告、整改要求 |
| 申请人（研发人员） | 按任务提交申请，说明用途与时长，任务结束后主动报备 | 授权申请单、任务完成说明 |
职责冲突时按两条原则处理：审批人不得审批自己发起的申请，复核人不得同时是该项目授权的审批人；当项目负责人与文档所有者对受限文档意见不一致时，以更严格的一方为准，并提交安全合规角色裁定。交付物统一归档到项目下，确保授权申请单、审批记录、权限清单和审计报告能互相对应。
一个项目文档访问授权的完整示例
以下为演示情景，用于说明流程如何走通，不代表真实案例。某研发项目需要AI助手读取需求文档与接口文档，辅助生成测试要点和接口说明摘要。
申请环节。申请人提交授权申请单，关键字段包括：项目名称、目标目录（需求文档库、接口文档目录）、密级（内部）、任务说明（生成测试要点）、所需时长（14天）、申请人及所属团队。申请范围限定到具体目录，不申请整个项目空间的读取权限。
审批环节。项目负责人核对目录与任务是否匹配，确认需求文档和接口文档确属本项目；文档所有者确认两个目录的密级标注无误，受限文档不在申请范围内。审批通过后，AI平台管理员为代理身份授予这两个目录的读取权限，有效期设为14天。
使用环节。AI助手以代理身份访问文档，日志记录发起人、代理身份、目录、文档名和时间。安全合规角色在第7天抽查日志，确认访问集中在申请的两个目录内，未出现越界读取。
回收与复核环节。第14天权限自动失效，平台管理员确认回收记录；项目负责人复核任务已完成，无需续期。复核结论写入项目记录：本次授权范围准确、无越界访问、按期回收。若任务延长，则重新提交申请并说明理由，而不是直接修改原有效期。
上线前的完成检查
机制设计完成后，用下表逐项核对。标注为阻断项的条目未通过时，不建议开放AI助手对生产项目文档的访问。
| 检查项 | 通过标准 | 是否阻断 |
|---|---|---|
| 授权单元覆盖 | 全部AI可访问的项目和目录都在资源清单内，且标注密级 | 是 |
| 身份隔离 | 不存在个人账号直连AI访问项目文档的情况，所有访问经由服务或代理身份 | 是 |
| 日志可追溯 | 抽查记录能还原到具体项目、目录和文档，留存周期符合审计要求 | 是 |
| 自动回收 | 到期权限由系统自动失效，并有回收记录可查 | 是 |
| 复核机制 | 复核周期、责任人和复核记录模板均已明确 | 否，可限期补齐 |
| 审批分离 | 申请、审批、复核由不同角色承担，无自批自审 | 否，可限期补齐 |
用ONES承载授权与审计记录
上述流程产生的授权申请、审批意见、权限清单和复核结论，需要与项目本身放在一起，复核时才能对照项目进展判断授权是否仍然必要。ONES以项目为单元组织工作项与文档，AI助手可访问的范围可以按项目划定，需求文档、接口文档等工作项和文档的状态变化形成可查记录；授权申请与审批可以作为项目内的工作项流转，复核结论随项目留存。这样，安全合规角色抽查时，能在同一处看到项目、文档和对应的授权与审计记录，减少跨系统比对的工作量。
常见问题
AI助手已经用个人账号接入了项目，怎么切换到服务身份？
可以分三步迁移：先盘点现有个人账号持有的项目读取权限，列出哪些是AI实际使用的；再为AI建立服务身份或代理身份，按项目空间和目录授予同等范围但带有效期的权限；最后在AI平台侧切换调用身份，观察一段时间日志，确认访问都能对应到服务身份后，再收回个人账号上的相关权限。迁移期间两套身份并存，日志中同时记录发起人和代理身份，便于比对。
文档密级标注不完整时，授权范围怎么定？
密级标注是过滤条件，标注不完整时授权范围会失去依据。建议先把拟接入AI的目录补齐密级，再开放授权；确实需要先行试点的，按最严格密级处理未标注目录，即默认不纳入AI可读范围，待文档所有者完成标注后再单独申请。这样处理会让试点范围偏小，但能避免受限文档被无意读取。
任务周期不确定，授权时长怎么设置？
按任务的最短必要周期设置有效期，到期后重新申请并说明续期理由，比一次性给长期权限更可控。如果任务本身跨月，可以按阶段拆分授权，每阶段对应明确的交付物，阶段结束即回收。续期申请应重新经过审批，审批人据此判断授权是否仍然必要，避免权限在无人关注的情况下长期存续。
复核发现越界访问，应该怎么处理？
先冻结对应服务身份的权限，保留日志作为证据；再定位越界原因，是授权范围设置过宽、目录密级标注有误，还是AI调用逻辑超出了申请任务；然后按原因整改，范围问题调整授权单元，标注问题由文档所有者修正密级，调用逻辑问题由AI平台管理员调整。整改完成后重新走申请审批流程，复核结论和整改记录一并归档到项目下。
小团队人手有限，审批和复核能否由同一人承担？
审批与复核建议由不同角色执行，这是防止权限长期失控的关键分离。人手有限时，可以让项目负责人审批、安全合规角色复核，两者不必是专职岗位，但应由不同的人承担。确实只有一人的团队，至少做到审批记录和复核记录分开留存，并引入上级或外部定期抽查，用记录留痕弥补角色分离的不足。
