现代安全体系很大程度上建立在权限之上谁可以登录谁可以读取谁可以修改谁可以删除谁可以调用某个 API谁可以操作生产环境。围绕这些问题行业已经形成了一整套成熟机制——IAM、RBAC、ABAC、PAM、OAuth、Policy Engine、Least Privilege、Zero Trust。它们解决的是互联网时代最核心的一类问题不要让错误的主体获得不该拥有的能力。AI Agent 暴露的是另一个问题即使主体是对的Credential 是对的Role 是对的Policy 也是对的最后发生的动作依然可能是错的。这不是因为 IAM 失败了恰恰相反IAM 可能工作得完全正确。问题在于我们开始要求权限系统回答一个它从未真正负责过的问题——这个主体能不能做和这件事现在应不应该做从来不是同一个问题。权限决定能力的边界执行控制决定现实的边界。一、IAM 最擅长回答的是你是谁IAM 的核心价值首先在于建立 Identity谁在访问身份是否真实来自哪里通过什么方式认证属于哪个组织Session 是否有效是否启用 MFA设备是否合规。这一层解决的是最基础的问题没有身份后面的授权无从谈起。它可以阻止匿名主体进入敏感系统降低 Account Takeover 风险让企业准确知道哪个用户、服务账户或 Workload 正在调用资源。但 Identity 只能证明请求来自谁不能自动证明这个人或 Agent 此刻为什么要这样做。身份是真实的不代表意图是真实的身份没有被盗也不代表主体没有理解错误。Authentication 可以证明是你却不能证明这件事就是你此刻真正想让它发生的事。二、RBAC 解决的是你的角色允许你做什么身份之后最典型的授权机制是 RBAC管理员、财务、开发者、审计员、客服每种角色对应一组 Permission。企业不需要逐个定义每个人能做什么只要把角色与能力绑定效率很高逻辑在多数场景下也很合理。但 RBAC 天然是相对粗粒度的它主要表达这个角色通常可以做这类事情不负责理解这一次为什么要做、这个具体对象是不是任务要求的对象、当前状态是否仍然成立、用户的真实 Intent 是否已经变化。客服拥有退款权限RBAC 可以允许refund但它未必判断得出这笔订单现在到底该不该退、金额是否对应当前 Intent、客户是不是正确对象、是否已经退过一次。RBAC 解决的是 Role-to-Capability Mapping而不是 Action-to-Intent Consistency。Role 可以告诉系统这个人通常能做什么却不能告诉系统这一次具体为什么应该做。三、ABAC 更聪明但它首先仍然是在做授权ABAC 比 RBAC 更细可以依据用户属性、资源属性、环境属性、时间、位置、设备状态、风险等级和请求上下文做判断。例如只有财务部门用户、在公司设备上、工作时间内、访问指定账户、金额低于某阈值时才允许付款。这显然比简单的 RBAC 强很多能表达更复杂的动态条件。于是有人会问既然 ABAC 已经能考虑 ContextExecution Control 还有什么不同差别不在于 ABAC 能不能表达复杂规则而在于它的核心语义通常仍是 Permit or Deny Access——在当前属性集合下主体能否对某资源执行某类操作。而不完美主体会继续追问这些 Attribute 从哪里来是不是当前的真实状态有没有与原始 Intent 绑定Action 参数在链路中有没有改变前序审批是否仍然对应当前对象任务是否已经过期如果上下文来源本身被污染怎么办如果当前状态是 Agent 自己提供的又怎么办。ABAC 可以让授权更动态却不能天然保证整个 Intent → Execution 因果链没有发生漂移。ABAC 可以成为 Execution Control 的重要组成部分但它不等于完整的 Execution Control。四、权限回答的是 CAPABILITY不是 PURPOSE权限系统本质上在管理能力有没有read、write、delete、transfer、deploy。但现实行动还有另一个维度——Purpose为什么做为了哪个任务服务于哪个 Mission当前动作是否仍属于那个目的。同一个 Capability 在不同 Purpose 下含义完全不同。transfer 1000 USDT可能是供应商付款可能是客户退款也可能是测试交易从权限角度看它们都只是transfer从现实意义看它们根本不是一件事。权限模型擅长定义你有没有能力转却未必理解为什么现在应该转。Capability 没有目的Purpose 才决定一次能力使用是否仍然符合原始任务。这正是 Mission-Bound Authorization 越来越重要的原因未来的授权可能不只是给 Agent 一组能力而是把能力绑定到具体 Mission。五、LEAST PRIVILEGE 也无法自动解决正确权限下的错误行为主体只获得完成任务所必需的最小权限这是安全工程最重要的原则之一。它能显著降低攻击面Credential 泄露、账户被接管、程序失陷时攻击者能做的事情都受到限制。但不完美主体带来的问题更微妙——一个主体完全可能在最小权限范围内犯错。退款 Agent 只有退款权限很合理但它仍可能退错客户部署 Agent 只有 Deployment 权限也合理但它仍可能部署错误版本交易 Agent 只有交易能力同样合理但它仍可能发出一笔错误交易。Least Privilege 控制的是 Maximum Capability没有完全控制 Correct Use of Capability。所以 Agent 安全不能停在把权限再缩小一点很多时候权限已经无法再缩——再缩Agent 就完不成任务。需要加入的是另一个维度Capability 可以存在但只能在明确的执行条件下被消费。最小权限限制的是主体最多能做什么执行控制限制的是这一次能力到底能不能被使用。六、PERMISSION 是持续状态INTENT 却往往是短暂状态权限通常具有持续性一个角色可能存在数年一个 OAuth Scope 有效几小时一个 Service Account 的权限可能长期存在一个管理员的生产权限可能持续数月。这是必要的设计否则每执行一个动作都重建权限系统成本会极高。Intent 则往往是瞬时的。用户今天允许给供应商 A 支付 5000不代表明天也允许允许处理订单 X不代表可以处理订单 Y允许 Agent 在当前任务里执行三次操作不代表这个额度可以被另一个任务继续消费。Permission 与 Intent 的生命周期天然不同如果系统只依赖长期 Permission就很容易出现合法权限被用于已经超出原始 Intent 的动作。危险的不是权限错误而是长期 Capability 被短期任务无限复用。一个长期存在的权限不应该自动继承每一次临时意图的合法性。因此 Agent 时代需要越来越多 Task-Scoped、Mission-Bound、Intent-Bound 的授权结构。七、AGENT 让有权限和使用权限之间的距离几乎消失在人类系统里权限本身不会主动行动。管理员拥有 Root不意味着 Root 会自己使用——人需要接到任务、理解任务、登录、输入命令、确认然后执行Capability 与 Execution 之间天然存在一段认知距离。Agent 改变了这一点拿到任务后立刻理解、计划、选 Tool、调用、执行。于是 Permission 不再只是静态能力它变成了 Machine-Consumable Capability——只要 Agent 做出判断这个能力马上就会被使用。权限系统此前并不需要承担持续理解主体为什么使用权限的责任而当两者之间的时间被压缩到毫秒级Permission 就很容易直接转化成 Execution。当权限可以被机器连续、高速、自动消费时权限本身就开始接近执行权。Tool Permission 很重要但 Tool Permission 不等于 Final Execution Authority。八、IAM 可以阻止陌生人却挡不住合法主体误解任务设想一个做得相当好的企业系统MFA、Zero Trust、设备认证、最小权限、短生命周期 Token、完整审计没有 Credential 泄露没有异常登录没有 Privilege Escalation。然后一个合法 Agent 收到指令把已经确认的供应商付款处理掉。它在读取数据时把 Pending Review 理解成了 Approved于是调用支付接口。IAM 看到主体合法通过RBAC 看到该 Agent 有支付权限通过ABAC 看到金额在范围内、设备正常、时间正常通过OAuth Token 有效API Scope 正确通过。整个安全体系都工作正常钱转错了。这不是 IAM 的失败因为 IAM 从未承诺理解 Pending Review 是不是当前 Mission 所要求的业务状态。有时候问题不是安全控制失效而是我们让一种控制承担了超出其设计边界的责任。Execution Control 不应以否定 IAM 为前提它依赖 IAM只是继续往后走一步。九、POLICY 已经 ALLOW不代表最终执行必须发生现代系统越来越依赖 Policy Engine请求进来Policy 评估返回 ALLOW操作继续。结构很清晰但不完美主体模型会追问Policy 到底评估了什么输入由谁提供什么时候评估执行时条件有没有变化如果 Agent 改了 Action 参数怎么办如果判断时 Object 是 A、执行时已经变成 B 怎么办如果授权是十分钟前完成而当前 State 已经改变呢。这说明 Policy Decision 与 Execution 之间仍然存在缝隙。Policy 说的是在我看到的条件下这个动作是允许的Executor 仍需确认我现在真正要执行的动作还是不是刚才那个动作。Policy 是重要的判断来源但进入现实之前还需要 Runtime Verification。这也是 Execution Control 与普通 Policy Control 的核心区别Policy ≠ Final Authority。十、权限关心主体—资源执行控制必须关心行动—现实传统 Access Control 通常抽象成 Subject → Action → Resource某个主体能不能对某个资源执行某种操作。这是一个很强的模型但 Agent 的现实执行需要更多维度WHO、WHAT、OBJECT、STATE、PROOF、BOUNDARY、MISSION、TIME。需要验证的不再只是主体能否对资源执行操作还包括这个 Action 是否仍属于原始任务对象是否还是原对象当前状态是否仍满足条件必要 Evidence 是否存在是否已经超出边界或过期是否出现冲突。Execution Control 关注的是 Action-to-Reality Transition。Access Control 保护的是谁能碰什么Execution Control 保护的是什么最终能够发生。两者不是竞争关系而是前后关系。十一、为什么权限正确仍然可能越界这里的越界不一定是权限越界也可能是 Mission 越界、Intent 越界、Object 越界、State 越界、Parameter 越界或 Time 越界。一个 Agent 被允许管理客户 A 的资产它确实拥有 Asset Management Permission但某次请求误操作了客户 B如果没有 Object Binding权限系统看到它有相应权限就可能继续放行。再比如一个 Agent 在某次任务中被允许转账不超过 1000 美元它本身拥有 Payment API 权限如果系统只检查 API Scope就判断不出某次 5000 美元的操作已经超出 Mission Boundary。Permission Boundary 和 Execution Boundary 并不是同一条边界。权限可以完全正确执行仍然可能越界——这正是 Agent 风险最容易让传统安全感到不对劲的地方。十二、从 SUBJECT-BOUND 走向 MISSION-BOUND传统授权围绕主体展开Alice 可以做什么Service Account 可以做什么Agent A 可以调用哪些 Tool这是 Subject-Bound Authorization。自主系统还需要加入 Mission-Bound Authorization——这个主体这一次是为了什么任务获得这些能力任务边界是什么允许操作哪些对象允许达到什么状态允许在多长时间内执行可以执行多少次需要哪些前置 EvidenceMission 完成之后授权是否自动失效。这会把权限从一种相对静态的关系变成任务上下文中的临时现实能力。Agent 不应该因为它是谁长期拥有一切而应该因为它现在正在完成什么任务临时获得明确能力。十三、要验证的不是它有没有权限而是这次权限有没有被正确消费未来 Agent Security 里可能会出现一个重要概念Permission Consumption——一份长期权限究竟如何被具体任务使用。Agent 有transfer权限但这次transfer基于哪个 Intent由谁授权允许金额多少允许对象是谁是否只能执行一次是否已经消费过是否需要后续 Evidence执行完成后能否证明这次 Capability Usage 与原始 Mission 一致。这比单纯看permission transfer复杂得多却更接近现实风险。权限存在并不是问题权限如何被一次具体行动消费才决定现实。十四、EVIDENCE 是权限系统与执行控制之间的桥梁如果执行层不能只相信Agent 有权限它需要 Evidence主体是谁Permission 是否存在Intent 是什么任务是什么对象是什么当前 State 是什么审批状态是否有效边界是什么前序步骤是否已经完成。这些 Evidence 让最终执行不再依赖上游说已经检查过而是下游可以自己验证。传统权限体系很大程度上只输出 Permit / DenyExecution Control 还需要保留 Why Permit并且让这个理由能够跟随 Action 一路抵达最终执行点。一个 Allow 如果无法携带自己的理由就很容易在离开 Policy Engine 以后失去原始语义。这也是 Post-Execution Proof 和 Evidence Chain 重要的原因不仅要证明执行了什么还要证明它为什么被允许执行。十五、EXECUTION CONTROL 不是新 IAM而是 IAM 之后的下一层把整条链拉开来看IAM 回答你是谁Authorization 回答你能做什么Policy 回答在这些条件下是否允许Execution Control 回答现在这一次具体行动是否仍然满足全部执行条件Evidence 回答它为什么被允许以及最后到底发生了什么。这几层不是互相替代而是逐步接近现实。Execution Control 不是要发明一个更高级的 IAM也不是说传统权限体系过时了。恰恰相反没有 IAM它连 WHO 都无法验证没有 Authorization它无法知道 Capability 是否存在没有 Policy它无法知道业务边界没有 Evidence它无法建立因果链。它补上的是从 Policy Decision 到 Reality Change 之间的最后一道结构。IAM 决定谁进入能力世界Execution Control 决定哪些能力最终可以进入现实世界。十六、权限体系为什么必须继续向执行延伸在人类时代权限体系之所以能长期承担这么大的责任是因为人一直在补上最后那层判断权限说你可以人再自己判断我要不要。AI Agent 时代这两个动作开始合并——权限说你可以Agent 判断我要系统立即执行。过去隐藏在人类认知里的应不应该就此消失。所以 Agent 安全必须把这个问题重新工程化不能再假设有权限的主体会自己正确判断何时使用权限而要把 Mission、Intent、State、Proof、Boundary 重新放回执行路径。AI Agent 改变的不是权限模型失效而是过去由人默默承担的最后判断开始需要被系统正式接管。十七、能不能和应不应该必须同时存在未来的安全体系不需要在两者之间二选一。只问应不应该而不做 Identity 和 Permission会失去最基本的访问控制只问能不能然后把合法能力直接交给不完美主体同样危险。完整的结构必须同时回答 Can this subject do it 与 Should this action happen now——前者是 Capability Eligibility后者是 Execution Eligibility两者同时成立执行才应该进入现实。这形成一种清晰的两层逻辑第一层判断主体有没有资格提出这种 Action第二层判断这次 Action 有没有资格成为 Reality。主体获得能力是授权问题能力获得现实效力是执行问题。十八、权限的终点不应该自动等于执行这个系列一直在拆解一些被默认的等式合法主体不等于正确主体合法行为不等于正确行为善意主体不等于安全主体能力更强不等于自动更安全Decision 不等于 Execution。这一篇要再拆一个Permission ≠ Final Execution Authority。IAM 没有错RBAC 没有错ABAC 没有错Least Privilege 也没有错。问题在于我们不能因为这些系统都返回了正确结果就默认现实一定应该随之发生——它们解决的主要是能不能而现实还需要回答应不应该。这个应不应该不是道德判断也不要求系统拥有哲学能力它完全可以非常工程化Mission 是否匹配Object 是否匹配State 是否成立Proof 是否完整Boundary 是否满足Action 是否仍与原始 Intent 一致。这些条件可以被定义、被验证、被拒绝而这正是 Execution Control 开始发挥作用的地方。成熟的 Agent Security 不会抛弃 IAM它会站在 IAM 之上继续向前身份仍要验证权限仍要最小化Policy 仍要明确但在最终执行之前系统还会再问一次——这一次凭什么发生因为对一个不完美主体来说我有权限永远只能证明我可以而不能自动证明我现在应该。