AI最小权限检查的目标，是确认每个AI应用、助手或模型调用接口只拿到完成当前任务所必需的数据和操作权限。检查应覆盖身份与授权、数据边界、工具调用、日志追溯和变更退出五类风险，并在上线前、权限变更时和周期性复核中重复执行。下文按角色时点、分项检查表、阻断项与放行条件展开，可直接用于评审记录。研发团队若使用ONES管理权限申请、审批与复核记录，也可把检查结论关联到对应工作项，便于后续追踪。
要点总览（TL;DR）
- AI最小权限检查围绕五类风险展开：身份与授权、数据边界与模型调用、工具调用与操作执行、日志追溯与复核、阻断项与放行判定。
- 检查时点分三类：上线前评审逐项留证，权限或配置变更时聚焦受影响项，周期性复核侧重权限是否仍然必要。
- 判断授权是否最小化，可让应用负责人逐条说明每项权限支撑的具体任务；说不清对应任务的权限通常可以收回或降级。
- 敏感数据无边界、外部模型调用数据流向不清、高权限操作无审批、共享账号无唯一身份、批量或删除操作无额外限制，应列为阻断项，未关闭前不放行。
- 放行需满足阻断项全部关闭、非阻断项有明确结论、四方角色会签完成、下一次复核计划已建立，并将检查表与证据一并归档。
谁在什么时点使用这份检查清单
这份清单的检查对象是投入使用的AI应用、AI助手、模型调用接口，以及负责配置和维护它们的团队。检查时点分为三类：上线前评审、权限或配置变更时、周期性复核。三类时点的检查深度不同，上线前要求逐项留证，变更时聚焦受影响项，周期复核侧重权限是否仍然必要。
参与角色需要提前明确，否则检查表容易停留在安全团队单方填写。应用负责人对业务必要性和使用范围负责；安全或权限管理员核对授权配置与审批依据；数据负责人确认数据范围和敏感数据处理方式；审计方抽查记录完整性与复核闭环。四方在同一张表上签字，比事后补说明更能反映真实状态。
| 时点 | 触发条件 | 主责角色 | 产出 |
|---|---|---|---|
| 上线前评审 | AI应用首次接入业务数据或对外提供服务 | 应用负责人牵头，安全、数据角色会签 | 完整检查表与放行结论 |
| 权限变更 | 新增数据源、新增工具调用、调整角色或授权范围 | 安全或权限管理员 | 变更影响项检查记录 |
| 周期性复核 | 按团队约定周期执行，或人员转岗、离职后触发 | 审计方组织，应用负责人确认 | 复核结论与权限回收记录 |
角色分工确定后，检查项才有明确的责任人和证据来源。以下各节的检查表均按“检查项—通过标准—证据—负责人”组织，阻断项单独标注。
身份与授权检查项
身份与授权是AI最小权限的第一道关口。核心判断是：AI使用主体是否有唯一身份，授权是否按任务收敛，高权限操作是否留下审批依据。以下检查项中，任一项无法提供证据，都应视为未通过。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| AI应用或服务账号是否有唯一身份标识 | 每个AI应用、助手或接口使用独立账号，不与个人账号共用，账号名称可对应到应用负责人 | 账号清单、负责人登记记录 | 安全或权限管理员 |
| 授权范围是否按任务最小化 | 授权清单能说明每项权限对应的业务任务；读写权限分开授予，查询类任务不附带写入权限 | 权限配置截图或导出记录、任务与权限对照说明 | 应用负责人 |
| 高权限操作是否有审批记录 | 涉及批量导出、跨项目访问、删除或修改配置的操作，有申请单和审批人签字，审批时间早于权限生效时间 | 审批单、权限生效时间记录 | 安全或权限管理员 |
| 人员离职或转岗后权限是否回收 | 离职、转岗人员相关的AI应用授权、个人令牌和共享账号在约定时限内完成回收或转移 | 人员变动记录、权限回收记录 | 应用负责人与人事接口人 |
判断授权是否最小化，可以用一个简单方法：让应用负责人逐条说明“这项权限支撑哪个具体任务，去掉后哪个功能会失败”。说不清对应任务的权限，通常可以收回或降级。读写分离尤其要检查，很多AI助手只需要读取项目信息回答问题，却因为配置方便被授予了修改工作项的权限。
在ONES中，权限申请、审批和复核结论可以记录在对应工作项或Wiki页面中，检查时直接调取审批记录和变更历史，减少在多个系统之间核对的时间。ONES AI研发管理方案说明其AI能力基于ONES权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，这一前提也意味着授权配置本身需要被纳入检查范围。
数据边界与模型调用检查项
数据边界检查回答两个问题：AI能访问哪些数据，数据在调用外部模型时流向哪里。这一节的风险往往比身份配置更隐蔽，因为提示词和上下文可能在不经意间夹带超出任务范围的数据。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断项 |
|---|---|---|---|---|
| 可访问数据是否按项目或字段限定 | AI应用的数据范围有明确配置，按项目、知识库或字段限定，不默认继承全组织数据 | 数据范围配置记录、范围说明文档 | 数据负责人 | 是 |
| 敏感数据是否脱敏或禁止进入提示词 | 明确列出禁止进入提示词的数据类型，如个人身份信息、密钥、未公开财务数据；必要场景有脱敏规则 | 敏感数据清单、脱敏规则或过滤配置 | 数据负责人 | 是 |
| 外部模型调用是否明确数据留存与传输边界 | 调用外部模型前，确认数据传输范围、留存策略和退出机制，并在配置或合同中体现 | 模型服务配置说明、数据处理约定 | 安全或权限管理员 | 是 |
| 提示词与上下文是否可能夹带越权数据 | 抽查典型提示词和上下文组装逻辑，确认检索结果、附件和引用内容均经过权限过滤 | 抽查记录、上下文组装逻辑说明 | 应用负责人 | 否 |
敏感数据无边界、外部模型调用数据流向不清，属于典型阻断项，未关闭前不应放行。提示词夹带越权数据虽然列为非阻断项，但一旦在抽查中发现实际案例，应按阻断项处理并回溯影响范围。检查时建议选取三类样本：正常业务提问、跨项目提问、包含敏感字段的提问，观察AI返回内容是否超出提问者应有范围。
ONES AI研发管理方案提到在Wiki页面、附件、音视频和个人协作数据中建立统一知识上下文，并保障权限边界。对使用此类知识上下文的团队，检查重点应放在知识库范围配置和问答结果是否遵循原有页面权限，而不是只看模型侧配置。
工具调用与操作执行检查项
当AI从回答问题走向执行操作，权限风险从“看到什么”扩展到“改了什么”。工具调用检查要确认AI代理能操作的对象范围、写操作是否有确认环节、批量与删除动作是否受到额外约束。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 工具调用是否限定可操作对象与范围 | 每个可调用工具列出允许操作的对象类型和范围，如仅限指定项目的工作项，不开放全组织范围 | 工具清单与范围配置 | 应用负责人 |
| 写操作是否有人工确认或二次校验 | 创建、修改、状态流转等写操作在执行前有确认步骤，或执行后有可回退的校验机制 | 操作流程说明、确认环节截图 | 应用负责人 |
| 批量操作与删除类动作是否有额外限制 | 批量修改、批量导出、删除类动作需要单独授权或人工审批，不包含在默认工具权限中 | 权限配置、审批记录 | 安全或权限管理员 |
| 调用失败或异常时是否停止而非扩大权限 | 工具调用失败、超时或返回异常时，AI停止当前动作并提示人工处理，不自动切换更高权限账号重试 | 异常处理配置、失败日志样本 | 应用负责人 |
写操作的人工确认环节需要区分场景。高频、低风险的内部状态更新可以设置执行后通知和回退入口；涉及对外发布、客户数据或删除的动作，应要求执行前确认。检查时不要只看流程文档，抽取最近若干次实际调用记录，确认确认环节确实发生过。
ONES Assistant智能助手能够理解项目、工作项、迭代和Wiki页面等真实工作上下文，并直接执行后续操作。对这类能执行操作的助手，检查重点应放在其可操作对象是否与使用者的项目权限一致，以及执行结果是否能在工作项历史中追溯。
日志、追溯与复核检查项
日志与复核检查确认AI使用行为是否可记录、可追溯、可复核。没有记录，前面几节的检查只能反映配置状态，无法证明实际运行符合最小权限要求。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 是否记录调用主体、时间、对象与结果 | 每次AI调用可查到使用主体、调用时间、访问或操作的对象以及执行结果 | 日志样本、字段说明 | 安全或权限管理员 |
| 敏感操作日志是否留存并受保护 | 涉及敏感数据访问、批量操作和删除的日志单独留存，访问日志本身需要授权，防止被修改或删除 | 日志留存配置、访问控制记录 | 安全或权限管理员 |
| 是否设定周期性权限复核机制 | 有明确的复核周期、复核人和复核结论记录，复核后对不再需要的权限执行回收 | 复核计划、复核记录、回收记录 | 审计方 |
| 异常访问是否有告警或发现路径 | 对超出授权范围的访问尝试、异常调用频率设有告警规则或定期排查路径，并有处理记录 | 告警规则配置、异常处理记录 | 安全或权限管理员 |
复核机制的关键是形成闭环：复核发现权限多余，要有回收动作和确认记录；复核发现日志缺失，要回到对应检查项补配置。只有复核记录没有回收动作，不能算通过。ONES AI研发管理方案说明其基于ONES权限体系运行，输出过程可追踪、结果可审计，团队可将复核结论与工作项状态关联，让每次复核都有对应记录和责任人。
阻断项与完成条件
阻断项是未关闭即不能放行的检查项。建议至少将以下情形列为阻断：可访问数据未按项目或字段限定；敏感数据无脱敏或禁止进入提示词的规则；外部模型调用的数据留存与传输边界不明确；高权限操作无审批记录；AI应用使用无唯一身份标识的共享账号；批量或删除类操作无额外限制。各团队可根据业务敏感度增补，但增补项需在评审前书面确认。
阻断项未关闭时，处置方式有三种：一是暂停上线或暂停相关功能，待配置补齐后重新检查；二是收缩范围，先关闭涉及敏感数据或高权限的工具调用，以受限模式运行；三是设置限期整改，明确整改责任人和复查时间，整改期间限制使用范围。三种方式都需要在评审记录中写明，不能以口头同意代替。
| 放行条件 | 判定标准 | 确认方式 |
|---|---|---|
| 阻断项全部关闭 | 所有标注为阻断的检查项均有通过证据，无遗留项 | 安全或权限管理员核对并签字 |
| 非阻断项有明确结论 | 未通过项已记录风险、责任人和整改期限 | 应用负责人确认 |
| 角色会签完成 | 应用负责人、安全或权限管理员、数据负责人、审计方均完成确认 | 评审记录签字或系统审批记录 |
| 复核计划已建立 | 下一次周期性复核的时间和责任人已确定 | 复核计划记录 |
全部检查项通过并完成会签后，方可放行上线或继续使用。放行结论应连同检查表、证据和整改记录一并归档，作为下一次复核的基线。权限发生变更时，从变更影响项重新检查，不必每次重跑全表，但阻断项必须重新确认。
常见问题
上线前检查已经通过，后续还需要在什么情况下重新检查？
上线前评审通过只代表当时的配置状态。出现以下变化时应重新检查：新增数据源或知识库范围、新增可调用的工具或操作类型、调整角色授权或审批流程、接入外部模型服务、人员转岗或离职导致账号与令牌需要回收。变更时不必重跑全表，聚焦受影响项即可，但阻断项必须重新确认并留下证据。
检查表由安全团队单独填写可以吗？
不建议。安全团队单独填写容易只反映配置层面，难以判断权限是否真的对应业务任务。应用负责人需要说明每项权限支撑的具体任务，数据负责人确认数据范围和敏感数据处理方式，审计方抽查记录完整性。四方会签的检查表更能反映实际运行状态，也便于后续复核时对照。
AI助手只做问答、不执行写操作，工具调用部分还需要检查吗？
需要，但检查重点不同。只做问答的助手仍可能调用检索、读取类工具，应确认其可访问的数据范围与提问者的原有权限一致，检索结果和引用内容经过权限过滤。写操作相关的人工确认、批量与删除限制可以标注为不适用，但要在检查表中写明理由，避免后续功能扩展时遗漏。
发现提示词可能夹带越权数据，但未列为阻断项，应该怎么处理？
提示词夹带越权数据在清单中列为非阻断项，前提是抽查未发现实际案例。一旦在抽查中确认存在实际越权返回，应按阻断项处理：暂停相关功能或收缩数据范围，回溯已发生调用的影响范围，补齐权限过滤后再重新检查。处理过程和结论应记录在评审记录中。
周期性复核发现权限多余，只记录不回收算通过吗？
不算。复核机制的关键是形成闭环：发现权限多余要有回收动作和确认记录，发现日志缺失要回到对应检查项补配置。只有复核记录没有回收动作，不能视为通过。复核结论、回收动作和责任人应关联到对应工作项，作为下一次复核的基线。
