现代安全体系很大程度上建立在权限之上：谁可以登录，谁可以读取，谁可以修改，谁可以删除，谁可以调用某个 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 已经能考虑 Context，Execution 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——这个主体这一次是为了什么任务获得这些能力，任务边界是什么，允许操作哪些对象，允许达到什么状态，允许在多长时间内执行，可以执行多少次，需要哪些前置 Evidence，Mission 完成之后授权是否自动失效。

这会把权限从一种相对静态的关系，变成任务上下文中的临时现实能力。

Agent 不应该因为"它是谁"长期拥有一切，而应该因为"它现在正在完成什么任务"临时获得明确能力。

十三、要验证的不是"它有没有权限"，而是"这次权限有没有被正确消费"

未来 Agent Security 里可能会出现一个重要概念：Permission Consumption——一份长期权限究竟如何被具体任务使用。

Agent 有 transfer 权限，但这次 transfer 基于哪个 Intent，由谁授权，允许金额多少，允许对象是谁，是否只能执行一次，是否已经消费过，是否需要后续 Evidence，执行完成后能否证明这次 Capability Usage 与原始 Mission 一致。这比单纯看 permission = transfer 复杂得多，却更接近现实风险。

权限存在并不是问题，权限如何被一次具体行动消费，才决定现实。

十四、EVIDENCE 是权限系统与执行控制之间的桥梁

如果执行层不能只相信"Agent 有权限"，它需要 Evidence：主体是谁，Permission 是否存在，Intent 是什么，任务是什么，对象是什么，当前 State 是什么，审批状态是否有效，边界是什么，前序步骤是否已经完成。这些 Evidence 让最终执行不再依赖"上游说已经检查过"，而是下游可以自己验证。

传统权限体系很大程度上只输出 Permit / Deny，Execution 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 仍要明确，但在最终执行之前，系统还会再问一次——这一次，凭什么发生？因为对一个不完美主体来说，"我有权限"永远只能证明我可以，而不能自动证明我现在应该。