《AI 执行工程论纲》专论：何为“对抗性完整“（Adversarial Completeness）?-北京尧图网络

《AI 执行工程论纲》专论 · 第三概念引子讨论 AI 执行安全时很容易列出一张看似足够的清单多因素认证、多重审批、数字签名、硬件密钥、异常检测、审计日志。这些机制都重要。但它们只说明系统拥有什么不回答当攻击、故障、内部作恶与状态失真同时出现时哪些事情依然绝对不能发生。安全功能说明系统配了多少把锁对抗性完整回答的是钥匙落到攻击者手里之后哪扇门仍然打不开。对抗性完整不承诺「永不被攻破」也不承诺「消灭全部风险」。它的命题只有一条在明确声明的威胁模型与故障模型下即使部分组件已经失效、被控制或开始作恶最关键的执行约束仍然成立。一、有安全功能不等于安全边界成立传统安全建设围绕功能展开有没有权限系统、审批流程、硬件签名、日志留痕。问题在于机制在正常条件下能运行不代表它在对抗条件下仍然有效。一个系统可以没有任何代码缺陷却依然不安全——因为它的规格从未覆盖「管理员关闭规则」「SaaS 被接管」「审批对象与执行对象不一致」。每个组件也可以分别安全而整条执行链仍被绕过——因为组件只验证自己攻击者利用的却是组件之间从未被验证的关系。没有 Bug 只能证明实现忠于设计不能证明设计足以抵抗攻击。正常运行证明系统会工作对抗性完整证明系统失去正常之后仍不会越界。因此它要求系统明确回答五件事允许哪些部分失效哪些信任域不能同时失效失效后进入什么状态哪些执行必须被拒绝最终结论如何被独立验证。二、从「我们有什么」到「即使如此也不能发生」最重要的方法论变化是把安全描述从功能清单改写为安全命题。「使用了硬件密钥」不是安全命题「采用三人审批」也不是。可验证的表达只有一种结构即使 X 已经发生Y 仍然不能发生。即使 SaaS 被完全攻陷攻击者仍不能绕过硬件边界取得最终执行能力即使管理员拥有最高业务权限也不能关闭固化在边界中的安全底线即使审批人数达标只要审批来源不具备关系独立性就不能产生ALLOW即使 Payload 携带合法签名只要无法与原始意图和审批对象绑定执行仍须拒绝即使系统无法确认当前状态也不能把未知解释为安全。每一条都同时指明哪一部分被假定失守以及失守之后哪条底线仍必须成立。真正的安全声明不是「攻击者进不来」而是「即使他已经进来了他仍然做不到什么」。这让安全变得可证伪。测试者可以直接接管 SaaS、替换 Payload、控制管理员、制造网络分区、提交冲突证据然后观察被禁止的现实动作是否仍会发生。发生则命题失败不发生系统才获得该威胁模型下的对抗性证明。三、攻击者攻击的不是单点而是执行关系STRIDE 围绕身份、数据与访问展开。但 AI 执行链的核心风险不止于数据被篡改而是意图、证据、审批、Payload 与执行能力之间的关系被切断。因此《论纲》提出面向执行链的EX-STRIDE不按攻击主体黑客、管理员、AI、供应链分类而按执行链中被损坏的环节分类——意图被伪造或漂移审批后 Payload 被替换证据被伪造、过期或阻断管理员试图关闭固定底线攻击者绕过最终边界直取现实执行所需的能力。它的价值在于收敛攻击手法层出不穷但攻击若要改变最终结果就必须作用于意图I、候选执行x、策略P、宪法K、证据Ev、判定函数Γ、必要能力cap中的至少一项。不要追着攻击者的名字建立安全体系要守住他最终必须经过的环节。四、系统不知道的时候不能替自己编出答案在边界看来「证据因网络故障取不到」与「证据被攻击者主动阻断」可能表现为完全相同的状态。既然无法区分原因就必须按攻击情形处理。无法区分故障与攻击时宽容故障就是宽容攻击者。所以证据不能只有「有效无效」两态至少需要保留四种不同的非成立状态状态含义恢复路径MISSING必要证据未提交补交证据UNKNOWN已提交但无法完成验证修复验证通道EXPIRED曾经有效现已过期重新采集或重新签发CONFLICT同时持有不能共存的证据独立裁定必要时进入 Safe Mode四者都不产生ALLOW但它们的恢复路径完全不同。未知不是一种低置信度的「是」而是一种不能被放行的「尚未证明」。AI 擅长在信息不足时推测业务系统习惯取默认值运维也常凭经验判断「应该没问题」。但在最终执行边界上推测不能替代证据经验不能覆盖冲突措辞更自信也不能把UNKNOWN改写成VALID。否则任何证据缺失都可以被加一层「智能判断」用语言消解。AI 可以解释未知边界必须保留未知。五、Fail Secure失去能力不能失去边界断网用缓存、异常跳检查、超时沿用旧授权、硬件故障切软件执行——这些设计都能让业务继续运行。但对不可逆执行而言它们意味着保护机制一旦失效执行能力反而自动释放。最危险的系统不是故障后停止而是故障后假装一切正常。Fail Secure 的要求只有一句没有完整证明就不释放执行能力。这里的「拒绝」不等于永久停机而是进入预先定义的受限状态。Safe Mode 可以保留通信、审计、只读访问与必要恢复能力同时禁止新的高风险动作也可以降低额度、缩小范围、要求额外独立证据或现场确认。系统可以降级能力但不能降级底线。如果云端验证失效后本地管理员即可直接执行如果硬件边界故障后软件可以继续签名如果紧急模式能够关闭全部安全约束——那么所谓「降级路径」本身就是一条被正式保留的绕过路径。紧急机制可以改变业务策略P但不能让固定宪法K消失。Owner 可以调整系统如何工作却不能获得关闭最后底线的权力。一条能被故障自动关闭的边界从来就不是边界只是一项正常情况下开启的功能。六、它不承诺绝对安全任何严肃的安全体系都必须承认残余风险。对抗性完整不承诺抵抗拥有无限时间与无限物理接触的攻击者不承诺制造环节已被植入后门且无法认证的硬件仍然可信也不承诺在全部独立证据来源被同一主体控制之后系统还能凭空恢复事实。它要求的不是隐藏这些边界而是把它们明确写进威胁模型。不声明自己不能防什么的安全体系通常也没有证明自己真正防住了什么。支撑它的是一组可执行的验证活动明确威胁模型 → 建立失败矩阵 → 定义任何状态下都必须成立的不变量 → 按执行链受损环节实施对抗测试 → 预先规定如何检测边界已被绕过。它最终回答的不是「系统是否足够安全」这种无法验证的问题而是一个更窄、更硬、更有工程意义的问题在已声明的攻击与故障条件下那些绝不能发生的现实动作是否仍然不能发生结语执行缝隙说明局部正确推不出最终结果正确。执行控制说明现实动作必须在最后边界之前接受独立裁决。对抗性完整继续追问当上层系统已经不再可信这道裁决是否仍然成立边界的价值不在所有人都守规则时边界的价值在有人开始破坏规则以后。AI 时代不缺更聪明的判断系统真正稀缺的是一种不会因为攻击、故障、权力或紧急状态而自动放弃底线的工程结构。安全不是证明系统永远不会失败而是预先决定当系统失败时什么仍然不能发生。所谓对抗性完整就是允许系统失去部分可信仍不允许现实失去最后边界。延伸阅读关于执行缝隙、执行控制、对抗性完整与 EBL 执行边界语言的完整体系见《AI 执行工程论纲》

《AI 执行工程论纲》专论：何为“对抗性完整“（Adversarial Completeness）?

相关推荐

Dify实战：零代码构建AI应用与自动化工作流

HC-05蓝牙模块与虾米扩展板集成方案对比测评

C++与Python混合编程实战：性能优化与工程实践

更多资讯

Dify 1.17本地部署实战：从Docker Compose到模型接入全指南

Noah-MP陆面模式与Python整合实践指南

OpenCode与Claude Code：AI编程辅助工具对比与实战

Zulip 升级失败后如何回滚到之前的版本

Telegraf Merge 聚合器插件：按序列键合并多条指标为多字段指标

RBF神经网络PID自整定控制：MATLAB实现与梯度下降参数优化

今日更新

51单片机开环控制磁阻传感器的硬件匹配与代码实现

AI Agent安全操作数据库：SQL注入防御与参数化查询实战

Android逆向实战：还原激励类App签到接口的签名算法

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？