Assurance Case Automation：证据都是真的，为什么仍然不足以证明 AI Agent 系统安全？｜SEO / GEO 自动化治理（四十八）

SEO / GEO 工作自动化部署与实践规范 · 第四十八篇

核心主题： Assurance Case Automation / Claim–Argument–Evidence / Goal Structuring Notation / Structured Assurance Case Metamodel / Evidence Sufficiency / Defeasible Reasoning / Assumption Tracking / Confidence Assessment / Continuous Assurance Case / Evidence-driven Governance Decision

研究日期：2026 年 11 月 5 日（北京时间）

研究性质： 国际标准与原始研究核验、可信自治系统工程分析、本项目原创 SEO/GEO Assurance Case 自动化模型

系列定位： AI Agent 生产治理、SEO/GEO 工作自动化、系统安全论证、证据充分性、持续保证与风险决策

---

一家企业已经建立了一套相当完善的 AI Agent 自动发布平台。

Research Agent 负责研究，Writer Agent 负责内容生成，Fact Check Agent 负责证据核验，Editorial Agent 负责审核，Publisher Agent 负责将文章发布到 WordPress。

在此前的工程改造中，系统已经具备：

Policy-as-Code。

Workload Identity。

Resource Ownership。

Evidence-bound Authorization。

Runtime Assurance。

Governance Root of Trust。

Formal Model Checking。

Assurance Evidence Plane。

每次正式发布之前，系统会生成一组结构化记录。

某天，一篇工业设备技术指南通过全部自动检查。审核人员打开 Governance Dashboard，看到了以下结果：

Artifact Integrity:
VERIFIED

Editorial Approval:
VERIFIED

Policy Decision:
ALLOW

Runtime Assurance:
PASS

Workload Identity:
VALID

WordPress Effect:
VERIFIED

Evidence Ledger:
INTEGRITY VERIFIED

Final Result:
ALL CHECKS PASSED

每一条记录都真实。数字签名有效。文章摘要匹配。WordPress 中的内容也与批准版本一致。日志没有发现被篡改的迹象。

按照已有标准，这次发布似乎没有任何问题。

但独立安全评审人员提出了一个问题：

“这些证据能证明当前发布流程是安全的吗？”

工程团队回答：“所有检查都已经通过。”

评审人员继续追问：“系统是否已经证明，所有能够修改网站内容的执行路径，都必须经过这些检查？”

没有人能够立即回答。

进一步调查发现：

Publisher Agent 的确必须通过 Protected Effect Gateway。

但是 WordPress 还保留了一组拥有文章编辑权限的旧凭据。某个历史自动化脚本仍然可以通过这组凭据直接修改文章。

与此同时，WordPress 管理后台中的部分高权限账户，也不受新建 Publisher Gateway 控制。

这意味着：

所有已记录的 Agent 发布操作都可能完全合规，但系统仍然存在没有被纳入验证范围的生产写入路径。

那些审批记录不是假的。那些 Policy Decision 不是假的。WordPress 回读结果也不是假的。

问题在于：

这些真实证据，并不足以支持“所有受保护的生产写入都受到可信治理”的结论。

它们最多支持一个范围更窄的判断：

当前记录中的这次 Publisher Gateway 发布操作，满足已定义且已经核验的部分安全条件。

这两个结论之间存在非常大的差距。

第（四十七）篇，我们研究了：怎样证明证据来源可信、完整、及时，并与真实生产效果相对应。

第（四十八）篇，我们继续推进：

即使所有证据都可信，怎样判断这些证据是否足以支持系统提出的安全主张？

本篇的核心研究对象是 Assurance Case Automation。

一、为什么 Evidence Verification 之后，必须进入 Assurance Case？

第（四十七）篇建立：

Policy Decision
       ↓
Authorization Evidence
       ↓
Runtime Assurance Decision
       ↓
Effect Command
       ↓
External Effect
       ↓
Observed State
       ↓
Causal Evidence Graph
       ↓
Independent Verification

这条链路帮助回答：操作是否有可靠授权记录？证据是否与同一 Intent、Artifact 和 Effect 对应？记录是否完整、未被发现篡改？WordPress 是否具有相应真实结果？

但这些仍停留在证据验证层面。

它们没有自动回答：

系统的安全目标是什么？

必须满足哪些条件？

这些条件是否覆盖所有重要风险？

每项证据对结论究竟提供什么支持？

是否存在能推翻结论的反例？

哪些假设仍未验证？

这些是论证问题。

Assurance Case 不只是收集证据，而是建立从明确主张到支持论证、再到具体证据的可审查推理结构。

这是本系列从治理执行进入治理证明的转折。

二、Assurance Case 究竟是什么？

ISO/IEC/IEEE 15026-2:2022 是 Assurance Case 领域的重要标准。

核心思想是在明确上下文中，围绕特定系统属性，以实际证据支持可审查论证，从而为某项主张提供合理依据。

需要特别注意：

该标准规范 Assurance Case 的结构和术语，但并不保证 Assurance Case 内容本身的质量。

也就是说，一套论证即使满足某种结构规范，也不代表其结论一定成立。

英国 AI Security Institute 对 Safety Case 的解释强调三个核心组成：

Claim、Argument、Evidence。

对应主张、论证、证据。

CLAIM
我们希望证明什么？
       ↓
ARGUMENT
为什么这些条件足以支持该结论？
       ↓
EVIDENCE
有哪些可以核验的事实支持这些条件？

最容易被忽略的是中间的 Argument。

工程系统往往擅长产生日志和测试报告，却不擅长解释：

这些日志与测试报告为什么足以支持更大的系统级结论。

三、Claim–Argument–Evidence：三者必须分开设计

以 WordPress 正式发布为例。

首先提出 Claim：

在指定生产环境和当前系统版本下，所有纳入治理范围的自动化文章发布操作，均须经过有效授权，并符合已定义的运行时安全约束。

为了支持它，需要 Argument。

第一，所有纳入范围的自动化发布请求只能通过受保护 Gateway 产生外部写入。

第二，Gateway 对每次写入验证身份、资源权限、文章摘要和审批。

第三，Gateway 执行前检查 Safety Epoch、Policy Version 和 Effect Reservation。

第四，外部结果通过 WordPress 回读及 Effect Ledger 对账验证。

第五，相关异常无法自行恢复高风险写权限。

然后才是 Evidence：

Gateway 入口与权限检查记录。

WordPress 凭据权限审计。

Policy 测试报告。

Artifact Digest 对比记录。

运行时拒绝日志。

重复投递测试。

WordPress 回读结果。

故障恢复演练报告。

Evidence 负责说明事实，Argument 负责说明这些事实为什么支持 Claim。

如果没有 Argument，真实证据也可能被用来支持不恰当的结论。

四、安全主张必须具体，不能只写“系统安全”

一句“AI Agent 系统是安全的”，几乎无法直接验证。

我们不知道安全针对什么风险、覆盖哪些 Agent、哪些环境和生产操作、哪些版本、允许什么例外，以及结论在什么条件下失效。

每个 Assurance Claim 都应有明确边界。

claim_id: CLM-PUBLISH-001

subject:
  service: seo-publisher
  environment: production
  site: SITE-A

property:
  name: NoUnauthorizedPublish

scope:
  actions:
    - wordpress.create_post
    - wordpress.update_post

  channels:
    - protected_effect_gateway

  exclusions:
    - separately_governed_manual_admin_actions

baseline:
  deployment_ref: DEPLOY-001
  policy_bundle_ref: POLICY-001
  runtime_contract_ref: RTA-001

claim:
  statement: >
    Every in-scope protected publishing
    effect is authorized and bound to
    an approved artifact under the
    specified runtime conditions.

status: NOT_YET_ASSESSED

这是项目示例，不是已执行记录。

重点是明确：这项安全结论适用于哪些生产行为？

尤其重要的是 exclusions。如果人工后台操作不在 Claim 范围，就不能据此宣称整个 WordPress 网站不存在未经授权修改。

被排除范围必须由独立治理控制负责。写成排除项，不会自动消除风险。

五、Safety Case 的关键不是让结论强大，而是让它可被反驳

“系统使用先进的安全治理机制”缺少明确测试条件。

而：

对当前部署版本的指定自动发布入口，每次正式 WordPress 写入都必须具有可追溯有效授权与对应批准 Artifact。

就可以接受检查。

我们能够调查：

是否有写入缺少 Approval？

是否接受旧 Capability？

是否存在 Digest 不匹配？

是否有未归属的 WordPress Effect？

是否存在绕过 Gateway 的路径？

好的安全主张不应通过模糊措辞避免被推翻，而应主动定义什么事实能够推翻它。

这一思想与 Assurance 2.0 强调的 Defeater Analysis 一致。

六、Goal Structuring Notation：如何拆解大结论？

Goal Structuring Notation，GSN，是一种表达 Assurance Argument 的结构化方法。

Safety-Critical Systems Club 发布的 GSN Community Standard Version 3，为安全论证提供结构和实践指导。

它帮助工程人员明确目标、策略、上下文、假设及其支持证据，而不仅提交很长的文字报告。

G0: Top-level Claim
          │
          ↓
S1: Argument Strategy
          │
     ┌────┼────┐
     ↓    ↓    ↓
    G1   G2   G3
     │    │    │
     ↓    ↓    ↓
   Sn1  Sn2  Sn3

G 表示 Goal，S 表示 Strategy，Sn 表示 Solution，即证据解决项。

实际 GSN 还有 Context、Assumption、Justification 等元素。这里是便于阅读的简化图，并非完整 GSN 规范图。

GSN 的价值不是绘图，而是显式暴露论证结构中的缺口。

七、Structured Assurance Case Metamodel：让安全论证进入自动化

GSN 偏重结构化论证的表达。

若进一步考虑跨工具存储、交换和机器处理，需要研究 Structured Assurance Case Metamodel，即 SACM。

Object Management Group 维护 SACM 规范。

截至本篇研究时间，2.3 属正式发布版本；2.4 Beta 已进入规范流程，但不能当作最终正式版本。

SACM 的工程价值在于为 Assurance Case 中的论证对象和证据对象提供机器可处理的结构化表达基础。

Claim
  │
  ├── Argument
  │     │
  │     ├── Subclaim
  │     └── Reasoning
  │
  └── Evidence Reference

对于 SEO Publisher，未来可以连接 Claim Registry、Argument Graph、Evidence Registry、Policy Registry、Runtime Contract Registry、部署版本与治理批准记录。

但：

使用 SACM 或 GSN，不意味着自动获得认证，更不意味着论证质量已通过独立审查。

结构化表达只是基础，核心是论证能否成立。

八、为什么所有测试都 PASS，仍然不能证明系统级安全？

假设：

Test A:
Publish without approval → DENY

Test B:
Publish with stale epoch → DENY

Test C:
Publish with wrong digest → DENY

Test D:
Queue duplicate message → no duplicate post

Result:
4/4 PASS

测试都真实。

但能否支持“网站所有正式内容修改都不会越过治理系统”？

通常不能。

测试覆盖特定路径和状态，仍可能存在：

人工管理员直接修改文章。

旧脚本调用 WordPress。

插件使用其他接口更新内容。

额外 REST Endpoint。

数据库层直接修改。

泄露的高权限凭据。

所以它们可支持：

指定 Gateway 在已测试条件下满足对应控制要求。

不能自动支持：

整个网站不存在其他未经治理的生产写入路径。

真正缺少的不是更多 PASS，而是覆盖完整性的论证。

九、Evidence Sufficiency：怎样判断证据是否足够？

本项目建议对证据充分性设置七个审查维度。

测试报告可能可信，却只覆盖开发环境。

它在 Credibility 方面合格，但在 Production Applicability 方面可能不足。

WordPress 回读可以证明文章存在，却不能证明所有写入入口受控。

它在 Relevance 方面具有一定价值，却不足以支持广泛的 Claim。

Evidence Sufficiency 不应以文件数量、日志数量或 PASS 数量衡量，而应以证据与主张之间的推理关系衡量。

十、必要条件全部满足，不等于充分条件成立

这是 Assurance Case Automation 最关键的逻辑问题。

假设：

A = Valid Approval
B = Correct Artifact Digest
C = Policy Allow
D = Runtime Assurance Pass

四项全部成立。

能否推出：

Safe Publishing System

不能直接推出。

还缺少一个需要证明的逻辑前提：

A、B、C、D 的共同成立，为什么足以支持当前定义的安全结论？

如果系统有另一个不经过这些检查的写入入口：

A AND B AND C AND D

即使全部成立，也无法覆盖该入口。

因此需要在论证中明确：

A AND B AND C AND D
AND
All In-scope Effects Pass This Boundary

最后一项往往最难证明。

Assurance Case 的核心工作之一，是识别从局部事实推导系统级结论时缺失的桥梁条件。

十一、一个真正可审查的 Publishing Assurance Case

首先提出顶层 Claim。

G0：在指定生产版本与治理范围内，受保护的自动化文章发布行为满足组织定义的发布安全要求。

再按风险机制分解：

G0:
Protected Publishing Is Acceptably Controlled
                    │
                    ↓
               Strategy S0
                    │
   ┌────────┬───────┼───────┬─────────┐
   ↓        ↓       ↓       ↓         ↓
  G1       G2      G3      G4        G5

Authority Artifact Runtime Effect  Recovery
Control   Binding  Control Integrity Control

还需要横向条件：

G6：执行范围完整，并且不存在尚未解释的生产写入绕过路径。

这样，Case 不再只验证系统已经执行的步骤，也开始验证：

整个被声明的安全边界是否覆盖应该覆盖的生产行为。

十二、G1：怎样证明生产授权控制有效？

G1 可以定义为：

每项受保护的生产操作，都具备与执行主体、资源、动作和当前运行状态相匹配的有效授权。

需要的不是一份简单 ALLOW 日志。

还需证明：

Workload Identity 经过验证。

权限范围覆盖本次动作。

Policy Decision 适用于当前版本。

Safety Epoch 没有失效。

授权尚未被撤销。

最终写入路径真正执行这些检查。

可关联的证据：

Workload Attestation
Policy Bundle Digest
Authorization Decision Receipt
Capability Validation
Safety Epoch Record
Effect Gateway Enforcement Record

Policy 返回 ALLOW 与 Gateway 实际执行 ALLOW，不是同一项证据。

必须把决策与执行边界连接起来。

十三、G2：怎样证明发布内容与批准内容一致？

G2 可以定义为：

实际提交并保存的受保护内容，与适用的已批准 Artifact 在定义的内容表示层级上保持一致。

这里必须说明比较对象：

Markdown Source。

WordPress content.raw。

WordPress content.rendered。

公开页面 HTML。

它们不一定具有相同字节表示。

如果 Approval 绑定 Markdown，而最终核对渲染后的 HTML Digest，正常转换也可能导致摘要不同。

因此 G2 还需要：

内容规范化规则。

转换版本。

批准时 Artifact Digest。

提交时 Artifact Digest。

WordPress 回读表示层级。

必要时的渲染一致性检查。

结论应限定为：

被批准内容在规定的转换与允许变更范围内，与实际生产内容一致。

不能把所有表示层级视为字节完全相同。

十四、G3：怎样证明 Runtime Assurance 真正覆盖执行过程？

G3 可以定义为：

每次受保护的生产写入都受到当前 Runtime Contract 和 Safety Envelope 约束。

需要核验：

安全检查发生在 Effect 之前。

检查输入来自受信上下文。

异常时不默认放行。

状态改变后不复用失效授权。

Fallback 无权自行恢复高风险写入。

这里可以引用第（四十五）篇 Formal Verification Manifest，但模型 PASS 只是证据之一。

还需要实现映射与测试：

Formal Property
       ↓
Runtime Contract
       ↓
Implementation Control Point
       ↓
Conformance Test
       ↓
Observed Production Behavior

如果模型要求检查 Safety Epoch，但代码只定义了检查函数、没有在真实发布路径调用，Claim 就不能成立。

十五、G4：怎样证明外部 Effect 得到正确处理？

G4 应覆盖：

Effect Reservation。

WordPress 请求派发。

请求结果确认。

外部状态回读。

重复投递。

网络超时。

Effect Unknown。

Idempotency。

如果 WordPress 创建成功但响应丢失，系统直接重试又创建重复文章，那么即使首次发布得到有效批准，也可能违反 Effect Integrity。

因此需要：

Effect Intent
      ↓
Effect Reservation
      ↓
WordPress Command
      ↓
External Observation
      ↓
Reconciliation
      ↓
Verified Outcome

对于结果不确定的操作：

不能因为请求超时，就自动认为外部效果没有发生。

除了正向成功证据，也需要异常情况下的故障测试。

十六、G5：怎样证明事故期间存在可信恢复路径？

安全系统不能只证明正常情况下不会出错。

还要解释事故发生后怎样限制损害、处理不确定状态、恢复必要生产能力，以及避免治理系统自身形成死锁。

这与第（四十）、（四十一）、（四十四）、（四十五）、（四十六）篇直接相关。

G5 可以分解为：

Containment 阻断受影响的新写入。

旧 Capability 无法自行恢复权限。

Recovery 具备独立授权与证据要求。

Break-glass 受范围、时间及审批约束。

恢复后产生新的有效运行时授权。

需要强调：

存在恢复流程，不等于该流程能够在所有事故条件下成功执行。

若提出恢复进展的 Liveness Claim，还需要明确外部服务和调度条件，不能无条件承诺在任何情况下都能恢复。

十七、G6：为什么“所有写入路径都受控”可能是最重要的子主张？

前面 G1 至 G5 可能全部通过。

但如果另一插件仍能直接修改 WordPress 内容，绕过 Agent Gateway：

G1 = SUPPORTED
G2 = SUPPORTED
G3 = SUPPORTED
G4 = SUPPORTED
G5 = SUPPORTED

并不意味着整个网站的写入环境安全。

因为：

G6 = NOT ESTABLISHED

G6 必须回答：

哪些主体可以写入？

哪些 API 可以写入？

哪些凭据能修改内容？

管理后台、插件、部署脚本与数据库是否有其他写入能力？

哪些路径纳入当前 Claim？

哪些由其他控制机制治理？

是否存在未知或未登记的写入？

证据可以包括 WordPress 权限与账户审计、Application Password 清单、生产脚本清单、写入接口分析、实际修改记录、独立 Unattributed Effect 检测。

局部控制正确，不能自动替代系统边界完整。

十八、Evidence Sufficiency 应与 Risk Model 双向关联

只从已有证据出发构建 Assurance Case，容易产生选择性证明。

例如系统有很多 Publisher 测试记录，于是团队围绕这些记录提出 Claim。

但真正风险可能是全站错误 noindex、批量 Redirect、失效的 Application Password 或旧脚本绕过 Gateway。

因此应从 Risk Model 反向检查 Evidence Sufficiency：

Risk / Hazard
      ↓
Safety Requirement
      ↓
Claim
      ↓
Argument
      ↓
Required Evidence

也从 Evidence 反向追溯：

Available Evidence
      ↓
Supported Subclaim
      ↓
Argument
      ↓
Top-level Claim

从 Claim 向下，发现证据缺口。

从 Evidence 向上，防止无关证据被夸大为系统级证明。

十九、为什么 Positive Evidence 不够？

团队偏好展示：

测试通过。

审批通过。

发布成功。

没有报警。

没有观察到违规。

这些是正向证据。

但：

没有观察到问题，不一定意味着问题不存在。

Gateway 在全部测试样本中都拒绝无效授权，但测试可能没有覆盖：

缓存中的旧授权。

系统时间变化。

并发写入。

身份服务故障。

异常恢复。

绕过 Gateway 的入口。

仅有 Positive Evidence 容易导致确认偏差。

英国国防科学技术实验室关于 AI 与自治系统 Assurance 的研究强调：除了支持可信性的正向证据，还需要主动寻找可能使系统失败的负向证据。

这与此前 Counterexample-driven Governance、Game Day 相连接。

二十、Defeater：什么事实能够推翻安全论证？

Assurance 2.0 强调识别 Defeaters，即可能削弱或推翻 Assurance Argument 的挑战。

可理解为：

如果这个疑问成立，当前论证会在哪个环节失败？

例如：

Claim：

所有受保护的自动化发布都必须经过有效授权。

Defeater：

可能存在未经 Gateway 的直接 WordPress 写入入口。

这不是随意担忧，而是直接挑战“执行边界完整”这一前提。

Defeater 应具有攻击对象、风险机制和处置流程。

defeater_id: DEF-047-001

attacks_claim: CLM-PUBLISH-001

type: UNDERCUTTING

statement: >
  A legacy publishing client may perform
  writes without passing the protected gateway.

investigation:
  required: true

status: OPEN

resolution_evidence: []

UNDERCUTTING 借鉴论证理论术语。整个 YAML 是项目示例，不是官方通用 Schema。

二十一、Undercutting 与 Rebutting：两类不同的反证

Assurance 2.0 研究讨论多种 Defeater。

Undercutting Defeater：攻击证据与结论之间的推理关系。

例如团队用测试环境的 Gateway 检查结果支持生产环境安全结论。

质疑：

测试环境和生产环境是否使用相同权限、配置和写入路径？

若无法证明环境一致，测试报告就不一定足以支持生产 Claim。

Rebutting Defeater：提出与主张相矛盾的事实。

Claim：

所有受保护写入都有有效授权。

独立对账发现：

WordPress Modification Observed
Authorization Record Not Found

这直接挑战 Claim。

但缺少授权记录也不一定证明实际未经授权，可能是日志丢失或采集失败。

不过当前已不能无条件维持原 Assurance 结论，应进入：

ASSURANCE_CHALLENGED

然后调查。

二十二、Defeater 不能由原 Agent 随意关闭

如果 Publisher 被发现存在重复发布风险：

DEF-001:
Possible duplicate WordPress effect.

Publisher 不能仅凭“我已经处理好了”就关闭 Defeater。

因为它可能同时是缺陷来源和解释者。

应提供：

修复 Commit。

相关测试。

新的 Effect Reconciliation。

必要的独立审查。

批准的结案记录。

状态机：

OPEN
  ↓
INVESTIGATING
  ↓
RESOLUTION_PROPOSED
  ↓
EVIDENCE_REVIEW
  ↓
RESOLVED / REJECTED / ACCEPTED_RISK

ACCEPTED_RISK 不能自动等同 RESOLVED。

它表示剩余风险在明确权限下被接受。

若超出组织允许范围，不能通过简单的“接受风险”恢复生产。

二十三、Assumption Tracking：隐藏假设为何危险？

第（四十五）篇讨论过 Liveness 与 Fairness 对运行环境的依赖。

Assurance Case 也依赖假设。

例如：

Claim:
Old Agent cannot modify WordPress.

可能依赖：

旧凭据已经撤销。

全部写入路径经过身份控制。

缓存不会无限接受旧授权。

不存在未登记管理接口。

如果假设未被记录，团队可能把“默认成立”误当“已经证明”。

所以要建立 Assumption Registry。

每条 Assumption 应记录：

关联 Claim。

内容。

验证方式。

负责人。

有效条件。

状态。

失效后的影响。

二十四、Assumption 必须能触发自动失效传播

assumption_id: ASM-046-003

statement: >
  All automated WordPress publishing
  operations use the protected gateway.

depends_on:
  - wordpress_write_credentials_inventory
  - deployment_access_review
  - runtime_effect_reconciliation

validation:
  method: cross_system_audit
  max_age: P1D

status: NOT_YET_VERIFIED

impacted_claims:
  - CLM-PUBLISH-001

项目示例的关键并不是字段名称。

而是：发现新的 WordPress 写入凭据时，这条 Assumption 自动进入重新验证状态，并影响关联 Claim。

Credential Inventory Changed
           ↓
Assumption Revalidation
           ↓
Claim Impact Analysis
           ↓
Assurance Case Reassessment

不能生产环境已经改变，Dashboard 却仍显示几个月以前的安全结论。

二十五、Confidence Assessment：为什么不应简单计算“安全置信度 98%”？

Assurance Case 涉及 Confidence，但容易产生伪精确。

假设系统有 100 项检查，其中 98 项通过。

能否得到：

Safety Confidence = 98%

通常不能。

这些检查不是独立同分布的随机试验，风险权重也不同。

其中可能有很多日志格式检查、低风险内容验证，却只有一次关键的 Gateway Bypass 检查。

如果唯一失败的是 Gateway Bypass，其他 98 项 PASS 不能抵消该风险。

Assurance 2.0 的研究指出，Confidence 不能简单压缩为单一数字。

应综合考虑：

论证逻辑充分性。

证据质量和判别力。

Defeater 调查结果。

剩余风险。

与决策场景有关的假设。

如果没有严格设计的概率模型，不能随意生成精确安全百分比。

二十六、建立可解释的 Assurance Confidence Profile

对于 SEO/GEO 自动化，建议使用多维 Profile，而不是伪精确综合评分。

这种情况下，不能因为 Evidence Integrity 已核验，就把整个 Case 标为通过。

这是一套供治理评审的状态模型，并非官方统一 Assurance Confidence 算法。

核心是：

让团队知道当前安全主张为什么成立、为什么尚不能成立，以及还差哪些证据。

二十七、Evidence Independence：证据数量多，不一定更有说服力

假设：

Publisher Log。

Runtime Monitor Log。

Governance Dashboard。

三者都显示：

Publish Authorized = TRUE

但全部来自 Publisher 自报的同一字段。

这不是三份独立验证，实质上只有一个信息来源。

若原始字段错误，三个系统可能一致重复错误。

所以 Case 应记录：

Evidence Source。

Evidence Producer。

Verification Method。

Shared Dependencies。

共同失效条件。

独立读取的 WordPress 资源状态与 Publisher 自报 HTTP Success 相比，可以提供新的外部效果信息。

但 WordPress 不同 REST Endpoint 也可能共享同一数据库和权限系统。

Evidence Independence 是信任与失效边界分析，不是计算 API 数量。

二十八、Coverage Argument：怎样证明风险清单没有遗漏重要路径？

顶层论证常以风险识别为基础。

组织识别六类高风险操作，并对它们提供测试。

但还需要追问：

为什么这六类已经覆盖所有应该治理的重要生产风险？

这是 Coverage Argument。

对 SEO Publisher，至少比较：

已登记 Agent Tool。

Cloudflare Worker 路由。

GitHub Actions。

WordPress 写入凭据。

WordPress 用户权限。

关键插件。

其他影响内容或索引配置的入口。

还要核对：

实际 WordPress 变化。

Effect Ledger。

部署记录。

必要的人工变更记录。

如果发现未经登记的生产入口，原 Coverage Claim 必须重新评估。

模型检查强调模型边界；Assurance Case 则继续论证：

所选择的系统边界为什么足以支持当前业务结论。

二十九、从 Assurance Evidence Plane 进入 Assurance Argument Graph

第（四十七）篇建立：

Causal Evidence Graph

它强调实际事件之间的关联。

第（四十八）篇增加：

Assurance Argument Graph

它强调主张之间的推理关系。

两者不同。

Causal Graph 可以证明某次 Approval 关联某次 Publish Intent。

Argument Graph 要解释该 Approval 为什么支持“此次发布符合规定”的主张，以及还需要哪些其他条件。

                    TOP CLAIM
                        │
                   Supported By
                        ↓
                 ARGUMENT STRATEGY
                        │
           ┌────────────┴────────────┐
           ↓                         ↓
      SUBCLAIM A                SUBCLAIM B
           │                         │
       EVIDENCE A              EVIDENCE B

并且：

EVIDENCE A
    ↓ references
Causal Evidence Graph

从而形成论证与事件证据之间的可验证关系。

三十、构建 Assurance Case Automation 的最小数据模型

建议从六种对象开始。

Claim：明确的安全主张。

Argument：连接主张与证据的推理步骤。

Evidence Reference：引用第（四十七）篇可信证据。

Assumption：推理依赖的条件。

Defeater：可能削弱或推翻论证的挑战。

Assessment：独立审核结果及范围。

关系：

Claim
  │
  ├── supported_by → Argument
  │                     │
  │                     ├── subclaim
  │                     └── evidence
  │
  ├── depends_on → Assumption
  │
  ├── challenged_by → Defeater
  │
  └── assessed_by → Assessment

每个对象应有稳定 ID、版本和负责人。

不能只靠标题或自然语言描述建立引用，否则 Claim 略有修改，自动化系统可能无法判断与旧 Evidence 的关系。

三十一、一个可实施的 Assurance Case Schema

项目级 YAML 示例，用于定义审核逻辑，不代表真实执行的 Assurance Case。

case_id: CASE-048-001
version: 1.0.0

top_claim:
  id: CLM-001
  statement: >
    All in-scope protected WordPress
    publishing effects are authorized,
    artifact-bound, and runtime-controlled.

  scope:
    environment: production
    service: seo-publisher
    actions:
      - wordpress.create_post
      - wordpress.update_post

  baseline:
    deployment: DEPLOY-001
    policy_bundle: POLICY-001
    runtime_contract: RTA-001

argument:
  id: ARG-001
  strategy: hazard_and_control_decomposition

  required_subclaims:
    - CLM-IDENTITY
    - CLM-ARTIFACT
    - CLM-RUNTIME
    - CLM-EFFECT
    - CLM-RECOVERY
    - CLM-COVERAGE

evidence:
  required:
    - wordpress_write_path_inventory
    - deployment_attestation
    - authorization_regression_tests
    - artifact_binding_tests
    - runtime_conformance_tests
    - effect_reconciliation_report

assumptions:
  - ASM-WRITE-BOUNDARY
  - ASM-TRUSTED-IDENTITY
  - ASM-EXTERNAL-OBSERVATION

defeaters:
  require_critical_resolution: true

assessment:
  status: NOT_YET_ASSESSED
  reviewer: null
  evaluated_at: null

重点是：

Claim 绑定环境、动作和部署版本；Argument 明确必要子主张，不只是证据引用。

否则系统无法判定证据缺口是否影响顶层结论。

三十二、Assurance Case Automation 应自动完成哪些检查？

首先验证论证结构。

是否存在顶层 Claim？

Claim 是否定义范围？

是否存在 Argument？

是否引用必需子主张？

是否有无证据支持的叶子 Claim？

其次验证证据适用性。

Evidence 是否存在？

是否完成第（四十七）篇的验证？

是否适用于当前 Deployment？

是否绑定当前 Artifact？

是否超过有效期？

第三，验证治理条件。

是否有未解决的 Critical Defeater？

是否存在失效 Assumption？

是否有重要子主张状态不明确？

是否有未经授权的 Exception？

最后生成评估结果。

但是：

自动检查 Claim Graph 结构完整，不等于证明整个论证逻辑正确。

复杂推理、风险接受和未建模路径，仍需要独立工程评审。

三十三、为什么不能只写自动计算的 PASS？

假设所有必需证据都存在。

系统执行：

Required Evidence Found
→
PASS

这只是结构完整性检查。

更完整的评估要区分：

Evidence Exists

Evidence Verified

Evidence Applicable

Argument Justified

Claim Supported

它们不是一个状态。

例如测试报告存在、签名有效，却针对旧版 Worker：

Evidence Exists = TRUE
Evidence Integrity = VERIFIED
Evidence Applicable = FALSE

此时不能把相关子主张标记为已充分支持。

Assurance Case Automation 的目标不是尽可能多输出 PASS，而是准确解释结论能被支持到什么程度。

三十四、设计 Assurance Case 的状态机

建议至少区分这些状态。

这里 SUPPORTED 不是：

PROVEN_SAFE_FOREVER

而是：

当前证据与论证在规定范围、条件和评审准则下，足以支持相应决策。

对于部分主张可以使用更严格的形式化证明，但整个系统是否安全，不能仅凭某个模型检查报告自动得出无限范围的结论。

三十五、Case 状态如何影响真实生产权限？

这是从理论到工程的关键。

Assurance Case 不能只是 Dashboard 装饰。

对高风险 Action，它应成为治理决策输入。

Proposed Production Action
           ↓
Policy Authorization
           ↓
Runtime Assurance
           ↓
Applicable Assurance Case
           ↓
Final Governance Gate
           ↓
Protected Effect

但不能让 Agent 自己生成：

Assurance Case = SUPPORTED

便立即获得新权限。

Case 必须经过独立评估，生效范围和版本也要接受 Meta-Governance 约束。

例如：

Applicable Case = SUPPORTED
AND
Case Baseline = Current Production Baseline
AND
Critical Defeaters Resolved
AND
Required Assumptions Valid

可作为高风险决策的必要前提之一，但不是唯一授权条件。

主体身份、权限、资源和运行时状态仍需检查。

Assurance Case 提供决策依据，不能替代最小权限与执行前授权。

三十六、Continuous Assurance Case：为什么论证必须持续更新？

传统 Assurance Case 容易成为一次性评审文件。

上线时形成报告。

后来代码升级、Policy 修改、Agent 增加工具，报告却未更新。

Assurance Case:
SUPPORTED

Production System:
CHANGED

原结论可能已经不适用。

因此要建立 Continuous Assurance Case，持续维护：

Claim。

Argument。

Evidence。

Assumption。

Defeater。

Deployment Baseline。

Runtime Observation。

评审决定。

但不必每次低风险文字调整都重新验证整个系统，应当依据影响范围重新评估子主张。

三十七、Change Impact Analysis：怎样识别受影响 Claim？

假设 Publisher 更新重试逻辑。

变更可能直接影响：

CLM-EFFECT

涉及重复发布防护、Effect Unknown、Idempotency、外部 Reconciliation。

但不一定改变 Editorial Approval 业务规范。

可以沿依赖图分析：

Publisher Retry Logic Changed
             ↓
Effect Integrity Evidence Invalidated
             ↓
CLM-EFFECT Requires Reassessment
             ↓
Top-level Claim Reassessment

又例如 WordPress 新增可写插件：

New Write-capable Plugin
             ↓
Write-path Inventory Changed
             ↓
Coverage Assumption Invalidated
             ↓
CLM-COVERAGE Challenged
             ↓
Top-level Claim Suspended

这样 Assurance Case 不再只是静态安全声明图，而是能够感知生产变化的治理模型。

三十八、Case Invalidity Propagation：子主张失效后顶层怎么办？

假设：

G0
 ├── G1 SUPPORTED
 ├── G2 SUPPORTED
 ├── G3 SUPPORTED
 ├── G4 SUPPORTED
 ├── G5 SUPPORTED
 └── G6 CHALLENGED

如果 G6 是顶层论证必要条件，G0 不能继续无条件 SUPPORTED。

但状态传播不能只有：

Any Child Fails
→
Entire Case Fails

因为论证可能包含经过批准的替代控制。

例如某项风险由控制 A 或经过充分证明的替代控制 B 处理。

因此必须显式定义 Argument 逻辑：

G0 requires:
G1 AND G2 AND G3 AND G4 AND G5 AND G6

或：

G0 requires:
G1 AND G2 AND (G3 OR G3_Alternative)

自动状态传播的正确性依赖明确建模的论证逻辑，不能由 LLM 临时猜测子主张之间是 AND 还是 OR。

三十九、将 Defeater Analysis 放入 CI/CD

第（四十五）篇建立 Counterexample-driven Governance。

现在每个重要 Counterexample 都应关联它挑战的 Assurance Claim。

例如：

Test:
stale_capability_after_recovery

发现真实缺陷。

CI 不应只报告：

TEST FAILED

还应输出：

Challenged Claim:
CLM-RUNTIME

Affected Top-level Case:
CASE-048-001

Reason:
Stale capability accepted after recovery.

Required Action:
Suspend high-risk authorization
and reassess affected claim.

CI 开始向治理决策系统提供结构化反证，而不是只有软件质量状态。

但这些关系必须由可信流程建立，不能让任意测试日志的自然语言直接修改 Governance Root 或发布权限。

四十、完整案例：一次 WordPress 发布怎样形成 Assurance Case？

以 B2B 设备选型指南为例。

文章包括产品参数、应用场景和技术建议。

系统已经得到：

Research Source Registry。

Fact Check Report。

Editorial Approval。

Artifact Digest。

Policy Decision。

Workload Identity。

WordPress Publishing Gateway Record。

WordPress Readback。

Effect Verification。

这些记录已经通过第（四十七）篇 Evidence Verification。

先定义业务 Claim：

指定文章版本的本次自动发布，在当前部署和授权条件下，符合组织定义的正式发布控制要求。

分解为五项子主张：

内容主张：发布内容与批准内容一致。

授权主张：Publisher 对目标站点与动作拥有有效权限。

运行时主张：执行时没有违反 Safety Envelope。

效果主张：WordPress 产生对应且经验证的效果。

覆盖主张：本次 Effect 经过受保护入口，未发现适用范围内的未登记绕过路径。

每项子主张引用相应 Evidence。

然后执行 Defeater Review：

审批之后内容是否被修改？

Policy 是否发生变化？

WordPress 是否存在重复文章？

站点是否运行不同版本 Worker？

是否出现未知的后台修改？

最后由独立评审机制判断：

证据与论证是否足以支持当前定义的发布合规主张。

这种方法可以支持单次 Effect，也可以扩展到部署版本的工作流控制，但两者 Claim 范围不同，不能混用。

四十一、自动化代码应怎样评估 Assurance Case？

简化 TypeScript 风格伪代码，不是已部署的生产实现。

async function assessAssuranceCase(
  caseId: string,
  services: AssuranceServices
) {
  const assuranceCase =
    await services.caseRegistry.load(caseId);

  const baseline =
    await services.deployment.currentBaseline();

  if (!matchesBaseline(
    assuranceCase.scope,
    assuranceCase.baseline,
    baseline
  )) {
    return {
      status: "STALE",
      reason: "Production baseline mismatch",
    };
  }

  const structure =
    await services.argumentValidator.check(
      assuranceCase
    );

  if (!structure.complete) {
    return {
      status: "INCOMPLETE",
      gaps: structure.gaps,
    };
  }

  const evidence =
    await services.evidenceVerifier.verifyRequired(
      assuranceCase.requiredEvidence
    );

  if (!evidence.allApplicable) {
    return {
      status: "INCOMPLETE",
      gaps: evidence.gaps,
    };
  }

  const assumptions =
    await services.assumptionRegistry.evaluate(
      assuranceCase.assumptions
    );

  if (!assumptions.allValid) {
    return {
      status: "CHALLENGED",
      reasons: assumptions.failures,
    };
  }

  const defeaters =
    await services.defeaterRegistry.evaluate(
      assuranceCase.id
    );

  if (defeaters.hasUnresolvedCritical) {
    return {
      status: "CHALLENGED",
      reasons: defeaters.criticalIssues,
    };
  }

  const reasoning =
    await services.argumentEvaluator.evaluate(
      assuranceCase.argumentGraph
    );

  if (!reasoning.rulesSatisfied) {
    return {
      status: "UNDER_REVIEW",
      reasons: reasoning.openQuestions,
    };
  }

  return {
    status: "READY_FOR_INDEPENDENT_ASSESSMENT",
    evidenceRefs: evidence.references,
    argumentRef: reasoning.argumentRef,
  };
}

注意最终不是：

SYSTEM_SAFE = TRUE

而是：

READY_FOR_INDEPENDENT_ASSESSMENT

这是一项有意的设计。

自动化可核验证据、摘要、适用版本、Argument Graph 结构以及尚未关闭的 Defeater。

但复杂系统级安全主张仍涉及论证质量、风险接受与未建模行为。

不能仅凭自动化 PASS 代替有责任主体的工程决策。

四十二、为什么 Assurance Case 不应由 LLM 自行编写、自行审核、自行批准？

LLM 可以帮助生成 Assurance Case 草稿。

例如：

根据 Risk Model 提出候选 Claim。

从 Case Template 生成论证结构。

识别遗漏的 Assumption。

推荐测试或核验方法。

总结 Evidence Gap。

但不能让同一个模型同时具有生成 Claim、生成 Evidence、评价 Evidence、关闭 Defeater、批准 Case 和恢复生产权限的能力。

否则形成新的自我授权循环：

Agent:
"I have sufficient evidence."
       ↓
Agent:
"My argument is valid."
       ↓
Agent:
"Assurance accepted."
       ↓
Agent:
"Production access restored."

这与第（四十四）篇 Meta-Governance 的职责分离原则冲突。

因此：

LLM 负责辅助论证，可信验证器负责事实检查，独立审批主体负责最终高风险治理决定。

四十三、Assurance Case Automation 的实施 SOP

面向 WordPress + Cloudflare Worker + GitHub Actions，建议分六阶段。

阶段一：建立最小 Claim Registry。

先选 WordPress 自动发布这一个高风险主题，不要同时覆盖所有 Agent。

定义 Claim ID、Scope、Owner、Required Evidence、Assumptions 与 Applicable Version。

阶段二：建立 Assurance Argument Graph。

将顶层 Claim 分解为身份、Artifact、运行时、Effect、恢复与覆盖性子主张，明确定义逻辑关系。

阶段三：连接第（四十七）篇 Evidence Registry。

不创建第二套业务日志，只通过受信 Evidence Reference 获取已验证证据。

阶段四：建立 Defeater 与 Assumption Registry。

让事故记录、回归测试、跨系统对账结果可以挑战对应 Claim。

阶段五：接入 CI/CD Change Impact Analysis。

发生高风险变更时，自动识别受影响 Claim 并要求重新评估。

阶段六：接入 Governance Decision Gate。

对于高风险生产动作，适用 Assurance Case 必须处于规定的有效状态，才能继续进入既有 Policy 和 Runtime Enforcement 流程。

保留人工终审和高风险批准机制。

不能因为 Assurance Case Automation 上线就取消组织责任。

四十四、怎样衡量 Assurance Case 的质量？

不能只统计：

Cases Created = 100

或：

Claims Supported = 98%

就宣布安全保证提高。

建议指标：

这些是项目建议 KPI，不是 ISO、OMG、GSN 或 NIST 的统一 Assurance KPI。

重点不是追求更多绿色指标，而是：

安全论证能否准确暴露无法得到充分支持的结论。

四十五、Game Day：让 Assurance Case 主动接受反证

建议建立 Assurance Argument Game Day。

演练一： 删除关键 Evidence，检查顶层 Case 是否停止无条件保持 SUPPORTED。

演练二： 模拟旧 WordPress 凭据绕过 Gateway，检查 Coverage Claim 是否被挑战。

演练三： 更新 Worker 重试逻辑，检查 Effect Integrity Claim 是否重新评估。

演练四： 使 Assumption 过期，检查状态传播。

演练五： 提交多份同源 Evidence，检查是否误认为独立证据。

演练六： 生成签名有效、内容虚假的 Claim Statement，检查独立验证器是否核实事实。

演练七： 使用历史 Policy 评估当前操作，检查版本不一致是否被发现。

演练八： 注入 Critical Defeater，检查 Case 是否进入 CHALLENGED 或受限状态。

核心是：

系统能否因为新的反证而改变原来的安全判断。

如果不论异常如何出现，Assurance Case 都保持绿色，就失去了治理价值。

四十六、十五条 Assurance Case Invariants

本篇收敛成十五条项目级约束。

Invariant 1

Verified Evidence
≠
Sufficient Assurance Argument

Invariant 2

Every Critical Claim
must have an explicit scope.

Invariant 3

Every Assurance Argument
must define how its premises
support its conclusion.

Invariant 4

Evidence Existence
≠
Evidence Applicability

Invariant 5

All Tests Passed
≠
All Relevant Risks Covered

Invariant 6

Model Verification
must not silently expand
beyond its modeled scope.

Invariant 7

Critical Assumptions
must be explicit and monitored.

Invariant 8

Unresolved Critical Defeater
must prevent unconditional
Assurance acceptance.

Invariant 9

Correlated Evidence
must not be treated as
independent by default.

Invariant 10

Assurance Case
must bind to an applicable
production baseline.

Invariant 11

High-risk Change
requires impact-based
Claim reassessment.

Invariant 12

Assurance Case Approval
must respect separation of duties.

Invariant 13

LLM-generated Argument
does not constitute
independent approval.

Invariant 14

Residual Risk Acceptance
must be explicit,
authorized and recorded.

Invariant 15

Claim Supported
does not mean
System Safe Without Conditions.

共同原则：

系统不应因为拥有真实证据，就自动宣称更大范围的安全结论成立。

四十七、真正的 Continuous Assurance Architecture

经过第（四十二）至第（四十八）篇逐层推进，形成：

Governance Requirement
          ↓
Risk / Hazard Model
          ↓
Formal Safety Property
          ↓
Protected Runtime Contract
          ↓
Policy / Authorization Decision
          ↓
Controlled Production Effect
          ↓
Independent Effect Verification
          ↓
Assurance Evidence Plane
          ↓
Claim–Argument–Evidence Graph
          ↓
Assumption / Defeater Analysis
          ↓
Independent Assurance Assessment
          ↓
Scoped Governance Decision
          ↓
Continuous Reassessment

这条链并不表示全部组件目前已部署，而是项目目标架构。

前面的机制回答：

系统怎样运行、限制危险行为、生成可信证据。

后面的 Assurance Case 回答：

这些证据为什么足以支持当前提出的治理主张。

当 Policy、代码、模型或外部环境变化，Assurance Case 要识别影响并重新评估。

这才接近真正持续保证，而不是一次性合规审查。

---

结语：可信的 AI Agent 系统，不仅需要证据，还需要能够经受反驳的论证

过去几篇，我们为 AI Agent 建立越来越严格的生产约束。

第（四十二）篇研究全局安全结论。

第（四十三）篇将治理规则编译进执行边界。

第（四十四）篇约束治理权本身。

第（四十五）篇用形式化方法寻找危险状态和规则冲突。

第（四十六）篇将经过验证的约束推进到生产运行时。

第（四十七）篇建立可独立验证的证据平面。

但直到第（四十八）篇，我们才进一步面对：

事实本身不会自动证明一个结论。

有效数字签名不能证明业务声明真实。

完整日志不能证明所有必要事件已记录。

正确的 Policy Decision 不能证明不存在绕过路径。

成功的模型检查不能证明未建模的行为也安全。

一百项通过的测试不能自动覆盖未知的高风险入口。

因此，治理系统不能只不断增加 Logs、Tests、Approvals、Signatures、Attestations。

还必须明确：

我们希望证明什么？

为什么这些证据足以支持结论？

哪些前提必须成立？

哪些事实可能推翻它？

哪些风险尚未解决？

当前结论适用于哪个版本、环境和操作范围？

最终形成：

Governance Claim
       ↓
Explicit Context
       ↓
Argument Structure
       ↓
Required Subclaims
       ↓
Verified Evidence
       ↓
Assumption Validation
       ↓
Defeater Investigation
       ↓
Independent Assessment
       ↓
Scoped Assurance Decision
       ↓
Continuous Reassessment

这就是 Assurance Case Automation for SEO/GEO Autonomous Systems。

相比传统自动化检查，它最重要的变化不是增加工具，而是：

系统能说明自己为什么支持某项安全结论，也能在新证据出现时承认原结论不再充分。

Assurance Case 不是安全的无条件数学证明，也不能取消组织责任。

它将主张、推理、证据、假设、反证和决策责任组织在一起，让安全判断透明、可审查、可反驳、可维护。

Trustworthy autonomy requires more than verified evidence. It requires an explicit, challengeable, and continuously maintained argument explaining why the evidence is sufficient for the claim being made.

可信自治不仅需要经过验证的证据，还需要一套明确、能接受反驳并持续更新的论证，解释这些证据为什么足以支持相应安全主张。

由此，从 Evidence-verifiable Autonomous Governance System 推进到：

Evidence-backed and Argument-verified Autonomous Governance System。

官方标准与研究依据

1. ISO/IEC/IEEE 15026-2:2022 — Assurance Case

该标准规范 Assurance Case 的结构、术语及其含义，适用于 Assurance Case 的开发与维护。

需要特别注意，它不保证 Assurance Case 内容质量，也不要求必须采用特定图形表示。

官方来源：

https://www.iso.org/standard/80625.html

https://standards.ieee.org/ieee/15026-2/10236/

2. Goal Structuring Notation Community Standard Version 3

GSN Community Standard 为结构化安全论证提供表达方法与实践指导。

本文借鉴 Goal、Strategy、Context、Assumption、Justification、Solution 等要素的组织思想。

官方来源：

https://scsc.uk/gsn-standard

3. OMG Structured Assurance Case Metamodel

OMG SACM 提供机器可处理的 Assurance Case 论证和证据元模型，可支持结构化表达、交换及管理。

截至本篇研究时间，2.3 为正式版本，2.4 为 Beta 阶段。

官方来源：

https://www.omg.org/spec/SACM

https://www.omg.org/spec/SACM/2.3

4. UK AI Security Institute — Safety Cases

英国 AI Security Institute 研究安全论证在 AI 系统中的应用，强调安全主张、证据与二者之间的论证关系。

相关研究也承认，对于高能力 AI 系统，如何建立完整可靠的 Safety Case 仍存在开放问题。

官方来源：

https://www.aisi.gov.uk/blog/how-can-safety-cases-be-used-to-help-with-frontier-ai-safety

https://www.aisi.gov.uk/blog/safety-cases-at-aisi

5. NIST AI Risk Management Framework 1.0

NIST AI RMF 1.0 通过 Govern、Map、Measure、Manage 四个功能，为 AI 风险识别、评估、监测和治理提供框架。

本文借鉴持续风险管理和独立评估思想，不将其等同于特定 Assurance Case 自动化规范。

官方来源：

https://airc.nist.gov/airmf-resources/airmf/5-sec-core/

6. UK Defence Science and Technology Laboratory — Assurance of AI and Autonomous Systems

该研究讨论如何结合支持可信性的正向证据与挑战系统行为的负向证据，并利用 Assurance Case 组织与表达相关论证。

官方来源：

https://www.gov.uk/government/publications/assurance-of-ai-and-autonomous-systems-a-dstl-biscuit-book/assurance-of-artificial-intelligence-and-autonomous-systems-a-dstl-biscuit-book

7. Assurance 2.0 — Robin Bloomfield、John Rushby 等研究

Assurance 2.0 研究强调更严格的论证推理、证据质量、Defeater Analysis、反证调查和剩余不确定性管理。

本文对 Assumption、Defeater、Confidence 多维评估的讨论借鉴相关研究，不代表所有术语和状态都属于官方标准要求。

研究来源：

https://www.csl.sri.com/users/rushby/abstracts/sss21

https://www.csl.sri.com/users/rushby/abstracts/confidence22

https://arxiv.org/abs/2405.15800

8. UK AI Security Institute — AI Control Safety Case

研究探索围绕 AI 系统控制机制建立结构化安全论证，并解释为什么测试结果仍需额外推理才能支持更广泛部署安全结论。

官方来源：

https://www.aisi.gov.uk/research/a-sketch-of-an-ai-control-safety-case

本项目原创工程设计与边界

本篇将现有 Assurance Case、GSN、SACM、AI 风险管理和 Assurance 2.0 研究组合为 SEO/GEO 自动化工程治理设计：

• SEO/GEO Assurance Case Automation
• Scoped Publishing Safety Claim
• Assurance Argument Graph
• Claim–Evidence Traceability Registry
• Evidence Sufficiency Assessment
• Write-path Coverage Argument
• Defeater Registry
• Assumption Validity Registry
• Confidence Profile
• Claim Invalidity Propagation
• Impact-based Case Reassessment
• Independent Assurance Assessment
• Assurance Argument Game Day
• Continuous Assurance Case
• Evidence-backed and Argument-verified Autonomous Governance System

这些机制属于项目工程方案，不代表 ISO、OMG、GSN、NIST 或英国 AI Security Institute 联合发布了相应的 SEO/GEO Agent 自动化治理标准。

本文的 YAML、伪代码和状态机均是工程设计示例，不意味着这些机制已经部署在现有 SEO Publisher 生产仓库中，也不意味着已经完成正式安全认证。

第（四十九）篇预告：Governance Decision Intelligence——当安全论证仍存在不确定性，怎样决定继续、限制、暂停或升级审批？

第（四十八）篇解决：

怎样判断真实证据是否足以支持明确的安全主张？

但是生产系统很少能获得绝对完整、永远不变的证据。

例如：

某些 Evidence 已验证。

部分 Assumption 仍有效。

一个低风险 Defeater 尚未关闭。

系统出现轻微 Assurance Drift。

此时应该如何行动？

立即停止全部自动化？

允许低风险任务继续？

暂停高风险发布？

要求新的 Governance Quorum？

还是进入 Containment？

下一篇建议研究：

Governance Decision Intelligence / Assurance-based Authorization / Risk-aware Decision Gate / Residual Risk Acceptance / Uncertainty-aware Governance / Decision Provenance / Human Escalation / Adaptive Autonomy / Controlled Degradation / Governance Decision Optimization

架构：

Assurance Case Assessment
          ↓
Evidence Sufficiency
          ↓
Residual Risk Analysis
          ↓
Current Runtime Context
          ↓
Governance Authority
          ↓
Decision Strategy
          │
    ┌─────┼──────┬──────┐
    ↓     ↓      ↓      ↓
  ALLOW  LIMIT   HOLD  ESCALATE
                  │
                  ↓
              CONTAINMENT

从：

我们是否拥有足以支持安全主张的证据与论证？

继续推进到：

论证存在剩余不确定性时，系统怎样作出可解释、受授权约束、与风险相称的生产决策？

目标：

Assurance-informed and Risk-governed Autonomous System。