Policy-as-Code：为什么 AI Agent 的治理规则必须成为真正的生产控制？｜SEO / GEO 自动化治理（四十三）

核心主题： Policy-as-Code / Global Invariant Compiler / Proof-carrying Handoff / Runtime Verification / Policy Decision Point / Policy Enforcement Point / Evidence-bound Authorization / Governance CI/CD / Policy Regression Testing

研究日期：2026 年 10 月 16 日

研究定位： AI Agent 生产安全、SEO/GEO 自动化、分布式治理、策略工程与可验证自治系统

---

一家工业设备出口企业已经建立了一条完整的 AI 内容生产链。

Research Agent 负责研究。Writer Agent 负责写作。Fact Check Agent 负责事实核验。Editorial Agent 负责终审。Publisher Agent 负责 WordPress 发布。

整个系统还有一套详细的治理规范：

未经验证的产品参数不能公开。

未经批准的文章不能发布。

普通内容发布不能修改 robots.txt。

审批后的正文如果再次修改，必须重新审核。

Agent 不得操作授权范围之外的网站资源。

这些规则被写进了 Prompt、SOP 和项目规范。

从文档上看，治理体系已经相当完善。

直到有一天，一篇尚未完成最终审核的文章被直接发布。

调查发现，Publisher Agent 收到了一组看起来完全正常的字段：

{
  "review_status": "approved",
  "publish_allowed": true,
  "fact_check": "pass"
}

Publisher 根据这些信息调用：

POST /wp-json/wp/v2/posts

并提交：

{
  "status": "publish"
}

WordPress 成功创建文章。

但是所谓 approved，并不是独立审核系统签发的审批证明。它只是另一个 Agent 输出中的一个字段。

所谓 fact_check = pass，也没有绑定具体文章版本。

Writer 在审核之后又修改了正文。

最终被发布的内容，并不是原来被批准的版本。

整个自动化流程却依然显示：

Research      SUCCESS
Writing       SUCCESS
Fact Check    SUCCESS
Editorial     SUCCESS
Publishing    SUCCESS

问题不在于系统没有治理规则。

恰恰相反。

这是一个拥有很多治理规则，却没有让规则真正控制生产行为的系统。

因此，第（四十三）篇要解决的问题已经不再是：

应该制定什么规则？

而是：

怎样让规则真正拥有阻止生产操作的能力？

也就是从：

Governance Documentation

继续推进到：

Machine-enforceable Governance

一、为什么“Agent 知道规则”仍然不够？

在此前的治理体系中，我们已经逐步解决了多个问题。

Authority Graph 解决谁拥有什么权限。

Workload Identity 解决谁正在执行。

Intent Binding 解决为什么执行。

AI Supply Chain 解决使用了哪个模型、Prompt、工具和数据。

Continuous Assurance 解决已经获得的权限是否仍然合理。

Runtime Containment 解决出现风险以后如何立即停止。

Recovery Proof 解决恢复以后为什么可以重新获得权限。

第（四十二）篇进一步建立：

Cross-Agent Evidence Graph
        ↓
Global Invariants
        ↓
Distributed Evaluation
        ↓
System-wide Safety Case

但即使系统已经知道：

Global Invariant = FAIL

如果 Publisher Agent 仍然可以直接访问 WordPress，那么违规操作在技术上依然可能发生。

也就是说：

Policy Exists
≠
Policy Enforced

如果执行架构仍然是：

Agent
  ↓
WordPress REST API

那么最后一道控制仍然依赖 Agent 自己。

真正的生产架构应该逐渐转变成：

Agent
  ↓
Action Request
  ↓
Trusted Context Builder
  ↓
Policy Decision Point
  ↓
Policy Enforcement Point
  ↓
Effect Gateway
  ↓
WordPress

Agent 可以提出：“我要发布这篇文章。”

但 Agent 不应该自行决定：“所以我现在可以发布。”

提出行为与批准行为必须分离。

二、Policy-as-Code 到底是什么？

Open Policy Agent 将 Policy-as-Code 的基本思想体现得非常清楚：

应用向独立策略引擎提交结构化输入，策略引擎根据策略和数据返回决策，应用再负责执行这一决策。

OPA 使用声明式语言 Rego 处理 API 请求、配置数据及其他结构化文档，同时将 Policy Decision 与实际 Policy Enforcement 分离。

官方文档：https://www.openpolicyagent.org/docs/

这类架构对 Agent 系统尤其重要。

因为我们不再希望：

LLM reads policy
→ LLM interprets policy
→ LLM decides whether it may act

而希望变成：

Agent proposes action
→ deterministic policy evaluates action
→ enforcement boundary accepts or rejects action

因此，Policy-as-Code 不能仅仅理解成：

把 SOP 写进 JSON。

例如：

{
  "require_fact_check": true
}

本身并不能解决什么。

系统仍然需要回答：

谁完成了 Fact Check？

它验证了什么？

验证的是不是当前文章版本？

证据是不是可信？

审批是否已经过期？

如果文章重新修改，原审核是否仍然有效？

如果策略服务发生异常，该请求是否继续？

因此：

机器可读规则，不等于机器可执行治理。

真正的生产级 Policy-as-Code 至少必须连接：

Policy
+
Trusted Evidence
+
Authorization
+
Runtime State
+
Enforcement Point

三、先不要急着写 Rego：必须把治理问题分层

一个常见错误，是把所有规则全部交给一个 Policy Engine。

例如：

产品参数是否真实？

文章是否有原创价值？

Publisher 是否允许发布？

Canonical 是否正确？

是否可以修改 robots.txt？

是否超出 Autonomy Budget？

这些问题实际上属于不同类型。

可以拆成四层。

例如：“文章是否真正有用户价值”通常属于语义判断。

“Writer 是否可以修改 robots.txt”则属于确定性权限问题。

“关键产品参数是否拥有有效证据”属于 Evidence Policy。

“审核以后内容 Hash 改变”属于 Runtime Safety Policy。

这四者不能完全由同一种技术替代。

语义问题交给语义系统，身份问题交给授权系统，事实问题交给证据系统，最终写入由执行边界强制控制。

四、OPA、CEL、Cedar 分别给我们什么启发？

OPA / Rego：通用 Policy Decision Point

OPA 是通用策略引擎。

Rego 可以对结构化数据进行声明式评估，因此非常适合：

identity
action
resource
approval
evidence
runtime

这样的综合授权输入。

OPA 也支持 Decision Logs，其中可以记录策略查询、输入、Bundle 信息以及 decision_id 等字段，为审计和离线调查提供基础。

官方资料：

https://www.openpolicyagent.org/docs/

https://www.openpolicyagent.org/docs/management-decision-logs

OPA Bundle 机制还允许 Policy 和相关数据以 Bundle 形式分发和更新。

https://www.openpolicyagent.org/docs/management-bundles

但要注意：

OPA 可以判断：

input.approval.valid == true

它不会自动证明这个 true 是否来自可信审批系统。

策略引擎不是事实制造机。

CEL：轻量级确定性条件验证

CEL 适合在应用程序中嵌入受限表达式检查。

Kubernetes ValidatingAdmissionPolicy 就使用 CEL 对 API 请求执行验证。

更值得 SEO/GEO 自动化借鉴的是它的 Enforcement 模式。

Kubernetes 的相关 Binding 可以使用：

Deny
Warn
Audit

不同的 validation action。

同时，failurePolicy 可以配置部分策略执行错误是 Fail 还是 Ignore。

官方资料：

https://cel.dev/

https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/

这为 Agent 治理提供了一个非常有价值的模式：

AUDIT
↓
WARN
↓
DENY

也就是说，新 Policy 不必第一天就直接阻断生产。

可以先观察。

然后告警。

最后正式强制执行。

但这只是 Kubernetes 提供的具体功能。

WordPress 本身并不会自动提供同样的 Agent Policy Admission Layer。

如果我们需要这一能力，就必须在 Publishing Gateway 中建设。

Cedar：Authorization Policy

Cedar 重点解决：

Principal
Action
Resource
Context

之间的授权。

其授权算法包含 Default Deny，以及 Forbid Overrides Permit。

这使它非常适合表达资源授权边界。

但是这里有一个重要的工程细节。

Cedar 官方文档说明：某一条 Policy 求值出错时，该 Policy 会被跳过，并通过 diagnostics 报告相关错误。

官方资料：

https://docs.cedarpolicy.com/auth/authorization.html

因此不能简单认为：

Cedar Error
→
Automatically Deny Everything

如果某个安全关键 forbid 规则因为输入错误而无法计算，它可能被跳过。

这意味着宿主应用必须检查 diagnostics，并决定高风险操作是否应该 Fail-Closed。

这正说明：

策略语言自身的默认语义，并不能替代整个系统的安全设计。

五、Global Invariant Compiler：从自然语言约束到 Policy Artifact

第（四十二）篇已经建立了 Global Invariants。

例如：

未经验证的关键产品参数不得正式发布。

现在的问题是：

怎样让它变成生产系统可以执行的东西？

本项目提出：

Global Invariant Compiler。

这里的 Compiler 不是指已经存在一个能够自动把中文制度转换成安全 Rego 的成熟产品。

它是一套策略工程过程。

Human-approved Policy
        ↓
Policy Classification
        ↓
Typed Specification
        ↓
Schema Validation
        ↓
Semantic Review
        ↓
Policy Intermediate Representation
        ↓
Target Policy
        ↓
Test
        ↓
Approved Policy Artifact

例如原始自然语言规则：

未经验证的关键产品参数不得发布。

首先转成规范化定义：

policy_id: SEO-PUBLISH-001

subject:
  action: wordpress.publish

condition:
  critical_claims_verified: REQUIRED

failure:
  action: DENY

fallback:
  allow_draft: true

然后才能进一步转换成 Rego、CEL 或其他目标策略。

为什么不能直接让 LLM 自动生成 Policy 并部署？

因为 Natural-language Meaning 到 Executable Logic 之间可能发生语义损失。

例如原规则：

所有关键 Claim 必须完成验证。

错误转换后可能变成：

至少一个 Claim 已验证

或者：

存在 Fact Check 记录

这两者都不等价。

所以 Global Invariant Compiler 必须包含 Policy Conformance Testing。

即：

目标 Policy 是否真正保留原始治理要求？

LLM 可以帮助生成初始策略。

但：

被治理的模型，不应该自动批准并部署约束自己的最终 Policy。

六、从一条 SEO 发布规范开始

假设规则是：

未经验证的关键产品参数不得进入正式发布状态。

我们可以首先定义项目级 Policy Specification：

policy_id: SEO-PUBLISH-001
version: 1.0.0

applies_to:
  action: wordpress.publish
  resource_type: article

requirements:
  approval_required: true
  critical_claims_verified: true
  approved_artifact_match: true

trusted_evidence:
  verification_issuer: fact-verification-service
  approval_issuer: editorial-approval-service

failure_behavior:
  missing_evidence: DENY
  invalid_evidence: DENY
  policy_error: DENY

fallback:
  save_draft: conditional

governance:
  owner: content-governance
  status: approved

这不是 WordPress 官方 Schema。

是本项目建议的 Governance Schema。

这里特别使用：

save_draft: conditional

而不是：

save_draft: always

因为保存草稿仍然属于写操作。

如果 Agent 根本没有该网站的写权限，就不能因为 publish denied 自动获得 draft write permission。

降级不是越权。

七、把规则写成 Rego，只完成了其中一半

可以设计类似下面的规则：

package seo.publish

import rego.v1

default allow := false

allow if {
    input.action == "wordpress.publish"

    input.identity.verified == true

    input.authorization.valid == true

    input.authorization.site_id == input.resource.site_id

    input.authorization.safety_epoch ==
        input.runtime.safety_epoch

    input.approval.valid == true

    input.approval.artifact_digest ==
        input.artifact.digest

    input.claims.critical_unverified == 0

    input.assurance.status == "PASS"

    input.effect.remaining_budget > 0
}

这里实现了一个很重要的原则：

default allow = false

证据不充分的请求不会自动获得生产授权。

但是这段 Policy 仍然依赖大量输入：

identity.verified
authorization.valid
approval.valid
critical_unverified
assurance.status

这些值从哪里来？

如果全部由 Publisher Agent 自己提交：

{
  "identity": {
    "verified": true
  },
  "approval": {
    "valid": true
  }
}

那么 Policy Engine 只是帮助 Agent 验证自己的声明。

这显然不够。

因此必须进入下一层：

Evidence-bound Authorization。

八、Evidence-bound Authorization：权限必须绑定证据

过去的授权模式可能是：

Publisher Agent
→ can_publish = true

问题是：

这个权限往往过于宽泛。

更安全的授权应表达成：

谁
在什么时间
因为什么任务
针对哪个站点
针对哪个 Artifact
允许执行什么 Effect

例如：

authorization_id: AUTH-043-001

subject:
  workload_id: seo-publisher
  workload_identity: VERIFIED

intent:
  intent_id: INTENT-043-001

resource:
  site_id: SEO-CN
  content_id: ARTICLE-043

artifact:
  digest: sha256:2b49...

action:
  type: wordpress.publish

constraints:
  max_effects: 1
  allowed_status:
    - publish

evidence:
  editorial_approval: APR-043-001
  fact_verification: FACT-043-001
  workflow_assurance: ASSURE-043-001

runtime:
  safety_epoch: 47

validity:
  not_before: 2026-10-16T14:00:00Z
  expires_at: 2026-10-16T16:00:00Z

这依然是本项目 Schema 示例。

它意味着：

Publisher 获得的不是“你可以发布文章”，而是：

你可以在有限时间内，针对指定站点，发布这一个已经批准的 Artifact，最多产生一次相应 Effect。

这就是 Evidence-bound Authorization。

九、Artifact Digest：解决“审核的是 A，发布的是 B”

这是生产自动化中非常关键的一步。

Editorial Agent 审核了文章 A。

审批通过。

之后 Writer Agent 修复了一句话。

文章变成 B。

如果批准记录只是：

{
  "approved": true
}

Publisher 仍然可能发布 B。

因此，Approval 必须绑定 Artifact Digest。

例如：

Approved Artifact:
sha256:AAA

Current Artifact:
sha256:BBB

当：

AAA ≠ BBB

系统应该输出：

APPROVAL_INVALIDATED

而不是继续相信原来的 approved=true。

核心原则是：

Approval
=
Approval of a Specific Artifact

而不是：

Approval
=
Permanent Approval of a Topic

这会直接阻断一种常见风险：

审核以后再修改正文。

十、Proof-carrying Handoff：Agent 交接不能只传一个答案

第（四十二）篇已经讨论过 Handoff。

现在进一步要求：

Handoff 不仅传递 Artifact，还要携带能够被下游验证的证据。

例如 Research Agent 交给 Writer：

{
  "research": "...",
  "ready": true
}

这种结构几乎没有安全意义。

更好的设计是：

handoff:
  handoff_id: HOF-043-001
  workflow_id: WF-043-001

from:
  workload_id: research-agent

to:
  workload_id: writer-agent

artifact:
  id: RESEARCH-043
  digest: sha256:abc123

claims:
  - claim_id: CLM-043-001
    status: VERIFIED
    evidence_ref: SOURCE-101

  - claim_id: CLM-043-002
    status: UNKNOWN
    evidence_ref: null

constraints:
  publishable: false
  draft_use: true
  independent_verification_required:
    - CLM-043-002

policy:
  version: POLICY-BUNDLE-62

attestation:
  issuer: research-assurance-service
  attestation_id: ATT-043-001

下游 Writer 不能把：

CLM-043-002 = UNKNOWN

自动变成：

CLM-043-002 = TRUE

除非系统获得新的验证证据。

因此，Handoff Gate 应该检查：

Artifact Digest
Issuer
Audience
Workflow ID
Claim State
Constraints
Policy Version
Expiration

然后才允许进入下一阶段。

这就是本文所说的：

Proof-carrying Handoff。

这里的 Proof 主要是可验证的证据、签发记录与约束，而不是声称已经实现形式化数学证明。

十一、Proof-carrying Handoff 最重要的不是“签名”，而是语义不能丢

即使 Handoff 使用数字签名，也不意味着里面的结论一定正确。

签名能够帮助证明：

这份 Envelope 没有被未经授权地修改

以及：

它由某个可验证主体签发

但签名不能证明：

产品参数本身一定真实

例如：

Claim:
18 kW

Issuer:
Research Agent

Signature:
VALID

只说明 Research Agent 确实签发了这条结论。

不能说明现实设备一定是 18 kW。

因此必须区分：

Integrity of Evidence

与：

Truth of Claim

两者不是同一个问题。

这也是为什么需要 Source of Truth、Provenance 和 Fact Verification。

十二、Policy Decision Point 与 Policy Enforcement Point 必须分离

生产系统中，应当明确区分：

PDP — Policy Decision Point

负责回答：

ALLOW?
DENY?
REQUIRE_REVIEW?
ALLOW_WITH_CONDITIONS?

例如 OPA 可以承担这一职责。

PEP — Policy Enforcement Point

负责真正阻止或者允许执行。

例如 WordPress Publishing Gateway 可以充当 PEP。

OPA 官方架构本身也强调 Policy Decision 与 Policy Enforcement 的解耦。

在 SEO 自动发布中：

OPA says DENY

如果 Publisher 仍然能够绕开 Gateway 直接访问 WordPress，那么 Policy 没有真正被 Enforcement。

因此生产架构必须满足：

No privileged production path
bypasses the PEP

也就是：

任何拥有实际生产效果的路径，都必须经过策略执行点。

十三、WordPress Publishing Gateway 应该怎样设计？

WordPress REST API 支持创建文章，并允许 status 使用 publish、draft、pending、private 等状态。

官方资料：

https://developer.wordpress.org/rest-api/reference/posts/

WordPress 自身也会根据用户 Capability 检查是否有权执行相关发布操作。

但这些机制主要回答的是：

这个 WordPress 用户是否拥有相应 Capability？

而我们的 Agent Governance 还要回答：

这一次具体工作流，
是否有资格发布这一个具体 Artifact？

这是更细粒度的问题。

因此建议架构为：

Publisher Agent
      ↓
Publish Request
      ↓
Cloudflare / Publishing Gateway
      ↓
Verify Workload Identity
      ↓
Load Workflow State
      ↓
Verify Approval
      ↓
Verify Artifact Digest
      ↓
Verify Evidence
      ↓
Evaluate Policy
      ↓
Consume Effect Budget
      ↓
Call WordPress REST API
      ↓
Read Back WordPress State

也就是说：

WordPress 原生 Capability 是底层权限，Publishing Gateway 是业务授权层。

两者应该叠加，而不是互相替代。

十四、Runtime Verification：策略通过以后还不能结束

假设：

14:00:00
Policy Decision = ALLOW

但是 Agent 到：

14:00:15

才真正执行写入。

这十五秒内可能发生什么？

文章内容被修改。

授权被撤销。

Safety Epoch 已更新。

事故响应启动。

资源 Lease 已被另一个工作流占用。

目标站点进入维护模式。

因此：

Policy Decision at T1

不能无限期授权：

Effect at T2

需要建立：

Runtime Verification。

在真正执行外部效果之前重新验证关键条件。

例如：

T0
Intent Approved

T1
Policy ALLOW

T2
Pre-effect Runtime Check

T3
WordPress Write

T4
Post-effect Verification

T2 至少重新检查：

Authorization still valid?
Safety Epoch current?
Artifact unchanged?
Lease valid?
Effect budget available?
Target resource unchanged?

这就是 Continuous Authorization 在实际 Effect Boundary 上的具体实现。

十五、TOCTOU：Policy-as-Code 中一个经常被忽略的问题

这类问题在安全工程中常称为：

Time-of-check to Time-of-use，TOCTOU。

也就是：

检查时成立的条件，执行时可能已经改变。

例如：

14:00:00
Post ID 128 belongs to ARTICLE-A

系统批准更新。

但是：

14:00:03
另一个工作流修改了资源绑定

到：

14:00:05
Agent 开始写入

原来的批准可能已经不再适用。

因此，高风险 Effect 不能只依赖较早产生的授权结果。

需要结合：

Resource Version
ETag / Version
Lease
Safety Epoch
Artifact Digest

重新核对。

这也是为什么 Policy Decision Receipt 应该包含上下文版本，而不能只是 allow=true。

十六、Policy Decision Receipt：每次放行都应该留下证据

一次生产授权至少应该产生：

decision_id: DEC-043-001

workflow_id: WF-043-001
intent_id: INTENT-043-001

subject:
  workload_id: seo-publisher

action:
  wordpress.publish

resource:
  site_id: SEO-CN
  content_id: ARTICLE-043

artifact:
  digest: sha256:abc123

policy:
  bundle_version: POLICY-62
  decision: ALLOW

evidence:
  approval: APR-043-001
  fact_check: FACT-043-001
  assurance: ASSURE-043-001

runtime:
  safety_epoch: 47

timestamp:
  evaluated_at: 2026-10-16T14:22:31Z

OPA 的 Decision Logs 可以记录查询输入、Policy Bundle 元数据和 decision_id，为类似审计体系提供技术基础。

但是，本项目中的完整 Decision Receipt 仍然属于自定义治理模型。

十七、Effect Budget：即使 Policy 允许，也不能无限重复执行

假设 Publisher 获得了 ALLOW。

它连续提交三次完全相同的发布请求。

结果创建三篇文章。

每一次请求单独看，都可能符合 Policy。

但最终业务效果错误。

因此 Policy 必须与之前建立的 Effect Budget 连接。

例如：

effect:
  type: CREATE_POST
  max_count: 1
  consumed: 0

第一次执行：

remaining_budget = 1

允许。

成功后：

consumed = 1

再次请求：

remaining_budget = 0

拒绝。

这意味着：

Authorization 不只是能不能做，还应该约束可以做多少次。

十八、Policy Error 应该怎么处理？

这是 Policy-as-Code 中非常关键的问题。

策略系统可能发生：

Schema 不兼容。

输入字段缺失。

Policy 编译错误。

Policy Service 不可访问。

Bundle 更新失败。

未知 Policy 版本。

如果系统统一采取：

Policy Error
→
Allow

那么故障本身就会变成安全绕过路径。

但如果所有错误都统一：

Policy Error
→
Stop Everything

又可能导致低风险系统完全不可用。

更合理的方式是按照 Effect Risk 分类。

核心原则：

Fail behavior
must match effect risk.

尤其对于 publish、delete、bulk update 和 technical SEO infrastructure，不应该因为 Governance Service 出现故障而自动放行。

十九、Policy 也需要版本控制

Agent 系统经常对模型和 Prompt 做版本管理，却忽略 Policy。

例如：

POLICY-61

允许 Editorial Approval + Fact Check 即可发布。

后来发现需要新增 Critical Claim Provenance。

于是升级到：

POLICY-62

如果 Workflow 在旧规则下开始，又在新规则上线以后继续运行，该使用哪个版本？

不能模糊处理。

建议 Decision Receipt 中明确记录：

policy_bundle_version
policy_schema_version
workflow_policy_epoch

Policy 变更还应该明确：

是否兼容已有任务？

是否使旧批准失效？

是否需要重新 Evaluation？

是否需要重新 Re-admission？

这就是：

Policy Versioning。

二十、Governance CI/CD：Policy 本身也要进入软件工程流程

Policy-as-Code 最大的价值之一，是治理规则终于可以进入 CI/CD。

过去：

治理文档修改
→
发通知
→
希望大家照做

现在可以变成：

Policy Change
      ↓
Pull Request
      ↓
Static Validation
      ↓
Unit Test
      ↓
Regression Test
      ↓
Shadow Evaluation
      ↓
Approval
      ↓
Staged Deployment
      ↓
Runtime Monitoring

Governance 不再只是文件管理。

它开始拥有：

Code Review
Version Control
Testing
Deployment
Rollback

这就是：

Governance CI/CD。

二十一、GitHub 应该怎样参与 Governance CI/CD？

GitHub Actions 可以承担 Policy 测试和部署流水线。

GitHub Environments 还可以在适用的仓库与套餐条件下配置 Required Reviewers、分支限制、环境 Secrets 和 Deployment Protection Rules，使生产部署在保护条件满足以后再运行。

官方资料：

https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments

例如：

policy/
  seo/
    publish.rego
    robots.rego
    redirect.rego

tests/
  policy/
    publish_test.rego
    robots_test.rego

schemas/
  policy-input.schema.json

Pull Request 可以运行：

Syntax Validation
Schema Validation
Unit Tests
Regression Tests
Forbidden Policy Pattern Check

通过以后才能合并。

生产 Policy Deployment 还可以进一步要求 Required Reviewer 批准。

这样，一个 Agent 就无法自己完成：

修改 Policy
→
批准 Policy
→
部署 Policy
→
利用 Policy 获得更大权限

这就是 Separation of Duties。

二十二、Policy Regression Testing：治理升级不能让旧安全约束消失

假设 Policy v1：

未审核文章不得发布。

Policy v2 新增：

需要 Source Provenance。

但开发者在重构时意外删除了原来的 Approval 检查。

新策略功能更多，安全性反而下降。

因此必须建立：

Policy Regression Test Suite。

至少测试：

未经审核 → DENY
审核通过 → 可继续其他检查
Artifact 变化 → DENY
关键 Claim UNKNOWN → DENY
Safety Epoch 过期 → DENY
错误站点 → DENY
重复 Effect → DENY
Policy 输入缺失 → DENY
robots.txt 非授权修改 → DENY

同时测试合法业务：

合法文章
+
合法证据
+
合法授权
+
合法资源
→
ALLOW

否则就可能建立一个永远 DENY 的“安全系统”。

Policy Testing 的目标不是让所有测试都拒绝，而是：

正确请求被正确允许，
错误请求被正确拒绝。

OPA 官方支持通过 opa test 执行 Rego 测试，并可通过 opa fmt 与 opa check 等命令进行格式和静态检查。

官方资料：

https://www.openpolicyagent.org/docs/cli/

二十三、建立 Golden Policy Cases

随着 Policy 数量不断增长，建议维护一批：

Golden Policy Cases。

例如：

case: approved_article_publish
expected: ALLOW

case: content_changed_after_approval
expected: DENY

case: unknown_product_specification
expected: DENY

case: expired_authorization
expected: DENY

case: save_draft_without_publish_authority
expected: CONDITIONAL

case: modify_robots_from_content_workflow
expected: DENY

这些 Case 成为治理规则的行为契约。

以后无论 Policy 如何重构，都必须维持这些关键安全语义。

二十四、Shadow Policy：不要让新规则第一次就在生产中阻断业务

一项新规则刚创建时，可能存在：

过度严格。

输入数据不完整。

边界条件遗漏。

异常业务未覆盖。

因此，不建议所有新 Policy 一上线就立即成为强制 DENY。

可以借鉴 Kubernetes Admission Policy 的 Audit / Warn / Deny 思路。

Agent Governance 可以设计自己的三个阶段：

OBSERVE
↓
WARN
↓
ENFORCE

OBSERVE

运行 Policy。

记录如果执行的话，会拒绝哪些请求。

但暂时不影响生产。

WARN

允许部分操作继续。

同时生成 Governance Warning。

ENFORCE

确认误报可接受以后，正式阻断不合规操作。

需要明确的是：

新规则进入 OBSERVE，不意味着既有强制安全规则可以暂停。

例如“未经批准不得正式发布”已经属于成熟控制，就不应因为另一个新 Policy 尚处 Shadow 状态而失效。

因此：

Current Mandatory Controls
            +
New Shadow Policy
            ↓
Decision Comparison
            ↓
Policy Tests
            ↓
Canary Enforcement
            ↓
Scoped Production Rollout

二十五、Policy Promotion Gate：从 Observe 到 Enforce 也必须有证据

不能因为：

新 Policy 已运行七天。

就自动进入强制模式。

时间不是充分证据。

应该检查：

Shadow Evaluation Coverage
False Positive Review
Expected Deny Cases
Unexpected Deny Cases
Schema Compatibility
Performance Impact
Policy Error Rate

只有符合预定义标准以后，才允许：

OBSERVE
→
WARN
→
ENFORCE

这与前面建立的 Agent Re-admission 很相似。

Policy 本身也应该经过逐级准入。

二十六、Policy Rollback：治理策略也可能制造生产事故

错误 Policy 可能导致：

所有发布任务被拒绝。

合法页面无法更新。

错误站点获得授权。

某些安全检查意外失效。

因此必须准备：

Policy Rollback。

但这里也不能简单恢复到 previous version 就结束。

Rollback 以后至少要验证：

旧版本仍然满足当前最小安全条件。

导致 Rollback 的错误规则是否已经停止生效。

Rollback 期间产生的错误决策是否需要 Effect Reconciliation。

哪些 Workflow 需要重新 Evaluate。

也就是说：

Policy Recovery 同样需要 Recovery Proof。

二十七、完整 WordPress 示例：一个 Agent 如何被真正阻止发布？

假设 Writer 完成第 43 篇文章。

Artifact：

ARTICLE-043
sha256:AAA

Editorial 审核：

APPROVED
artifact_digest = AAA

Fact Check：

critical_unverified = 0

Workflow Assurance：

PASS

随后 Writer 又修改了一段正文。

当前：

sha256:BBB

Publisher 请求：

{
  "action": "wordpress.publish",
  "artifact": {
    "digest": "BBB"
  }
}

Policy 输入中：

approved digest = AAA
current digest  = BBB

于是 PDP 返回：

DENY
reason:
ARTIFACT_CHANGED_AFTER_APPROVAL

Publishing Gateway 不会调用 WordPress。

整个生产状态保持：

NO EFFECT

Publisher 可以把结果返回给 Workflow：

REQUIRE_REAPPROVAL

经过重新审核后：

approval artifact = BBB

再执行新一次 Policy Evaluation。

最终：

ALLOW

Gateway 才调用 WordPress。

WordPress Posts REST API 支持创建文章并设置 publish、draft、pending 等状态。

官方资料：

https://developer.wordpress.org/rest-api/reference/posts/

发布成功以后仍不能立即结束。

Gateway 应重新读取：

Post ID
Slug
Status
Content

必要时核对 Revision 与公开页面状态。

WordPress REST API 也提供 Post Revisions 相关接口。

官方资料：

https://developer.wordpress.org/rest-api/reference/post-revisions/

于是整个链路变为：

Request
↓
Evidence Verification
↓
Policy
↓
Runtime Verification
↓
WordPress Effect
↓
REST Readback
↓
Effect Verification

这才是：

Policy-enforced Publishing。

二十八、Technical SEO 必须拥有比普通内容更严格的 Policy

不是所有 WordPress 写操作风险相同。

例如：

修改文章正文。

修改 Category。

修改 Canonical。

创建 Redirect。

修改 robots.txt。

更新 Sitemap 生成逻辑。

这几个操作的 Blast Radius 完全不同。

因此应建立 Effect Risk Tier。

例如：

T1
Draft content generation

T2
Single article update

T3
Single article publish

T4
Redirect / Canonical change

T5
Robots / Sitemap / Sitewide template

Risk Tier 越高：

需要越严格的身份要求。

越多的 Evidence。

更短的授权有效期。

更小的 Effect Budget。

更严格的审批。

甚至必须要求人工确认。

例如 Content Publisher 即使拥有 T3 的 publish article 权限，也不应该自动获得 T5 的 modify robots.txt 权限。

这就是：

Capability Segmentation。

二十九、Policy 不能只验证 Action，还必须验证 Resource

一个危险规则可能是：

Publisher may update posts.

这仍然太宽。

更精确的是：

Publisher
may update
Post 1000089
on SITE-A
under INTENT-043
before expiry

资源范围应该至少包含：

Tenant
Site
Resource Type
Resource ID
Operation

必要时再包含：

Field Scope

例如允许修改：

content
excerpt
tags

但禁止修改：

author
site settings
SEO global options

真正安全的 Agent Authorization 应不断从：

Role-based Broad Permission

向：

Intent-scoped Capability

靠近。

三十、Policy 输入本身也必须有 Schema

如果 Policy 预期：

input.approval.valid

但请求中发送：

input.approved

会发生什么？

不同策略语言和具体实现可能产生不同结果。

因此 Policy Input 应拥有严格 Schema。

例如：

{
  "schema_version": "policy-input-v3",
  "workflow_id": "WF-043-001",
  "action": "wordpress.publish",
  "subject": {},
  "resource": {},
  "artifact": {},
  "approval": {},
  "evidence": {},
  "runtime": {}
}

Policy Deployment 前必须测试：

Schema v3
+
Policy v62

是否兼容。

不要允许 Unknown Field、Missing Critical Field、Wrong Type 悄悄变成放行。

对于高风险效果，Schema Error 应被视为：

INSUFFICIENT_TRUSTED_CONTEXT

而不是让 Agent 自行补全缺失字段。

三十一、Policy Provenance：现在轮到治理规则自己接受供应链验证

第（三十八）篇已经讨论 AI Supply Chain。

到了这里，Policy 自己也进入供应链。

因此需要记录：

Policy ID
Version
Source Repository
Commit SHA
Build Artifact Digest
Approver
Deployment Time
Environment

否则发生事故后，可能只知道：

Policy allowed this action.

却不知道：

到底是哪一版 Policy？

这会使审计和回放非常困难。

所以 System-wide Evidence Graph 应加入：

Decision
  ↓
Policy Version
  ↓
Policy Artifact
  ↓
Repository Commit
  ↓
Approval

这就是：

Policy Provenance。

三十二、Governance CI/CD 的完整生命周期

把前面的机制组合起来，可以形成：

Governance Requirement
        ↓
Policy Specification
        ↓
Policy-as-Code
        ↓
Pull Request
        ↓
Static Validation
        ↓
Unit Tests
        ↓
Regression Tests
        ↓
Security Review
        ↓
Shadow Evaluation
        ↓
Policy Approval
        ↓
Signed / Versioned Policy Artifact
        ↓
Staged Deployment
        ↓
Runtime Decision
        ↓
Decision Logging
        ↓
Continuous Evaluation
        ↓
Rollback / Improvement

这意味着 Governance 不再只是：

文档 → 执行

而是拥有完整的软件生命周期。

三十三、必须防止“Agent 修改约束自己的 Policy”

如果一个高权限 Agent 能够：

修改自己的 Prompt。

修改 Policy。

提交 Policy。

批准 Policy。

部署 Policy。

然后继续执行生产任务。

那么所有权限限制都可能被自己解除。

因此必须执行：

Separation of Duties。

至少分离：

Policy Author
Policy Reviewer
Policy Deployer
Production Agent

不一定需要四个人。

其中一部分可以是系统身份。

但不能让同一个权限主体完成所有安全关键动作。

GitHub Environments 可以在适用的仓库和产品条件下对 Deployment 配置 Required Reviewers、分支策略、Environment Secrets 和其他保护规则。

官方资料：

https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments

对于 Governance Repository，这类控制尤其重要。

三十四、Policy Decision 不是永久授权

假设系统在：

16:00

计算：

ALLOW

到了：

16:20

不应该继续无条件复用该结果。

因为这段时间：

Policy 可能升级。

授权可能撤销。

Agent 可能触发风险事件。

Artifact 可能修改。

Safety Epoch 可能更新。

所以 Decision 应具有：

Validity Window

例如：

decision:
  id: DEC-043-009
  result: ALLOW
  valid_until: 2026-10-16T16:05:00Z

对于更高风险操作，甚至不需要缓存 ALLOW。

而是在 Effect Boundary 重新计算。

三十五、Policy Decision 的结果不能只有 Allow / Deny

复杂 Agent 系统至少需要：

ALLOW
DENY
REQUIRE_REVIEW
ALLOW_WITH_CONDITIONS
INSUFFICIENT_EVIDENCE
POLICY_ERROR

例如：

ALLOW_WITH_CONDITIONS

可以保存 Draft
不能 Publish

REQUIRE_REVIEW

需要产品负责人确认技术参数

INSUFFICIENT_EVIDENCE

不是已经发现错误，
而是当前证据不足以支持生产写入。

这几个状态非常重要。

因为：

UNKNOWN

不能自动等同于 FALSE，更不能自动等同于 TRUE。

三十六、治理系统本身也必须可观测

Policy 系统需要自己的 Dashboard。

至少观察：

这些是本项目建议的治理指标。

它们并不是 OPA、WordPress 或 GitHub 规定的统一 KPI。

尤其值得重点监测：

Enforcement Bypass Attempt

因为一个成熟的治理系统，不只是关心 Policy 返回什么。

还应该关心：

是否存在根本没有经过 Policy 的生产操作。

三十七、Policy Bypass Detection：怎么知道有人绕开 Gateway？

假设所有正常发布都有：

decision_id

并写入：

Effect Ledger

但 WordPress 中突然出现新 Post：

POST ID 130

却找不到：

decision_id

系统应该把它标记成：

UNATTRIBUTED_EFFECT

进一步检查：

人工发布？

合法后台编辑？

旧脚本？

泄露凭证？

绕过 Gateway 的 Agent？

因此生产核验可以比较：

Observed WordPress Effects

与：

Authorized Effect Ledger

发现：

Authorized Effect
→ no external result

或：

External Result
→ no authorization

这将第（四十一）篇的 Effect Reconciliation 与 Policy Enforcement 正式连接起来。

三十八、Governance CI/CD 不是只测试“代码能不能运行”

普通 CI：

Syntax
Build
Unit Test

Governance CI 还必须检查：

Policy Semantics
Security Invariants
Backward Compatibility
Decision Changes

例如一个 Pull Request 把：

input.claims.critical_unverified == 0

改为：

input.claims.critical_unverified <= 2

代码完全合法。

测试甚至可以运行。

但治理语义已经从：

零个未验证关键 Claim

变成：

允许两个未验证关键 Claim

因此 Policy PR 应生成：

Decision Diff。

例如：

Golden Cases: 1,200

Previous:
ALLOW 640
DENY 560

Candidate:
ALLOW 684
DENY 516

Newly Allowed:
44

这 44 个 Newly Allowed 应该成为重点审核对象。

因为安全风险经常不是：

Policy suddenly crashes

而是：

Policy silently becomes more permissive.

三十九、建立 Policy Blast Radius Analysis

在部署 Policy v63 之前，应先回答：

哪些 Workflow 会受到影响？

哪些站点？

哪些 Agent？

哪些资源？

哪些已有授权？

哪些待执行任务？

例如：

policy_change:
  from: v62
  to: v63

affected:
  workflows: 127
  active_authorizations: 9
  sites: 3
  high_risk_effects: 4

decision_diff:
  newly_denied: 11
  newly_allowed: 2

这种分析能避免：

一条 Policy 修改以后，所有自动发布任务突然停止。

也能识别更加危险的问题：

新 Policy 意外放宽了两项过去不允许的操作。

四十、Policy Rollout：治理规则也应该分阶段发布

对于高影响策略：

Development
↓
Test
↓
Shadow
↓
Canary
↓
Partial Enforcement
↓
Production Enforcement

例如：

第一阶段只记录 Policy 决策。

第二阶段对少量工作流强制执行。

第三阶段针对单个站点。

第四阶段扩大范围。

这不是要求所有 SEO 项目都建设复杂的全球部署基础设施。

而是在表达一项原则：

治理变化也会制造生产风险，所以 Governance 自己也必须接受发布治理。

四十一、实施 SOP：在现有 SEO Publisher 中怎样逐步部署？

对于已经拥有 GitHub、Cloudflare Worker、WordPress、GSC 和 GA4 的 SEO/GEO 自动发布体系，可以分阶段实施。

Step 1：先建立 Publishing Gateway

禁止 Agent 直接持有或使用能够绕过 Gateway 的 WordPress 生产凭据。

所有自动发布统一经过受控的 Publishing Gateway。

Step 2：建立标准 Action Request

统一请求结构：

Workflow
Intent
Agent
Action
Resource
Artifact
Evidence

Step 3：引入 Artifact Digest

文章进入审核时计算 Digest。

任何会影响批准语义的修改都必须使 Digest 变化。

Step 4：将审批绑定 Artifact

Editorial Approval 不再只是：

approved=true

而是：

approved_digest=XYZ

Step 5：建立最小 Policy Engine

初期只实现几条硬规则：

No approval → deny publish
Artifact changed → deny publish
Wrong site → deny
Stale Safety Epoch → deny
Unverified critical claim → deny

Step 6：建立 Decision Receipt

为每次 Policy Evaluation 生成唯一 ID，并记录 Policy Version 与关键证据引用。

Step 7：执行 Runtime Verification

真正调用 WordPress 前再次检查：

Artifact
Authorization
Safety Epoch
Effect Budget

Step 8：执行 Post-effect Verification

读取 WordPress 实际状态。

核对：

ID
Slug
Status
Content

WordPress Posts REST API 可用于读取这些基本状态。

Step 9：把 Policy 放进 GitHub

策略与测试进入版本控制。

所有修改使用 Pull Request。

Step 10：建立 Policy Regression Suite

固定维护关键 Allow / Deny Case。

Step 11：建立 Shadow → Warn → Enforce

重要新 Policy 先观察，再强制。

Step 12：建立 Policy Monitoring

监测：

Deny
Errors
Bypass
Drift
Decision Diff

到这里，治理体系才真正从 Agent Instructions 进入 Production Controls。

四十二、十二条必须写进工程规范的 Policy Invariants

最后，将整篇文章压缩成可以自动测试的约束。

Invariant 1

Agent Assertion
≠
Trusted Evidence

Invariant 2

Approval
must bind to
Artifact Identity

Invariant 3

Artifact Changed
→
Approval Invalidated

Invariant 4

No Trusted Evidence
→
No High-risk Effect

Invariant 5

Policy ALLOW
≠
Permanent Authorization

Invariant 6

Runtime State Changed
→
Re-evaluate Authorization

Invariant 7

No Production Path
may bypass the PEP

Invariant 8

Policy Version
must be attributable
to every decision

Invariant 9

Critical Policy Error
→
No Silent Allow

Invariant 10

Policy Change
→
Regression Testing

Invariant 11

Newly Allowed Behavior
→
Explicit Review

Invariant 12

Production Effect
without valid Decision Evidence
→
Incident

如果这十二条能够真正落实，Agent Governance 才开始拥有工程意义。

---

结语：治理必须站在 Agent 与生产世界之间

一个真正重要的转变正在发生。

早期 Agent 系统的控制方式通常是：

告诉模型不要做错事。

随后我们开始：

给 Agent 权限边界。

再后来：

记录 Agent 做了什么。

接着：

持续评估它是否值得继续拥有权限。

到了前几篇：

系统可以在事故后停止、恢复并重新证明可信。

而第（四十三）篇进一步提出：

治理规则本身必须进入真正的执行路径。

因为：

Policy in Prompt

只是建议。

Policy in Documentation

只是制度。

Policy in Evaluation

只是判断。

只有：

Policy at Effect Boundary

才真正拥有生产控制能力。

于是完整架构逐渐变成：

Business Intent
      ↓
Agent Workflow
      ↓
Proof-carrying Handoff
      ↓
Trusted Evidence
      ↓
Policy Decision Point
      ↓
Evidence-bound Authorization
      ↓
Runtime Verification
      ↓
Policy Enforcement Point
      ↓
Production Effect
      ↓
Effect Reconciliation
      ↓
Continuous Assurance

这意味着：

Agent 不再需要被信任到：

“请你自己判断是否应该遵守规则。”

而是：

“你可以提出行为，
但生产系统只执行
拥有当前有效证据和授权的行为。”

这是两种完全不同的自治系统。

前者依赖模型自律。

后者依赖架构约束。

因此，第（四十三）篇可以用一句话总结：

Governance is not enforceable until it sits between intent and effect.

治理只有真正站在 Intent 与 Effect 之间，才算成为生产控制。

从第（四十二）篇的：

End-to-End Verifiable Multi-Agent System

我们进一步进入：

Policy-enforced and Evidence-carrying Autonomous Workflow。

而这还不是终点。

因为当越来越多的 Policy、Evidence、Authorization 和 Enforcement Point 被部署以后，我们马上会遇到下一个问题：

谁来治理治理系统本身？

---

官方依据与研究边界

1. Open Policy Agent / Rego

OPA 是通用开源 Policy Engine，可将策略决策与 Enforcement 解耦，并使用 Rego 对结构化数据进行策略评估。OPA 还提供 Decision Logs 与 Bundle 等治理能力。

官方资料：

https://www.openpolicyagent.org/docs/

https://www.openpolicyagent.org/docs/management-decision-logs

https://www.openpolicyagent.org/docs/management-bundles

2. Kubernetes ValidatingAdmissionPolicy

Kubernetes 使用 CEL 实现 ValidatingAdmissionPolicy，并支持 Deny、Warn、Audit 等 Validation Actions；failurePolicy 控制部分策略错误采用 Fail 或 Ignore。本文将这种渐进式 Admission Enforcement 思路借鉴到 Agent Governance，并非声称 WordPress 原生具备相同功能。

官方资料：

https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/

3. Cedar Authorization

Cedar 授权算法具有 Default Deny、Forbid Overrides Permit 和 Skip-on-error 等明确语义。尤其需要注意：单条 Policy Evaluation Error 会被跳过并出现在 diagnostics 中，宿主应用仍需决定高风险操作如何处理错误。

官方资料：

https://docs.cedarpolicy.com/auth/authorization.html

4. GitHub Actions Deployment Environments

GitHub Environments 可以在适用条件下配置 Required Reviewers、分支策略、环境 Secrets 和 Deployment Protection Rules，用于对 Deployment 增加控制。

官方资料：

https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments

5. WordPress REST API

WordPress Posts REST API 支持创建、读取与更新 Posts，并提供 publish、draft、pending、private 等状态。本文在 WordPress 原有权限之上增加项目级 Publishing Gateway，并不意味着 WordPress 官方已经提供本文描述的 Agent Policy Layer。

官方资料：

https://developer.wordpress.org/rest-api/reference/posts/

https://developer.wordpress.org/rest-api/reference/post-revisions/

本项目原创工程设计

以下概念属于本项目在现有 Policy、Authorization、CI/CD 和 Agent 工程能力基础上的组合性设计：

• Global Invariant Compiler
• Policy Intermediate Representation
• Evidence-bound Authorization
• Proof-carrying Handoff Envelope
• SEO/GEO Publishing Gateway
• Agent Runtime Verification
• Policy Decision Receipt
• Policy Effect Budget
• Governance CI/CD
• Policy Decision Diff
• Policy Blast Radius Analysis
• Policy Promotion Gate
• SEO/GEO Policy Regression Suite
• Policy-enforced and Evidence-carrying Autonomous Workflow

这些机制适合继续转化为项目 Schema、GitHub Repository Structure、Cloudflare Worker Gateway 和 WordPress Publishing Control，但不能直接描述成 OPA、Google、WordPress、GitHub、Cedar 或 Kubernetes 已发布的统一 Agent 治理标准。

---

第（四十四）篇预告

下一篇建议继续进入：

Meta-Governance / Policy Authority / Governance Root of Trust / Policy Conflict Resolution / Emergency Override / Break-glass Access / Dual Control / Separation of Duties / Governance Quorum / Constitutional Policy / Policy Recovery

核心问题将从：

怎样让机器执行治理规则？

进一步推进到：

谁有资格制定、修改、覆盖或紧急绕过这些规则？

例如：

Policy Author 能不能修改自己的权限？

Production Admin 能不能绕开 Global Invariant？

发生真正紧急事故时，如何使用 Break-glass？

Emergency Override 怎样避免成为永久后门？

两条 Policy 相互冲突时谁拥有更高优先级？

谁能够修改 Root Policy？

如果 Policy Repository 或 Policy Service 被攻破，整个 Agent 系统如何恢复？

届时将继续形成：

Business Governance
        ↓
Constitutional Policy
        ↓
Delegated Policy
        ↓
Policy-as-Code
        ↓
Runtime Enforcement
        ↓
Governance Evidence
        ↓
Meta-Governance

从：

Policy-enforced Autonomous Workflow

继续进入：

Governance-governed Autonomous System。