AADP 出现之后：AGENT 安全开始把"能做"和"该做"真正分开

权限体系解决了一个问题，Agent 带来了另一个

过去几十年，计算机安全大体建立在一个稳定的基本问题之上：谁可以访问什么。Identity 回答你是谁，Authentication 确认这个身份为真，Authorization 决定这个身份拥有哪些权限，IAM、RBAC、ABAC、OAuth、API Token 与 Cloud IAM 则把这套原则逐步变成了现代软件基础设施的默认结构。即使后来出现 Zero Trust，本质上也仍然是在不断收缩信任半径，让每一次访问接受更严格的验证。这套体系成熟、有效，直到今天依然重要。

但当 AI Agent 真正进入业务流程之后，一个长期被权限体系掩盖的问题开始暴露出来：一个主体拥有某项能力，并不意味着它此刻产生的每一个具体动作都应该被执行。这两件事过去几乎可以等同，现在却正在迅速分开。最近几周的一系列动作显示，这已经不再只是一个理论判断——安全行业似乎正在同时意识到，Agent 带来的变化并不是系统里多了一种新的 Identity，而是系统里出现了一种能够持续产生 Action 的主体。当 Action 本身成为风险单位，安全体系就必须重新寻找自己的控制点。

一份 Internet-Draft 选择的问题

2026 年 8 月，一份名为 Agent Action Decision Protocol（AADP）的 Internet-Draft 出现；9 月 1 日更新到 draft-saha-aadp-02。需要先说明它的位置：这仍然只是一份个人提交的 Internet-Draft，既不代表 IETF 已经接受，也不构成任何形式的背书。Internet-Draft 本来就是进行中的技术提案，可能被修改、替换，甚至最终消失。

值得关注的并不是它当前的标准地位，而是它选择处理的问题。AADP 一开头就把 Agent Security 里两个经常被混在一起的概念拆开：一个是 standing capability，即 Agent 是谁、持有什么 Credential、能够访问哪些 Tool；另一个是 per-action authorization，即这个 Agent 此刻提出的这一个具体 Action，带着这一组具体参数，在当前状态下究竟能不能执行。它对后者的论证相当直接：静态的 Permission 或 Access Grant 很难表达累计预算、仍在占用的 Reservation、Approval 的生命周期、Kill Switch 状态以及此前已经发生过什么，因此真正的授权决策必须发生在动作被提出的那一刻。这意味着 Per-Action Authorization 已经从个别安全产品的功能设计，开始进入协议层的讨论范围。过去我们给一个主体"权限"，现在有人开始试图给一个动作"许可"。

同一个 Credential，两个完全不同的动作

设想一个最简单的 Agent：它持有支付 API 的 Credential，也被允许调用 transfer()。从传统权限体系看，问题基本已经关闭——身份合法、Token 有效、Scope 正确、目标资源可访问。但它提出的两次调用可能完全不同：一次是向已确认的供应商支付 100 美元，另一次是凌晨三点向一个首次出现的账户支付 10 万美元。对 Access Control 而言，这两次几乎无法区分：同一个 Agent、同一个 API、同一个 Scope、同一个 Credential；而在现实世界里，它们显然不是同一件事。

这正是 Agent 开始动摇传统 Authorization 模型的原因。LLM 让软件从相对确定的程序路径，变成能够根据上下文动态生成下一步动作的主体。需要控制的因此不再只是它能够调用什么，还包括它准备怎么调用、携带什么参数、在什么状态下调用，以及此前已经做过什么。安全问题也随之从"你是谁、你被允许访问什么"，逐渐移向"此刻这一个动作是否应该发生"。AADP 的取舍就落在这里：它并没有试图重新发明 Identity，而是明确承认 Identity Layer 与 Action Decision Layer 是两个不同层次的问题。Token 可以证明你是谁、能够到达哪里，却无法充分回答这一刻这一个 Action 是否应该被允许。

授权正在变成一次运行时计算

AADP 更有意思的一点，是它没有把 Action Authorization 做成一次简单的 Policy Check，而是把 Authorization 当成有状态的。一个动作现在能不能执行，除了 Policy 之外，还可能取决于今天已经消耗掉多少预算、有没有尚未释放的 Reservation、之前的 Approval 是否已经过期、Kill Switch 是否刚刚被开启，以及相同的 Action 此前是否已经执行过一次。换句话说，Authorization 正在从"读取权限"变成"根据当前状态计算这一动作能否发生"的 Runtime Computation。

为此，AADP 定义了 PDP（Policy Decision Point）负责产生 Verdict，定义 PEP（Policy Enforcement Point）位于动作真正发生的位置，没有 Permit 就不得执行受控 Action；同时给出了一批相当接近现实执行语义的原则：未知 Action 默认拒绝，Kill Switch 必须优先于普通 Policy，不可逆 Action 不能直接自动执行，Budget Reservation 必须原子化，Undo 本身也是一个需要重新接受治理的 Action，而经过 Approval 恢复执行时还必须重新评估当前状态——因为审批完成的那一刻，世界可能已经不是提交审批时的那个世界。连 Evidence 也不再是传统意义上的 Audit Log：它要求记录 Request、Verdict、Reason、Tier、时间与执行结果，并保留足以重建当时决策所依据的 Authorization State。如果 Policy 后来发生变化，仅仅记下一句"当时允许了"，并不能说明当时为什么应该允许。这里已经触及一个重要的判断：安全不只需要证明谁拥有权力，还需要证明一次权力为什么在那个时刻被允许转化为现实。

Fail Closed 正在获得新的意义

另一个值得注意的变化，是 AADP 对失败的处理方式。当输入缺失、格式错误或必要条件无法满足时，它要求产生明确的 Deny；未知 Obligation 不能被静默忽略；当 PEP 无法联系到 PDP 时，推荐行为同样是不执行受治理 Action，而不是默认放行。这看上去只是工程细节，实际反映的是一种不同的信任模型。

在普通互联网系统里，很多失败意味着"服务暂时不可用"，代价是可用性；而在执行型系统里，某些失败必须意味着现实状态保持不变。当一个动作意味着转账、删除资源、修改生产环境、下达交易或控制设备之后，"不知道"就不能再被解释成"大概没问题"。Unknown、Missing、Expired、Conflict 这些状态，本身就应当被视为无法建立执行依据的状态——无法证明可以执行，就意味着不能执行。这是软件从"处理信息"走向"改变现实"之后，一次并不轻的认知调整。

几乎在同一时间窗口，多个团队走向同一个方向

如果 AADP 是孤立的，它的意义会有限得多。真正值得注意的是，几乎在同一个时间窗口内，背景完全不同的几支团队都在朝相似的方向移动。8 月 31 日，Broadcom 发布 AgentMinder，其官方定义已经不再停留在管理 Agent Identity，而是要在 Action 到达企业资源之前，依据 Agent 的 Mission、Intent、Context 与当前风险独立验证并授权每一个动作。9 月 1 日，OWASP GenAI Security Project 发布 Agent Control Standard，关注点也从模型输入输出转向要求 Agent Platform 暴露 Middleware Hooks，使安全策略能够在 Runtime 直接执行，让 Agent 的实际行为可被观察、追踪与控制。9 月 2 日，MuleSoft 的 Agent Kill Switch 正式 GA，控制粒度已经下沉到 Request、Session、Agent Instance 与 Tenant——当 Agent 因 Prompt Injection、Loop 或其他异常进入错误执行路径时，可以直接停掉那个正在运行的 Agent，而不必关闭整套 Runtime。

这些并不是同一类东西，解决的问题也不完全重合，把它们并排放在一起也不构成任何"标准已经形成"的结论。但共同点足够明显：Identity 不再被认为足够，静态 Permission 不再被认为足够，Prompt 层的 Guardrail 同样不再被认为足够，控制点正在向 Runtime、Action 与 Execution 本身移动。与其说是某个厂商发明了一个新词，不如说这更像是架构层面的一次集体重估——不同团队在独立地抵达越来越接近的结论，这种同步通常比任何单一发布更值得注意。

决策之后，还有一道边界

让这份 Draft 更有价值的，是它没有假装自己解决了所有问题。AADP 在 Security Considerations 中明确写出了自己的 Trust Boundary：如果一个 PEP 本身能够绕过 PDP 直接调用受治理 Capability，这条路径就不在协议的保护范围之内；同样，如果真正负责执行动作的那一层已经失陷，或者系统中仍然存在一条不经过 Authorization Decision 的通路，协议本身无法阻止那个动作发生。这不该被读成缺陷，恰恰相反，一个成熟协议最重要的品质之一，就是清楚说明自己的安全保证在哪里结束。

而这条边界自然把问题继续往前推了一层：如果 Decision 是正确的，谁保证这个 Decision 真正约束了 Execution？如果 PEP 可以绕过 PDP，如果调用外部 Capability 的执行路径已经被攻破，如果一个系统既负责生成 Policy、又负责计算 Decision、还同时拥有直接改变现实状态的能力，它的 Trust Boundary 究竟落在哪里？这条链条因此变得清晰：Identity 解决主体，Capability 解决可达范围，Per-Action Authorization 解决这一动作在当前状态下是否应该被允许，PEP 负责把 Decision 转化为 Enforcement——而只要最终能够改变现实的 Executor 仍然可以绕过、修改或忽略这个 Decision，系统里就还剩下一个没有被解决的问题。

Authorization ≠ Execution Authority.

授权意味着系统已经产生了"允许执行"的判断；Execution Authority 回答的却是另一个问题：谁最终拥有让这件事真正发生的能力。Decision 如何变成不可绕过的 Enforcement，目前还没有哪一层给出完整答案。

控制点正在不断向后移动

过去安全体系的大部分努力集中在主体进入系统之前：识别身份、发放凭据、限定权限、控制资源访问。Agent 时代正在迫使控制点持续后移——从 Identity 到 Capability，从 Capability 到具体 Action，从 Action 到 Runtime Decision，从 Decision 到 Enforcement，并最终指向那个真正改变现实状态的位置。原因并不神秘：AI 带来的最大变化不在于它会"思考"，而在于越来越多系统开始允许它依据自己的推理连续产生真实动作。一旦软件能够行动，安全就很难继续只围绕"它拥有什么权限"来设计。

今天还不能说 AADP 会成为标准，也不能说任何一家厂商已经找到了 Agent Security 的答案，这甚至不是最要紧的部分。要紧的是不同团队正在独立抵达越来越接近的判断：Agent 不能只靠 Identity 管理，不能只靠静态 Permission 管理，也不能只靠 Prompt Guardrail 管理。当它开始调用工具、操作账户、修改数据、触发工作流乃至直接影响物理世界时，控制必须越来越贴近 Action，并最终贴近 Execution。安全行业花了几十年回答 Who is allowed；AI Agent 正在迫使它继续回答 What is allowed to happen；而当这个问题抵达现实世界，还会剩下最后一问：Who can actually make it happen。Agent Security 的重心，正在从控制谁拥有权限，转向控制哪些动作能够成为现实。