AI Agent的权限,为什么需要在任务执行过程中不断改变?

AGENT SECURITY · 持续授权篇

从Microsoft Project Perception、ServiceNow AI Passport，到MCP执行安全与独立验证：一份授权，怎样跟上Agent的工作过程

一次报销审核中的动态授权：从任务发起、策略决策、工具调用到结果与证据。

参考架构示意，不代表厂商已完成联合集成；网关检查与运行时隔离属于不同控制点。

上午9点，财务主管Alice把一批报销单交给Agent。它读发票、查政策、核对供应商，然后批准符合条件的小额报销。

9点05分，它在一份外部文件里读到一段诱导性指令，开始尝试修改一家供应商的付款账户。

身份还是那个身份，Token也没有过期。可五分钟前的判断，已经不能直接沿用。

这是为解释架构而设的假设场景，不是已发生的客户事故；文中的控制流程也是参考设计，不代表几家厂商已组成联合方案。

此前我们从“公司里来了一位AI同事”谈到身份、负责人和工具权限。这一篇把镜头往下移：这位AI同事开始干活以后，授权怎样跟上它不断变化的执行过程？

聊天助手把答案交给人，后面的操作由人完成。能调用工具的Agent则会把一个业务目标拆成多步：读文件、访问应用、修改记录，必要时把部分工作交给子Agent。只守住任务入口不够，安全检查还得贴近那些真正改变业务状态的动作。

10月19日，Microsoft宣布把Project Perception的保护范围扩展到“智能体内部人”（agentic insider），提出按任务和动态风险调整Agent权限；10月15日，ServiceNow发布AI Passport，想让委派权限在执行路径上可被验证。前后不到一周，GitHub的一则MCP安全公告和Snyk的Agentic AppSec发布，又分别把问题推到了底层执行和结果验证。⁠^1,2,3,4

先看全貌

同一条执行链，需要三种不同的约束

01任务在继续，权限不能停在起点

先把Alice的要求写清楚。她并没有让Agent“管理财务系统”，只是让它审核这一批报销。

这段话还不能直接当安全策略用。平台要把它转成机器能检查的约束：报销单集合、可见字段、允许的操作、金额条件、目标系统、有效时间，以及哪些动作必须交给人。

任务意图是授权的输入，不是Agent给自己扩权的理由。模型可以提出需要哪些工具，最终授予什么能力，要由企业策略和有权限的审批人决定。

先分清四个角色：谁负责、谁派活、谁授予、谁执行

Alice可以是Agent的业务负责人，也可以是这次任务的发起人；财务系统管理员负责配置访问范围；Expense Review Agent才是真正的执行主体。

在小型演示里，这几个角色常常是同一个人；在企业里却未必重合。某位同事能给Agent发消息，不代表他能让Agent动用整个部门的权限；能管理Agent配置的人，也不一定有权批准付款。

所以审计记录不能只剩一个agent_id，至少要分得清负责人、任务发起者、权限授予方和执行实例。Agent把工作交给子Agent时，还要保留父子关系和这次委派的边界。

Microsoft：可以继续工作，不一定可以继续写入

Microsoft在10月19日宣布引入Dynamic Permissions、Dynamic Agent Risk和Dynamic Conditional Access，把任务授权、行为变化和多个安全控制点连在一起。按官方描述，权限按任务限定并带有时限；风险上升后，策略可以缩减权限、保留读取而阻止写入、收窄Agent能触及的数据和资源，或在关键动作前要求可验证的人工批准；风险最高时，还可以隔离运行环境或直接停止执行。⁠¹

这比“允许运行／彻底封禁”二选一要细。放到本文的例子里：Agent仍然可以查看当前报销单，但写入付款账户会被拒绝；需要人工处理的单据进入待办，不必连带中断整个财务团队的工作。

这篇博文没有说明上述能力的预览或正式提供时间，也不能据此认为任何第三方Runtime都已有同样的控制深度。实际部署还要看三件事：身份怎样传递，策略在哪里执行，被撤销的权限多久能在目标系统失效。⁠¹

把一次报销审核拆开，控制点就清楚了

篇首的图把这次报销审核拆成了六步。其中“需要人工确认”的付款账户修改，按前面写下的任务边界并不属于这次任务，应转入独立的授权流程。下面按顺序看几个关键控制点。

任务建立时，先确认授权来源。系统验证Alice的身份、她是否有权发起这批审核，以及Agent自己的执行身份。部门有多少权限，不能直接变成Agent有多少权限。

访问资源前，按需拿凭证。凭证代理（Credential Broker）可以在受控位置换取只面向指定资源的访问凭证，目的是减少Agent接触长期密钥的机会，并不是说所有下游系统都天然支持临时令牌。OAuth Token Exchange提供了交换令牌、表达“主体”与“执行者”关系的机制，完整的任务语义仍要靠平台和资源侧策略补上。⁠⁵

关键动作前，把判断和执行分开。策略判断点（PDP，Policy Decision Point）综合身份、委派范围、当前任务和资源策略，给出放行、拒绝或要求审批。策略执行点（PEP，Policy Enforcement Point）必须位于真实的调用路径上，把这个结果落实到工具或资源访问。

在这个流程里，“需要审批”不等于已经放行。审批要绑定具体的任务、目标、参数和有效期；批准之后，如果收款账户、金额或目标系统变了，旧的批准就不能直接复用。

执行之后，还要确认系统到底做了什么。Agent的回答、网关的调用记录、业务系统的实际结果要能关联起来。任务结束后，平台回收临时授权；如果子任务还在运行，就按事先定好的规则结束或重新授权。

ServiceNow：让委派权限有一份可验证的凭据

ServiceNow是企业工作流和IT服务管理平台厂商。它在10月15日发布的AI Passport，是一份带加密签名、供Agent在运行时出示的授权凭证。它以CMDB中的实时业务上下文为基础，并与GRC策略和工作流审批关联；在第三方Agent治理上，ServiceNow提到了逐级收窄的委派和精准撤销。官方预计2026年第四季度提供；NVIDIA作为设计与发布合作伙伴，在自己的Open Agent Safety Platform上构建面向生产环境的执行层实现。⁠²

CMDB（配置管理数据库）在这里不只是记录一台服务器叫什么，还能提供资产归属、业务关系等授权上下文。Passport要做的，是把“这个Agent获得过什么授权”变成下游能检查的记录，而不是只听Agent自己声明。

和Microsoft偏重风险反馈的路线相比，ServiceNow更强调可验证的授权凭据和业务上下文。两者分别回答两个问题：当前权限是否仍然合适，以及这份权限从哪里来。这里比较的是控制位置，并不代表两套产品已经互通。⁠^1,2

签名有效，不代表动作就该执行。资源端仍要检查：凭证是否适用于当前请求，授权是否已被撤销，参数是否越界。把一份可信的凭据交给Agent，和让最终系统真正执行限制，是两回事。

02工具声明了边界，底层真的守住了吗？

授权体系设计得再完整，也要落在可靠的执行层上。否则管理界面上写着“只能更新工作流”，底层程序却可能被带去做更多事。

MCP（Model Context Protocol）是Agent连接外部工具和上下文的一种协议。Tool Schema告诉客户端“这个工具叫什么、接受什么参数”，但它不是自动生效的操作系统权限边界。

GitHub在10月14日公开的Agentic Workflows（gh-aw）安全公告，正好是一个具体例子。部分MCP Handler把客户端传入的字符串直接追加到底层CLI的参数列表，没有用--标出选项结束，普通输入因此可能被解析成工具定义里没有公开的命令选项；同一公告还涉及一个路径问题，可以写到预期的.github/workflows/目录之外。公告把这组问题评为严重（CVSS v4.0 9.2）。⁠³

这里是命令行选项注入，不是Shell注入。攻击前提是一个已经连上相关MCP接口的低信任客户端，公告也把遭到提示注入的AI Agent列为可能的调用方；不能说成任意互联网用户可以直接接管GitHub。修复已包含在10月14日发布的v0.91.12中，公告发布时该版本标记为预发布版。⁠³

对平台工程师来说，这里有两次独立的检查。第一次判断“这个调用者有没有权请求这个操作”；第二次确认“实际执行的程序是否只能做获准的操作”。前者替代不了后者。

工具背后是CLI、浏览器或通用Shell时尤其如此：一条看起来简单的调用，可能跨过好几个权限域。要限制的不只是目的地，还有参数、文件范围、凭证的使用方式和可能触发的副作用。

网关、Sandbox和业务应用，各守一道门

网关可以验证身份、检查工具请求、实施流量策略；Sandbox约束进程能读哪些文件、用哪些系统能力；最终的业务应用仍然要做自己的授权判断。

这几道门不能互相替代。Agent绕开MCP、改用本地CLI时，网关可能根本看不到；只隔离本地进程，也挡不住一份合法的云凭证被拿去做越界的SaaS操作。

MCP官方的安全最佳实践文档（目前位于草案文档目录）专门讨论了令牌透传、SSRF、状态句柄劫持和最小权限范围等问题。连接成功、协议兼容，和授权完整是三件不同的事。⁠⁶

回到报销Agent：如果它能绕开工具网关，直接用环境里的财务API Key，那么“付款账户修改被阻断”只是某一条路径上的结论。企业真正要验证的是：所有可达的执行路径，是否守着同一份任务边界。

IAM没有过时，缺的是任务这一层上下文

传统身份体系并非只能做静态角色控制。现代IAM早已能按用户、设备、位置和风险等条件作访问判断。⁠⁷Agent带来的新难点，是把任务、委派、子Agent和工具动作一起纳入持续的执行过程。这是在成熟控制之上往前延伸，用不着推倒重来。

从以账号和应用为中心，到以任务、委派与执行链为中心。

示意图简化了传统部署场景，不表示现代IAM只有静态权限；条件访问、特权管理和持续评估等既有能力，仍是Agent Security的基础。

03可以让Agent执行，但不能只听它宣布成功

还有一道边界，出现在任务完成之后。

报销Agent说“账户没有被修改”，最好有业务系统的记录支撑；Coding Agent说“漏洞修好了”，也不能只拿它自己的解释当结论。

Snyk是应用安全和软件供应链安全厂商。它在10月15日推出的Evo Agentic AppSec，把发现、修复和独立验证组织成一条连续的流程：几个安全Agent负责发现和修复，Snyk已有的确定性分析引擎作为工具被它们调用；Continuous Offensive Security对运行中的应用发起攻击，充当“独立裁判”，确认修复是否真的生效；可能破坏构建的修复会先排队等待审批，而不是直接合并。⁠⁴

这些组件处在不同阶段：Code Scanning Agent、Dependency Firewall和Agentic Security Review以实验性预览向部分客户提供，Remediation Agent为公开预览，Continuous Offensive Security则从8月起已正式提供。不能把它们混写成“整套能力都已普遍可用”。⁠⁴

修复需要独立验证，验证本身也有范围

在参考开发流程里，Coding Agent可以提出补丁、更新依赖、跑基础测试；独立的验证流程负责检查原有攻击路径是否关闭，必要时再由有发布权限的人批准合并。

不过，“再让另一个Agent看一遍”不一定构成独立验证。如果双方带着同样的错误假设、缺着同样的上下文，或者执行者能改动验证规则，它们仍可能一起漏掉问题。

更可靠的设计要有受控的测试环境、执行者改不了的验证条件、可复现的记录，以及实际的资源状态。即使同一条攻击路径在修复后没有复现，也只能支持“这个版本、这个环境、这个测试范围”内的结论，推不出“应用已经没有漏洞”。

进攻型Agent也要做同样的区分。自主攻击验证（Autonomous Attack Validation）主要验证授权资产上的攻击路径、修复和复测；进攻性网络行动（Offensive Cyber Operations）则围绕一项任务的目标、行动规则（ROE）、操作员审批和有边界的持续执行展开。前者不会因此自动获得后者的行动授权。

安全团队要一起维护的，是这条链

IAM、IGA与PAM团队要把负责人、任务发起者、Agent、子Agent和下游身份关联起来，并说清权限回收会影响哪些长期任务。授权既要发得出去，也要收得回来。

SOC团队要把行为异常转成范围合适的响应：暂停某个Agent的写入，和禁用整个员工账号，业务影响完全不同。检测之后，还要确认限制确实在执行点生效，而不只是记下一条“已调用撤销接口”。

AppSec与红队要定义测试覆盖、资产范围、停止条件和复测方法。自动化程度越高，越要分清“没发现问题”和“证明某个风险已经关闭”。

Agent平台团队要提供稳定的任务标识、委派记录、凭证使用记录和结果关联。策略、审批和审计，不能完全由被约束的Agent自己掌控。

Key Takeaways

1. 授权跟着任务走，不停在起点。任务意图只是授权的输入；风险变化时，系统应能收紧写入、暂停或要求重新审批，而不必让整条业务一起停摆。

2. 委派要说得清来源，也要收得回来。审计记录要区分负责人、发起者、授予方和执行实例；验收时，直接测量从发出撤销到目标系统拒绝下一次访问的时间。

3. Tool Schema不是权限边界，每条执行路径都要守住。网关、Sandbox和业务应用各守一道门；原MCP路径、直接API和子Agent路径，都要受同一份任务边界约束。

4. “修好了”要由独立证据确认。用执行者改不了的验证条件和资源侧结果来核对，并写清这个结论只覆盖哪个版本、哪个环境、哪个测试范围。

资料与延伸阅读

内容时间点：2026年10月20日。业务场景、具体策略和验收方法属于参考设计；厂商能力以所引资料和实际版本为准。配图用于帮助理解，不证明产品已完成集成或实施效果。