AI 工具访问安全审查：从授权到撤销验证权限生命周期

AI 工具访问安全审查需要回答一个比“智能体能否被操纵”更具体的问题：系统执行动作时，使用的是谁的权限、哪个租户和资源、哪个确切动作、哪一次批准，以及该权限有效多久？在交互式对话、队列任务、重试和管理员撤销访问之后，答案可能完全不同。

虚构场景——Harbor Finance。 财务助手代表已登录员工读取发票，同时使用应用身份，在夜间把获批记录写入会计系统。经理批准了供应商 A、账户 X 的草稿。队列执行前，草稿被改成供应商 B、账户 Y。随后员工离职，其委托授权被撤销。审查必须确认：延迟写入是否仍会发生、由哪个身份授权、旧批准是否仍然有效，以及哪些令牌、导出文件、任务结果或应用会话继续存在。

这属于权限生命周期问题。它与过度代理能力和 MCP 安全有关，但不是另一份提示注入清单。审查需要沿着授权、使用、批准、撤销和清理追踪权限，为能够读写真实系统的助手、企业 Copilot 或智能体提供可验收的结论。

先明确谁能操作、操作哪些资源以及权限有效多久

工具名称几乎不能说明访问范围。“搜索文件”可能只能读取一个项目目录，也可能读取整个租户。“创建草稿”看似低风险，但另一个服务可能自动提交所有草稿。对每个可调用操作，应建立一份访问记录：执行身份、客户端或智能体、租户、目标资源、允许动作、重要参数、批准上下文、有效期和执行通道。执行通道用于区分前台请求、队列、定时任务、重试、Webhook 和重放。

OAuth 作用域通常描述访问类型，并不总能标识具体资源实例或业务对象。OAuth Resource Indicators 允许客户端声明目标资源；Rich Authorization Requests 可以携带结构化授权详情。这些是 OAuth 生态中的可选机制，并非每个已部署系统都具备。因此，审查必须验证实际的授权服务器、资源服务器、连接器和应用分别执行了什么控制。

访问记录还能拆开三个常被混为一谈的决定：同意授予客户端一类访问能力；运行时策略决定某次调用现在是否允许；交易批准确认某个有后果的具体动作。宽泛的同意页面不能代替未来每一笔付款、每一条消息、每一次权限修改或数据导出的批准。

区分委托权限与应用权限

在委托访问中，应用代表已登录用户操作。按照 Microsoft Graph 的模型，有效权限同时受应用的委托权限和用户自身权限约束。在应用访问中，应用以自己的身份操作，不需要已登录用户；这类权限可能覆盖组织数据，因此属于高权限。其他平台名称不同，但核心问题相同：下游系统能否识别人类主体，还是只看到工作负载身份？

后台任务启动时，这一区别尤其关键。原始聊天中存在用户，不代表队列工作程序就可以声称“用户批准了执行”。任务可能在用户角色变化后，由权限更宽的服务主体运行，也可能根据可修改的任务数据切换到另一个租户。审查应追踪原始请求身份、任务内保存的身份、工作程序使用的凭据，以及下游审计日志中的主体。

资源特定权限可以缩小“租户级授权”与“实际需要的对象”之间的差距。例如，Microsoft 的 Selected permissions 模型同时要求相关作用域、针对资源的显式分配，以及携带该作用域的令牌。这是特定产品设计，不是 OAuth 的普遍保证。其通用原则是：验证客户端权限、资源分配、人类或应用身份以及请求动作的交集。

对于采用 2025 年 11 月 25 日版授权规范的 HTTP MCP 部署，该规范要求服务器验证入站令牌确实为本服务器签发，并禁止把同一令牌直接传递给下游 API。服务器调用其他 API 时，应为该资源使用单独令牌。已有的 MCP 服务器安全评估指南详细讨论了协议边界；本文继续追踪批准、延迟执行、撤销和残留状态。

把批准绑定到最终执行的动作

只有覆盖重要交易数据，批准才有意义。付款的重要数据可能包括收款人、账户、金额、币种、付款账户、租户和操作类型。消息的重要数据可能包括频道、收件人、附件、数据分类，以及“保存草稿”还是“发送”。审批人应查看来自可信服务端记录的值，而不是可编辑的客户端文字。

OWASP 的交易授权指南提供了适用的通用模式：在服务端执行决定；保证状态按顺序转换；重要数据变化时让批准失效；限制有效时间；每次授权只对应一次操作；执行前设置最终关口。应用到 AI 系统后，批准应是针对一个规范化动作的短期、一次性能力，而不是对话中的长期“用户说可以”标记。

应使用无害变体测试过期批准。先批准一个控制动作，再修改一个重要参数、切换目标租户、复用同一批准、在过期后执行，并测试取消与执行的竞态。每组拒绝测试前先做正向控制，证明未修改的动作能由预期账户成功执行。随后还要检查下游系统；聊天中出现友好的错误消息，并不能证明没有产生副作用。

1. 构造服务端规范化身份、租户、资源、动作和重要参数
2. 批准向审批人展示这些值，并签发短期、一次性的决定
3. 重新评估执行时检查当前授权、任务所有者、策略、参数和取消状态
4. 预留派发前，以原子操作将一次性批准绑定到一个操作，拒绝竞争请求
5. 核对使用操作标识派发，记录下游结果，在重试前核实未知结果

把队列与后台任务视为新的授权时刻

队列把意图和效果拉开。在此期间，用户可能离职、角色可能变化、应用授权可能删除、资源可能迁移到其他租户、批准可能过期，任务内容也可能被修改。安全的工作程序不能把“已进入队列”等同于“始终有权执行”。

建议保存不可变意图：主体、客户端、租户、资源、操作、规范化参数、批准标识、创建时间、有效期以及摘要或版本。执行时，工作程序检查任务所有权与状态、取消和过期情况，并重新评估相关当前权限。如果业务明确要求任务在用户离职后仍继续，应采用显式的应用权限设计，指定责任人并限制服务身份，而不是让队列凭据偶然造成这种结果。

重试需要单独测试。下游动作可能已经成功，但工作程序在记录成功前遇到网络超时。我们建议在派发前，以原子操作把批准预留给一个操作，防止两个工作程序同时使用它。下游调用需要幂等机制或经过验证的防重复方案；仅有标识符并不能保证动作不重复。结果未知时，应先核实再重试。读取已提交的结果不同于授权新的副作用，过期或已撤销的批准不能允许新的动作。

如果取消发生在下游提交之后，就无法撤回已经完成的动作；应记录竞态结果，并在另行授权后执行必要的补偿操作。任务读取、结果查询、取消和列表操作也要按任务授权；难以猜测的任务标识不是访问控制。

最低测试矩阵应覆盖：用户禁用前后、委托同意删除前后、应用权限删除前后、资源授权删除前后、批准过期、任务取消、租户变化和工作程序凭据轮换。每一行都应写明预期由哪个控制阻断哪条路径，避免一个层面的成功撤销掩盖另一个仍然有效的入口。

测量撤销延迟，并明确被撤销的对象

“已撤销”可能指刷新令牌、访问令牌、应用会话、委托同意、应用角色分配、资源特定授权、工作程序凭据或任务本身。删除其中一个，并不能证明其他对象全部停止工作。

OAuth Token Revocation 要求实现支持撤销刷新令牌，并建议支持撤销访问令牌。如果授权服务器不支持访问令牌撤销，令牌可能一直有效，直到过期或被其他执行点拒绝。Token Introspection 允许资源服务器查询令牌是否有效，但标准也明确指出：缓存可以降低负载，却会形成已撤销状态仍未传播的窗口。标准定义机制和权衡，并不保证所有产品具有相同撤销时间。

Microsoft 文档体现了同样的边界。禁用用户并撤销刷新令牌可以阻止获取新令牌；现有访问令牌仍可能在到期前有效，除非应用与资源支持连续访问评估等机制。由应用自身签发的会话由应用控制，身份提供方无法直接撤销。应用权限属于应用身份，因此删除某个人类用户不会自动移除应用级授权。

审查应当测量，而不是假设。先执行一项有效、低影响的正向控制，在记录的时刻触发一种撤销；随后用现有访问令牌重复同一请求，再尝试刷新或获取新令牌，并检查应用会话和后台工作程序路径。在事先约定的安全边界停止。报告应记录每条路径最后一次成功与首次拒绝的时间、采样间隔、后续结果、拒绝组件和观察上限。连续拒绝可以缩小不确定范围；单次拒绝并不能证明所有副本或路径都已永久切断访问。“在测试窗口内被拒绝”是可验证结论；“撤销立即生效”通常不是。

检查残留权限、凭据、任务与制品

撤销会终止部分未来动作，但不会自动删除智能体已获取或创建的内容。文档缓存、导出文件、向量索引条目、对话附件、生成报告、队列载荷、任务结果、日志、浏览器下载和下游草稿都可能继续存在。工作程序还可能保留位于身份系统之外的刷新令牌、API 密钥、客户端密钥或应用 Cookie。

应为每个连接器建立残留状态清单。记录凭据存储位置、读取者、轮换和删除方式，以及日志是否包含令牌。再把数据制品映射到所有者、租户、分类、保留期、访问规则和删除路径。相关撤销控制生效后，应阻止依据该已撤销授权进行新的数据获取；除非已单独执行并验证删除，否则不能声称旧副本也被清除。

这正是生命周期审查与登录测试的区别。评估人员要确认：权限已结束的任务不能继续使用该权限恢复执行；缓存结果不能被无权访问的用户或租户读取；已撤销的连接器不能用保留的刷新令牌重新激活；下游草稿或链接不会保留完成动作的能力。如果法规或业务要求保留制品，报告应明确残留内容及其补偿控制，而不是宣称“已完全删除”。

围绕决策与证据界定审查范围

有效范围应包含身份提供方、智能体或客户端、授权与批准服务、工具网关、队列和工作程序、凭据存储、代表性下游 API、租户边界及制品存储。测试材料包括差异明显的角色账户、权限狭窄的应用身份、实际使用的资源特定授权、非生产租户、无害控制对象、相关日志和叫停联系人。破坏性动作、批量提取和真实外部消息，除非另有授权，否则不在范围内。

评估应先审查架构和配置，再执行受控测试。每个拒绝场景之前都要建立有效正向路径，避免把无效令牌或损坏对象造成的失败误判成安全控制。证据应保留策略决定、可用时的令牌声明或 introspection 结果、队列事件、工作程序身份、下游响应和对象最终状态，同时证明请求被拒绝且未发生禁止的副作用。 报告只应保留必要字段与标识，隐藏仍可使用的令牌和密钥，并限制对评估证据的访问。

交付物应包含权限地图、授权清单、批准绑定结果、队列与重试结果、测得的撤销行为、残留状态发现和复测计划。结论只适用于已测试身份、产品、配置和观察窗口。如果更关心智能体可能被诱导执行什么，可以结合阅读过度代理能力安全测试；本审查重点是证明权限如何随时间变化。

在启用可写工具、从委托访问切换到应用身份、增加后台执行，或修改撤销与批准控制之前，独立评估尤其有价值。Pentest.red 可在 AI 与 RAG 安全评估中验证约定的 AI、身份、队列和下游边界。渗透测试范围规划器可帮助整理角色、租户、工具和安全控制对象，渗透测试报告示例则展示应要求的可复现证据深度。审查不会认证所有未来配置；它为实际检查过的权限生命周期提供具体发现和复测标准。