对抗性完整与零信任，真正的区别在哪里？

Zero Trust 与对抗性完整都从“不应默认信任任何主体”出发，因此它们很容易被混在一起。

尤其是在 AI Agent、机器身份、持续授权和高风险自动化逐渐成为现实以后，很多安全体系都开始强调动态认证、最小权限、持续策略判断，这会让人产生一种直觉：只要 Zero Trust 做得足够彻底，执行安全问题似乎也应该随之得到解决。

但两者实际上处理的是两个不同层次的问题。

Zero Trust 解决的是：

一个主体在当前上下文中，是否应该获得访问某项资源或能力的资格。

对抗性完整进一步处理的是：

即使这个主体已经合法获得能力，甚至已经失陷，它是否仍然能够独立推动一个受保护动作真正发生。

因此，两者的真正差异并不在于谁“更不信任”，而在于它们控制的对象不同、安全模型不同，最终需要证明的东西也不同。

一、Zero Trust 控制访问资格，对抗性完整控制执行资格

Zero Trust 的基本模型仍然建立在主体与资源之间的访问关系上。

一个典型过程是：

主体身份 → 身份认证 → 设备与上下文验证 → 权限判断 → 资源访问

系统最终回答的是：

当前这个主体，是否有资格访问这个资源？

这种模型非常适合保护数据库、内部系统、API、云资源和企业应用，因为这些场景中最直接的安全风险就是：一个原本不应该访问资源的主体获得了访问能力。

但当 AI Agent 开始进入支付、交易、生产环境变更、云基础设施操作和现实设备控制以后，访问已经不再等于最终结果。

例如，一个 Agent 已经合法拥有：

payments.execute

这只能说明它拥有调用支付能力的资格，却并不能回答：

• 它这一次应该转多少钱；

• 应该转给谁；

• 当前状态是否还允许转账；

• 审批对象与最终执行对象是否一致；

• 当天累计金额是否已经超出边界；

• 最终参数是否在执行前被修改。

因此，对抗性完整关注的对象不再只是：

Subject → Resource

而是一个完整执行结构：

Actor + Action + Target + State + Evidence + Boundary → Execution

这里安全系统最终判断的不是“你有没有调用这项能力的权限”，而是：

这一次具体动作，现在是否具备真正发生的完整条件。

所以，两者最基础的分界就是：

Zero Trust 控制谁可以获得能力；对抗性完整控制已经获得能力以后，什么动作可以真正发生。

传统安全架构最熟悉的一类风险，是一个本来没有权限的人通过凭证泄露、身份冒用、权限提升或者横向移动获得了不属于自己的访问能力。

因此 Zero Trust 的设计天然围绕这种风险展开：持续验证身份、动态评估设备状态、缩短信任周期、限制 Session，并通过 Least Privilege 尽可能缩小攻击者一旦获得某个身份以后能够触碰的范围。

但 AI Agent 引入了一类完全不同的失败模式。

一个 Agent 可能满足所有传统安全条件：

• Identity：Valid

• Credential：Valid

• Device：Valid

• Permission：Valid

• Session：Valid

• API Call：Authorized

然后仍然执行了一件错误的事情。

它可能因为上下文理解错误，把 10,000 美元解释成 100,000 美元；可能调用了正确的部署接口，却选择了错误的 Production Cluster；也可能在合法的云管理权限范围内删除了错误的实例。

这里并不存在传统意义上的 Unauthorized Access。

真正发生的是：

**Authorized Actor

• Authorized Capability

• Incorrect Action**

也就是：

Authorized but Undesirable Execution。

这一点很重要，因为在这种事故里，IAM 甚至可能从头到尾都是正确的。

它正确识别了 Agent。

正确判断了 Credential。

正确确认了 Permission。

也正确允许了 API 调用。

错误发生在另外一个层面：

“允许这个主体使用某项能力”，并不能推出“这一次具体执行是正确的”。

因此：

Zero Trust 防的是不该拥有能力的人获得能力；对抗性完整防的是已经拥有合法能力的主体把事情做错。

Zero Trust 最经典的原则是：

Never Trust, Always Verify.

它反对因为主体已经登录、设备来自企业网络、身份以前合法，或者过去行为正常，就持续给予默认信任。

因此 Zero Trust 的逻辑，本质上仍然是一种持续判断：

这个主体在当前时刻，是否仍然满足信任条件？

对抗性完整采用的是一个更强的安全假设。

它并不满足于继续问：

这个组件现在是否仍然可信？

而是直接进入：

假设它已经不可信，系统还能不能守住最终执行边界？

例如，一个高风险执行系统可以依次假设：

• Agent 已失陷

• SaaS 已失陷

• Policy Engine 已失陷

• Approval Service 已失陷

• Execution Gateway 已失陷

然后逐个分析：

这个失陷主体现在掌握的 Authority，是否足以让它绕过其他约束，独立构造出一条完整执行路径？

这和 Zero Trust 有一个非常细微但重要的区别。

Zero Trust 的一个重要目标，是降低“系统继续信任一个已经失陷主体”的概率。

而对抗性完整进一步要求：

即使系统没有及时发现这个主体已经失陷，它也不应该因此直接获得最终执行权。

所以，对抗性完整开始把问题从“组件是否安全”推进到“架构是否安全”。

一个组件可以失败。

一个主体可以失陷。

一个 Credential 可以泄露。

但系统仍然不应该因为某一个单点失败，就直接失去最终执行边界。

因此：

Zero Trust 尽量避免继续相信已经失陷的主体；对抗性完整进一步要求，即使主体已经失陷，也不能因此直接获得最终执行权。

Zero Trust 极大强化了 Identity 在现代安全架构中的地位。

现代安全系统会区分：

• Human Identity

• Machine Identity

• Service Account

• Workload Identity

• Agent Identity

然后围绕这些 Identity 配置：

Role → Permission → Policy → Resource

这一套模型非常成熟。

但当问题进入现实执行以后，仅仅知道“你是谁”已经不够了。

真正重要的问题开始变成：

你在整个执行过程中到底掌握了什么权力？

例如：

AI Agent 可能拥有提出动作的权力；

Policy Engine 拥有判断规则是否满足的权力；

Approval Service 拥有提供授权证明的权力；

Execution Gateway 拥有组合条件并放行执行请求的权力；

Executor 则可能掌握真正改变现实状态的能力。

于是一个完整执行过程可以理解为：

Agent 提出 Intent → Policy 判断 Boundary → Approval 提供授权证明 → Arbiter 组合多个条件 → Executor 改变现实状态

从 Identity 角度看，这些只是几个不同主体。

但从 Authority 角度看，它们掌握的是完全不同的因果能力。

因此，执行安全必须进一步回答：

• 谁能修改 Action？

• 谁能修改 Target？

• 谁能改变 Amount？

• 谁能签署 Approval？

• 谁能修改 Policy？

• 谁持有最终 Credential？

• 谁能够直接调用 External System？

• 哪个主体失陷以后能够独立完成整条执行链？

这就是 Authority Decomposition。

如果 Policy、Approval、Credential 和 Executor 虽然被拆成了四个服务，但最终都由同一个 SaaS Administrator 完全控制，那么表面看有四个组件，实际在 Authority 层仍然可能只有一个根权力中心。

一旦这个根 Authority 失陷，整个安全结构仍然可能同时失效。

因此，对抗性完整真正关心的不是“系统里有多少个 Identity”，而是：

最终执行权究竟被拆成了多少个真正独立的 Authority。

所以：

Zero Trust 识别“谁是你”；对抗性完整进一步识别“你究竟拥有多少让现实发生变化的权力”。

Least Privilege 是 Zero Trust 中非常重要的原则。

它要求一个主体只能获得完成任务所必须的最小权限。

例如一个支付 Agent 只需要：

payment.execute

那么就不应该再给它数据库管理员权限、系统运维权限或者其他无关能力。

但现实执行中有一个问题：

API Permission 的粒度，往往远远大于一次现实动作需要的粒度。

即使 payment.execute 已经是非常小的 IAM Permission，它背后的真实能力仍然可能是：

• 可以转 10 美元；

• 也可以转 100,000 美元；

• 可以转给 Account A；

• 也可以转给 Account B；

• 可以执行一次；

• 也可能连续执行几百次。

因此：

Least API Privilege ≠ Least Execution Authority

这是 AI Agent 时代非常重要的一个区别。

因为 Agent 并不是偶尔点击一次按钮，而是可能持续、高频、自动地产生现实动作。

所以，对抗性完整需要继续把执行权压缩。

例如一次执行资格可能被具体限制为：

Actor：Agent-AAction：TransferTarget：Account Group XAmount：≤ 10,000 USDDaily Total：≤ 50,000 USDApproval：ValidState：FreshExecution Window：09:00–18:00

这时候系统给予 Agent 的，就不再是一个宽泛的“支付能力”，而是一段高度限定的现实执行空间。

因此：

Zero Trust 缩小主体能够调用的能力集合；对抗性完整进一步缩小每一次现实动作能够真正改变的范围。

Zero Trust 的验证对象主要集中在主体与访问上下文。

它通常验证：

• 身份；

• Credential；

• Device Posture；

• Session；

• Network Context；

• Role；

• Permission。

这些信息足以回答：

当前这个请求者是否符合访问条件？

但现实执行需要证明的内容更多。

因为“谁发起请求”只是一次动作的一部分。

真正决定这件事情是否应该发生的，至少还包括：

• WHO：谁在参与

• WHAT：要执行什么动作

• OBJECT：动作作用于什么对象

• STATE：当前现实状态是什么

• PROOF：凭什么认为条件成立

• BOUNDARY：执行不能越过什么边界

例如：

Agent-A is authorized

只能说明 Agent A 拥有参与资格。

而如果要证明一笔真实执行有资格发生，需要的是一组完整关系：

Agent-A 请求 Transfer → Target 是 Account-B → Amount 是 5,000 USD → Authority-C 对同一对象给出了 Approval → 当前 State 仍然满足要求 → Amount、Time、Frequency 仍然处于 Policy Boundary 内

只有这些事实被绑定以后，系统才可以从：

主体合法

继续推导到：

动作合法

因此，对抗性完整里的 ALLOW 并不是来自某一个 Identity 或某一个 Permission，而是来自多个相互绑定的事实同时成立。

所以：

Zero Trust 证明请求者有资格参与；对抗性完整证明这一次具体执行本身具备完整资格。

Zero Trust 的典型安全关系是：

Subject → Resource

因此它本质上保护的是一条 Access Path。

但现实执行不是在获得访问权限的瞬间就完成的。

一次 AI Agent 执行通常经历的是：

Intent → Interpretation → Policy Evaluation → Approval → Parameter Construction → Execution → External State Change

这是一条完整的因果路径。

而且真正危险的问题可能发生在任何一个环节。

例如：

原始 Intent 是正确的；

Policy 判断也是正确的；

Approval 批准的对象也是正确的；

但在 Parameter Construction 阶段，最终 Target 被换掉了。

此时前面的 Authentication、Authorization 和 Approval 全部可能是真的，但最终动作仍然是错误的。

因此，执行安全必须验证的是一种语义连续性：

最终 Action 是否仍然是原始 Action？

最终 Target 是否仍然是被批准的 Target？

最终 Amount 是否仍然位于批准的 Boundary 内？

做出决策时使用的 State，在真正执行时是否仍然有效？

也就是说，安全对象从：

Access Path Security

进一步变成：

Causal Path Security

系统不能只证明：

Agent A 有资格访问执行接口。

还必须证明：

从最开始的 Intent 到最后真实发生的结果，中间没有任何一个 Authority 能够偷偷改变动作语义而不被发现。

因此：

Zero Trust 关注访问能力有没有被错误获得；对抗性完整关注从意图到现实改变之间，是否存在任何可以偷偷改变结果的因果路径。

从理论上看，这是两者最本质的区别之一。

Zero Trust 的一个重要贡献，就是系统性消除 Implicit Trust。

传统系统中，一个主体可能因为位于企业内网、使用企业设备，或者已经成功登录一次，就在后续流程中获得持续性的隐式信任。

Zero Trust 把这种关系拆掉，要求信任不断重新建立。

但执行系统里还存在另一种更隐蔽的问题：

Implicit Execution Authority。

例如：

因为 SaaS 是管理员，所以它可以修改 Policy。

因为 Policy Engine 返回 Allow，所以后续 Executor 可以直接执行。

因为 Agent 拥有合法 Credential，所以它可以自己构造最终参数。

因为 Executor 是“内部可信服务”，所以来自内部的命令默认可信。

这些设计未必是漏洞。

很多时候它们甚至是正常的软件工程结构。

但从 Authority 的角度看，它们都隐含着一个假设：

某一个组件天然拥有足够的权力，可以让最终动作发生。

对抗性完整要求把这些隐藏 Authority 全部显式化。

然后逐个分析：

• 这个 Authority 为什么存在？

• 它是否真的必须拥有这么大的能力？

• 它是否可以进一步拆分？

• 它是否能够被另一个独立 Authority 制约？

• 它失陷以后能否独立执行？

• 它能否关闭系统固定安全底线？

因此，对抗性完整不是简单地“再多做一次验证”。

它实际上是在重新审计整个系统里的权力结构。

所以：

Zero Trust 消除默认信任；对抗性完整进一步消除默认执行权。

当一个 Credential 或 Identity 被攻陷以后，传统 Zero Trust 分析最关心的通常是攻击面：

攻击者现在还能访问哪些资源？

可以横向移动到哪里？

当前 Role 还能调用什么 API？

如何进一步缩小其权限范围？

这些问题都非常重要。

但对抗性完整把问题推进到最终结果：

凭借当前已经失陷的 Authority，攻击者到底能够独立造成什么现实后果？

例如 Agent 被攻陷以后，如果它只能生成 Intent，而不能直接生成最终执行资格，那么 Agent 本身无法完成一次受保护执行。

SaaS 被攻陷以后，如果最终 Credential 位于独立执行边界中，而且执行边界仍然要求验证独立 Approval、Target Binding 和 State Evidence，那么 SaaS 也不能直接构造任意现实动作。

进一步，还需要分析组合失陷：

• Agent + SaaS

• Agent + Policy

• Policy + Approval

• SaaS + Approval

这样就形成一个 Compromise Matrix。

这个矩阵真正分析的不是：

我们有几层安全系统？

而是：

在定义好的 Threat Model 下，当哪些主体已经失陷时，系统仍然缺少哪些不可绕过的执行条件？

如果某一个组件一旦失陷，就能够从头到尾独立完成整个执行过程，那么无论系统外围有多少 Zero Trust、IAM、Logging 或 Policy，它在最终执行权上仍然存在单点风险。

因此，对抗性完整最终问的是：

Compromised Authority → Can it independently cause protected execution?

所以：

Zero Trust 衡量失陷以后还能接触多少资源；对抗性完整衡量失陷以后还能独立造成什么现实后果。

因此，对抗性完整并不是 Zero Trust 的替代品。

Zero Trust 仍然是现代安全体系非常重要的基础。

它解决：

Identity、Context、Access、Least Privilege。

但当系统从“访问信息”进一步进入“改变现实”以后，仅仅控制 Trust 就不够了。

因为一个主体完全可能：

身份合法、Credential 合法、Permission 合法、Session 合法、访问合法，

最后仍然产生一个：

不应该发生的现实动作。

此时安全体系必须继续控制另外一个对象：

Authority。

因此，两者可以被压缩成两个不同方向：

Zero Trust → Reduce Implicit Trust

Adversarial Completeness → Reduce Implicit Execution Authority

Zero Trust 的核心问题是：

当前这个主体是否应该获得访问资格？

对抗性完整的核心问题则是：

即使这个主体已经不值得信任，它现在掌握的权力是否仍然足以让受保护动作发生？

前者控制信任关系。

后者控制因果能力。

前者限制访问。

后者限制现实改变。

最终，两者真正的区别可以归结为一句话：

Zero Trust 的边界停在“谁能够获得能力”；对抗性完整继续追问“即使这个主体已经失陷，它还能不能独立让事情发生”。