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

本文来自微信公众号： HavenlonLabs ，作者：Havenlon Labs

权限体系解决了一个问题，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的重心，正在从控制谁拥有权限，转向控制哪些动作能够成为现实。