SEO / GEO 工作自动化部署与实践规范（二十七）：Action Gateway / Enforcement Point / Capability Token——让 Governance Decision 从“允许执行”升级为“不可绕过的生产约束”

创作日期：2026年9月21日

第（二十五）篇，我们建立了 Policy-as-Code + Control API + Governance Engine，让 Agent 的生产行为不再依赖散落在 Prompt、Workflow、脚本和人工 SOP 中的约定。

第（二十六）篇，我们进一步建立 Evidence Plane + Risk Engine + Decision Trace，让 Governance Engine 不仅能够做出 ALLOW、DENY、REQUIRE_APPROVAL、DEFER、ESCALATE，还能够解释：为什么做出这个决定？

但到这里，整个 Agent Governance Architecture 仍然存在一个非常危险的缺口。

假设 Governance Engine 已经返回：

{
  "decision": "DENY",
  "decision_id": "dec_98321"
}

但是 SEO Agent 自己仍然保存着 WORDPRESS_APP_PASSWORD，或者 Publishing Agent 仍然能够直接调用 WordPress REST API，又或者 Coding Agent 仍然拥有 GitHub PAT、Cloudflare API Token、Database Password、SMTP Credential，那么 Governance Engine 的 DENY 到底有什么意义？

答案是：几乎没有。

因为真正产生副作用的执行路径仍然可以绕过 Governance Engine。这意味着 Governance Decision 目前还只是一条 Recommendation，而不是 Enforcement。

真正成熟的 Agent Governance System 必须进一步回答：

Governance Engine 做出决策以后，怎样确保 Agent 技术上无法绕过去？

这就是第（二十七）篇要解决的问题：

Action Gateway
Policy Enforcement Point
Capability Token

最终把整个链条接成：

Agent Intent
↓
Evidence
↓
Risk
↓
Governance Decision
↓
Capability
↓
Enforcement
↓
Execution
↓
Outcome

让 DENY 真正意味着：系统没有执行能力。而不是：希望 Agent 自觉不要执行。

1、Governance 最大的幻觉：系统“拒绝了”，所以动作不会发生

很多 Agent 系统的治理架构实际上是 Agent → Ask Governance Engine → Decision → Agent decides what to do next。

例如 Governance 返回 DENY，Agent Prompt 里写 If decision is DENY, do not execute the tool。这看起来已经安全，但它仍然是一种 Behavioral Enforcement，也就是依赖 Agent 遵守约定，而不是 Technical Enforcement。

真正的安全架构必须保证：Agent 即使忽略 DENY，也无法成功产生生产副作用。

2、Policy Decision 与 Policy Enforcement 是两个不同问题

这是授权系统中非常成熟的思想。OASIS XACML 把相关职责明确区分为 Policy Decision Point（PDP）和 Policy Enforcement Point（PEP）。PDP 负责评估 Policy 并做出授权决策；PEP 负责保护资源、向 PDP 请求决策，并真正执行授权结果。XACML 还定义了 Obligation——与授权决策一起由执行侧完成的操作。

PDP
=
Should this happen?

PEP
=
Can this actually happen?

第（二十五）篇建立的 Governance Engine，本质上承担的是 PDP-like Function。现在缺失的是 PEP。

3、NIST Zero Trust Architecture 也强调 Decision 与 Enforcement 分离

NIST Zero Trust Architecture 的工程模型同样区分 Policy Engine、Policy Administrator 与 Policy Enforcement Point。其中 Policy Engine 负责决定是否授予、拒绝或撤销访问；Policy Administrator 根据决策建立或终止通信路径，并可生成会话相关的认证与授权凭证；PEP 位于资源前方，负责实际执行访问决策。

对 Agent Automation 来说，可以借鉴：

Governance Engine
=
Policy Decision

Capability Issuer
=
Decision → Temporary Authority

Action Gateway
=
Policy Enforcement

Tool Adapter
=
Controlled Execution

本文提出的 Action Gateway、Capability Token、Tool Adapter 是本 SEO / GEO Automation 项目的工程架构，不是 NIST 或 XACML 官方定义的一套 Agent 标准。

4、真正需要建立的是“Side-Effect Boundary”

Agent 最大的风险并不是 READ、ANALYZE、GENERATE，而是 WRITE、UPDATE、DELETE、PUBLISH、SEND、DEPLOY、EXECUTE、TRANSFER、CHANGE_PERMISSION。这些行为会产生 Side Effect。

因此整个 Agent 系统应该建立清晰的 SIDE-EFFECT BOUNDARY。边界之外的 Research、Reasoning、Drafting、Simulation、Recommendation 可以拥有较高自治程度；一旦越过边界进入 Production Mutation，必须进入 Action Gateway。

5、第一条硬规则：No Gateway, No Side Effect

未来整个系统应该建立一个非常简单的基础不变量：

No Gateway
=
No Side Effect

这比“所有 Agent 应该先调用 Governance API”强得多。后者是 Process Rule，前者是 Architecture Constraint。

6、Agent 不应该持有 Production Credential

错误方式：

SEO Agent
├── WORDPRESS_APP_PASSWORD
├── GITHUB_TOKEN
├── CLOUDFLARE_API_TOKEN
└── DATABASE_PASSWORD

无论 Governance Engine 多么复杂，只要 Agent 拥有这些长期密钥，就拥有绕开治理系统的能力。

正确方式：

SEO Agent
│
│ no production credential
│
▼
Action Gateway
│
├── WordPress Adapter
├── GitHub Adapter
├── Cloudflare Adapter
├── Database Adapter
└── Email Adapter

真正的长期凭证只存在于 Credential Boundary 内部。

7、项目现有架构其实已经为这一步做好准备

当前项目自动化标准已经要求每一个 Automation 明确定义 Input、Validation、Logic、Output、Permission、Human Review、Logging、Retry、Failure Handling、Rollback、Monitoring，并明确要求高风险生产变更默认需要人工批准。

Agent Architecture 也已经把 Quality Gate、Human Approval、Retry、Failure Escalation 放到 Orchestrator 中，并禁止 RESEARCHING → PUBLISHED、DRAFTED → PUBLISHED 这样的状态跳跃。

第（二十七）篇进一步解决：如何让这些逻辑不只是 Workflow 规则，而是生产基础设施无法绕过的执行边界。

8、完整链路应该发生根本变化

过去：

Agent
↓
Governance Engine
↓
ALLOW
↓
Agent
↓
Tool
↓
Production

未来：

Agent
↓
Intent
↓
Governance Engine
↓
Decision
↓
Capability Issuer
↓
Capability Token
↓
Action Gateway
↓
PEP Validation
↓
Tool Adapter
↓
Production Resource

最关键的变化是：Agent 与 Production Resource 不再直接连接。

9、ALLOW 不是 Credential

Governance Engine 返回 ALLOW，并不应该意味着“这里是数据库密码，你去执行吧”。

它真正意味着：对这个具体 Action，在这些具体约束条件下，Governance Engine 允许系统生成一次受限制的执行能力。

ALLOW
≠
Credential

ALLOW
→
Capability

10、Capability Token 是什么？

本文把 Capability Token 定义为：Governance Decision 被批准后，由受信任组件签发的、短时有效、作用范围有限、与具体 Action / Resource / Decision 绑定的执行授权凭证。

{
  "capability_id": "cap_91823",
  "decision_id": "dec_77191",
  "principal": "seo-agent",
  "action": "UPDATE_SEO_TITLE",
  "resource": {
    "type": "wordpress_post",
    "id": "1842"
  },
  "audience": "wordpress-action-gateway",
  "environment": "production",
  "expires_at": "2026-09-21T14:32:00Z",
  "max_uses": 1
}

它不是 Permanent Permission，而是 Temporary Authority。

11、Capability Token 不是“换个名字的 API Key”

如果 Token 只是 scope = wordpress.write、exp = 30 days，那么本质上还是长期凭证。

真正的 Capability 应该尽可能绑定 WHO、WHAT、WHICH RESOURCE、WHERE、WHEN、HOW MANY TIMES、UNDER WHICH DECISION、UNDER WHICH APPROVAL、WITH WHICH OBLIGATIONS。

例如：seo-agent，只能 UPDATE_TITLE，只能操作 post_id=1842，只能在 production，未来 5 分钟内只执行 1 次，并且必须关联 decision=dec_77191、approval=apr_412，同时执行 snapshot obligation。

这才接近 Decision-bound Authority。

12、Capability Token 的核心是 Least Authority

传统 RBAC 可能告诉系统 SEO Agent = Editor，于是 Agent 可能获得 edit_posts、publish_posts、delete_posts、upload_files，远远超过实际任务需要。

Capability 模型应该收缩成：SEO Agent can perform UPDATE_TITLE on POST 1842 once before 14:32。

这是一种 Just-in-Time Least Authority。

13、Capability Token 可以借鉴 OAuth，但不能假装它就是 OAuth 标准

OAuth RFC 8693 Token Exchange 允许系统把现有 Token 交换成用于下游服务的另一个 Token，并支持更窄的 Scope 与特定 downstream service。这非常接近 Broad Identity → Governance Decision → Narrow Execution Token。

但本文的 Capability Token 数据模型仍然属于项目设计，不应声称 RFC 8693 定义了本项目这种 Agent Capability Token。

14、Fine-grained Authorization 可以借鉴 RFC 9396

OAuth 传统 scope=write 对 Agent 来说仍然太粗。RFC 9396 Rich Authorization Requests 引入 authorization_details，以 JSON 表达更细粒度的授权需求，并定义 actions、locations、datatypes、identifier 等通用字段。

启示非常直接：不要只授权 write，要授权 write what、where、to which object、in what way。

15、Capability 应该绑定 Action

如果 Capability 授权 UPDATE_TITLE，就不能拿来执行 DELETE_POST、PUBLISH_POST 或 INSTALL_PLUGIN。PEP 必须验证 requested_action == authorized_action。

16、Capability 应该绑定 Resource

如果授权资源是 wordpress_post:1842，就不能操作 post 1843，更不能把 wordpress_post 换成 wordpress_user。

17、Capability 应该绑定 Environment

environment=staging 的 Capability 不能拿到 production 执行。production-us 也不应该自动代表 production-eu。因此 Environment 本身必须进入 Capability。

18、Capability 应该绑定 Audience

OAuth Token 体系强调 Token 面向什么资源或服务，JWT Access Token Profile 也使用 aud 明确目标资源。在我们的体系中 audience=wordpress-action-gateway 意味着这个 Token 不能拿到 github-action-gateway 使用。

19、Capability 必须短时有效

生产执行能力不应该存在 30 days，甚至不应该默认 24 hours。如果一次动作只需要几十秒，Capability TTL 可以只有 5 minutes；极高风险动作甚至可以是 60 seconds。

Capability 生命周期应该接近 Action 生命周期。

20、短生命周期仍然不够，还需要 Single Use

即使 Token 只有五分钟，攻击者仍可能在五分钟内重放。高风险 Capability 可以要求 max_uses = 1。第一次成功执行后，Capability State = CONSUMED；再次调用则 DENY。

21、必须防止 Replay

Capability Token 最大风险之一就是 Token Replay。比如 Agent 成功发布一次，由于网络超时不知道结果，于是再次发送 POST，结果文章发布两次。

所以要同时建设：

Capability Single-use
+
Idempotency Key
+
Execution Receipt

22、Capability ID 与 Idempotency Key 不完全一样

例如 capability_id=cap_892，idempotency_key=cmd_612。Capability ID 表示谁有权执行什么；Idempotency Key 表示这是不是同一个业务动作的重复请求。两者应该同时存在。

23、Capability 还必须绑定 Decision ID

例如 decision_id=dec_77191。这样执行日志才能继续回到第（二十六）篇中的 Decision Trace。

Execution
↓
Capability
↓
Decision
↓
Risk
↓
Evidence

这就是 Execution Lineage。

24、Approval 也必须绑定 Capability

假设 Human Approval=YES，但人类批准的是修改一个 Title，Agent 之后把任务改成修改 800 个 Title。如果仍然沿用同一个 approval_id，就产生 Approval Drift。

因此 Capability 必须绑定 approval_id，并同时绑定 exact action、exact resource、exact payload。

25、最重要的进一步约束：绑定 Payload Hash

例如人工审核的是：

Old:
Ferris Wheel for Sale

New:
Commercial Ferris Wheel for Sale

Approval 后生成 payload_hash=sha256:abc…。Action Gateway 收到实际执行内容以后重新计算 sha256(actual_payload)，必须满足 actual_payload_hash == approved_payload_hash，否则 DENY。

26、这解决了一个极其重要的问题：TOCTOU

安全系统中存在经典问题 Time Of Check vs Time Of Use。Governance Engine 检查时是 Action A，真正执行时变成 Action B，如果两者之间内容发生变化，前面的授权已经失效。

因此 Decision Context 必须和 Execution Context 绑定。

27、资源版本也应该进入 Capability

例如 Governance Engine 审核 WordPress post_id=1842、version=91。Capability 可以绑定 resource_version=91。执行时发现 current_version=92，说明 Approval 后内容已经变化。

Action Gateway 应该 DEFER 或重新 REAUTHORIZE，而不是盲目写入。

28、Capability 应该绑定 Obligations

第（二十五）篇已经提出 ALLOW 不只是允许动作，还可以附带 CREATE_SNAPSHOT、STORE_DIFF、ENABLE_MONITORING、NOTIFY_OWNER、CANARY_10_PERCENT 等 Obligations。

问题在于：谁确保这些 Obligation 真正执行？答案就是 PEP。

29、PEP 不应该只检查“允许不允许”

真正成熟的 Enforcement Point 应该执行：

Preconditions
+
Decision
+
Obligations
+
Execution
+
Postconditions

例如 Before: Create Snapshot；Before: Validate Capability；Execute: Update Title；After: Verify REST response；After: Read back resource；After: Store diff；After: Start monitoring。

30、Action Gateway 就是 Agent 的 Production Choke Point

可以把 Action Gateway 理解成：所有会产生生产副作用的 Agent Action 必须通过的统一控制入口。

POST /actions/wordpress/update-post
POST /actions/github/create-pr
POST /actions/database/update
POST /actions/email/send
POST /actions/cloudflare/deploy

Agent 不再面对底层真实 Credential。

31、Gateway 与 Tool Adapter 必须分开

Action Gateway 不应该把所有第三方 API 逻辑都写进自己内部。推荐：

Action Gateway
│
├── WordPress Adapter
├── GitHub Adapter
├── Cloudflare Adapter
├── Database Adapter
├── Email Adapter
└── Search Platform Adapter

Gateway 负责 Enforcement，Adapter 负责 Execution Translation。

32、为什么需要 Tool Adapter？

因为 UPDATE_CONTENT 在 WordPress 中可能对应 POST /wp-json/wp/v2/posts/{id}，在 GitHub 中可能是 commit + pull request，在 Database 中可能是 UPDATE。

所以应该统一 Canonical Action，再由 Adapter 翻译成 Provider-specific Operation。

33、Canonical Action Taxonomy 必须稳定

第（二十五）篇已经建立 READ、GENERATE、ANALYZE、RECOMMEND、CREATE、UPDATE、DELETE、APPROVE、REJECT、PUBLISH、ROLLBACK、EXECUTE_TOOL、CALL_EXTERNAL_API、CHANGE_POLICY、CHANGE_PERMISSION 等分类。

这一篇需要进一步把 Canonical Action 连接到 Enforcement。不能出现 Governance 看到 UPDATE_CONTENT，Adapter 实际执行 DELETE_AND_RECREATE_CONTENT。这叫 Semantic Drift。

34、Adapter 必须声明 Side Effects

每个 Adapter Operation 都应该有 Machine-readable Manifest：

{
  "operation": "wordpress.update_post",
  "canonical_action": "UPDATE",
  "resource_type": "wordpress_post",
  "side_effects": [
    "content_change",
    "modified_timestamp_change"
  ],
  "reversible": true,
  "requires": [
    "snapshot"
  ]
}

这样 Governance Engine 才不会根据错误语义做决策。

35、长期 Credential 应该进入 Credential Broker

WORDPRESS_APP_PASSWORD、GITHUB_TOKEN、CLOUDFLARE_API_TOKEN、SMTP_PASSWORD、DATABASE_PASSWORD 都应该移出 Agent Runtime，进入 Credential Broker。

只有 Tool Adapter 在满足 Capability 时才能短时使用。

36、Credential Broker 与 Capability Issuer 不是一回事

Capability Issuer 回答：这次动作允许执行什么？Credential Broker 回答：执行这个动作时，用哪个底层 Credential 与外部系统通信？

这样 Agent 永远不需要知道 Real Secret。

37、Capability Token 最好不要包含真正 Secret

Capability Token 应该描述 Authority，而不是携带 WordPress Password、GitHub PAT、Cloudflare Token、Database Password。真正 Secret 仍应该留在受保护的 Secret Store 内部。

38、Agent Identity 与 Capability 是两个不同问题

Action Gateway 需要同时知道 Who are you? 和 What are you allowed to do now? 前者是 Identity，后者是 Capability。

例如 Identity=seo-agent-prod；Capability=update post 1842 title once。不能混为一个概念。

39、Workload Identity 可以借鉴 SPIFFE

SPIFFE 的核心目标之一，是为动态、异构环境中的 software workload 提供可验证身份。SPIFFE 使用 SPIFFE ID 表示 workload identity，并通过 SVID 让 workload 以密码学方式证明身份；SVID 可以使用 X.509 或 JWT 等形式。

因此在更成熟的部署中，可以形成 Agent Workload Identity + Capability Token 双层验证。

40、Identity 不等于 Authorization

SPIFFE ID 只能说明“这是 Publisher Agent”，不能自动说明“Publisher Agent 现在允许修改 Post 1842”。因此 Identity + Capability 必须同时存在。

41、为什么不能只依赖 Bearer Token？

传统 Bearer Token 的本质是：谁拿到 Token，谁就可能使用。RFC 9449 DPoP 的目标之一就是通过 Proof-of-Possession，把 OAuth Token 绑定到密钥持有者，使泄漏的 Token 更难被其他实体直接重放。

对于高风险 Capability，可以借鉴 Sender-constrained Token 思想。

42、Capability 可以进一步绑定调用者密钥

例如 Token 中加入 confirmation key，执行方必须同时证明 I possess the corresponding private key。即使 Capability Token 被复制，攻击者没有私钥仍无法直接使用。

这类高等级保护特别适合 DELETE、DEPLOY、CHANGE_PERMISSION、DATABASE_WRITE 等高风险动作。

43、Capability Token 可以是 JWT，也可以是 Opaque Token

没有必要一开始就锁定 JWT。Signed JWT 的优点是 Local Validation、Low Latency；Opaque Token 则可以由 Action Gateway 调用 Capability Store 验证。

RFC 7662 Token Introspection 也展示了通过网络端点查询 Token 是否仍然 Active，以及读取 scope、client、expiration 等元数据的方式。

44、JWT 与 Introspection 的本质权衡是 Freshness

Self-contained Token 很快，但撤销以后 Gateway 可能无法立即知道；Introspection 更实时，但增加 Network dependency、Latency、Availability requirement。

因此高风险系统可以采用 Short TTL + Online Validation，低风险动作可以采用 Short-lived Local Validation。

45、Decision 被撤销以后 Capability 也必须失效

例如 14:01 Governance ALLOW，14:02 Capability issued，14:03 Incident detected，14:04 Global Freeze enabled。即使 Capability 原本 14:07 才过期，14:04 以后也必须 DENY。

所以 PEP 不能只检查 Signature + exp，还要检查 System State。

46、Global Freeze 应该成为 PEP 的最高优先级

例如 PRODUCTION_FREEZE = TRUE，那么 PUBLISH、DEPLOY、DELETE、WRITE 即使 Capability 仍然有效，也应该被阻断。这是 Runtime Override。

47、Break-glass 必须与普通 Capability 分开

系统必须允许极端情况下 Emergency Override，但不能简单 disable governance。应该建立 BREAK_GLASS_CAPABILITY，并要求 short TTL、named human actor、reason、incident_id、extra logging、mandatory notification、post-event review。

Break-glass 不是 Admin bypass，而应该是 More Audited Override。

48、Agent Tool Wrapper 还不是真正的 Enforcement Point

很多 Agent Framework 会定义 tool()，在 Tool Wrapper 里检查 permission。这很好，但如果 Agent Runtime 或其他服务仍能直接连接 api.wordpress.org、api.github.com、database.internal，就仍然存在 Bypass Path。

49、真正的 PEP 应尽量靠近 Resource

原则：Enforcement should be close to the side effect.

正确路径：Agent → Gateway → WordPress Proxy → WordPress。错误路径：Agent 同时拥有 Gateway 和 WordPress Direct Access。后一种架构的 Gateway 只是 Optional Middleware，而不是 Enforcement Point。

50、要真正做到不可绕过，还需要 Network Enforcement

真正严格的架构最终应该做到 Agent Runtime 在网络层无法直接访问生产写接口。

Agent Network
↓
Action Gateway Only
↓
Production APIs

这意味着 Enforcement 不只发生在 Application Layer，还可能包括 Network Policy、Firewall、Service Mesh、IAM、API Gateway、Database ACL。

51、PEP 最好采用多层 Enforcement

高风险场景可以形成：

Layer 1
Action Gateway

Layer 2
Provider Adapter

Layer 3
Cloud / Platform IAM

Layer 4
Network Boundary

即使一层配置错误，也不至于直接开放 Full Production Access。

52、WordPress 场景：Publisher Agent 应该怎样执行？

Content Agent 完成文章，Intent=PUBLISH_WORDPRESS_POST。Governance Engine=REQUIRE_APPROVAL。人工批准后 ALLOW。Capability Issuer 生成 cap_wp_291，绑定 post、slug、content_hash、category、status、expiry、approval_id、decision_id。

Publisher Agent 调用 Action Gateway，Gateway 检查通过后，WordPress Adapter 才读取 WP_APP_PASSWORD 执行 WordPress REST API。Agent 本身永远没有 WP_APP_PASSWORD。

53、WordPress Capability 可以细到 Status

Capability A 只允许 CREATE_POST status=draft，就不能执行 status=publish。因为 draft 与 publish 是完全不同的 Side Effect。

54、GitHub 场景：Capability 不应该是 repo.write

Coding Agent 请求 UPDATE_AUTOMATION_CODE，正确 Capability 可能是：

repo:
seo-publisher

branch:
feature/evidence-gateway

actions:
create_commit
create_pr

main_write:
false

merge:
false

这样即使 Coding Agent 出错，也无法 force push main。Capability Token 可以把 feature branch → implement → test → diff review → commit → pull request → deploy → verify 从 SOP 进一步变成 Machine-enforced Constraints。

55、Database 场景：绝不能给 Agent 通用数据库密码

错误：DATABASE_URL + admin password。

正确：

Capability:

table:
seo_jobs

operation:
UPDATE

columns:
status

where:
job_id=8291

max_rows:
1

真正 SQL 由 Database Adapter 生成或验证。Agent 不直接拿 root credential。

56、Database Capability 必须控制 Row Count

Agent 原本请求 UPDATE one record，如果实际 SQL 影响 82,341 rows，PEP 应该在 commit 之前 ABORT。因此 Obligation 可以包括 max_affected_rows = 1。

57、Email 场景：GENERATE_EMAIL 与 SEND_EMAIL 是两种 Capability

GENERATE_EMAIL 几乎没有外部副作用，但 SEND_EMAIL 会真正影响外部用户。

所以 Draft Capability ≠ Send Capability。SEND_EMAIL 还应该绑定 recipient、subject_hash、body_hash、max_recipients。

58、Cloudflare 场景：Deploy 与 Config Change 必须拆开

DEPLOY_WORKER 不应该自动允许 CHANGE_DNS，也不应该允许 DELETE_ZONE。Tool Adapter 必须将这些能力拆分成不同 Action。否则 cloudflare.write 仍然过于宽泛。

59、Action Gateway 必须验证 Capability 的完整状态

一次生产 Action 至少需要检查：

Signature
Issuer
Audience
Subject / Principal
Action
Resource
Environment
Expiry
Not-before
Decision ID
Approval ID
Payload Hash
Resource Version
Usage Count
Revocation State
System Freeze
Obligations

这才是 Enforcement。

60、Capability Validation 顺序应该确定化

Request
↓
Authenticate Workload
↓
Parse Capability
↓
Verify Signature
↓
Verify Issuer
↓
Verify Audience
↓
Verify Time Window
↓
Verify Revocation
↓
Verify Action
↓
Verify Resource
↓
Verify Payload Hash
↓
Verify System State
↓
Verify Obligations
↓
Execute

顺序应该成为正式规范，而不是每个 Adapter 自己决定。

61、Fail Closed 对生产 Side Effect 更重要

如果 Governance unavailable，或者 Capability validation unavailable，生产写操作一般不应该“先执行再说”。更合理的是 DENY 或 DEFER。

Unknown Authorization State ≠ ALLOW。

62、但 Fail Closed 也不能简单扩大到所有 Read

例如 public SERP research 不一定需要和 DELETE_DATABASE 同样严格。因此应该区分 Read Plane、Write Plane、High-risk Control Plane，不同层采用不同 Availability / Enforcement 策略。

63、Action Gateway 本身会成为 Critical Infrastructure

一旦所有 Side Effect 都走 Gateway，它就成为 Production Critical Dependency。因此必须建设 High Availability、Audit、Rate Limit、Circuit Breaker、Replay Protection、Latency Monitoring、Fallback、Disaster Recovery。

否则安全提高以后，可能换来 Single Point of Failure。

64、Action Gateway 需要自己的 SLO

例如 Availability、P95 Decision Validation Latency、Execution Success Rate、Unauthorized Attempt Block Rate、Capability Validation Error Rate、Replay Detection Rate、Gateway Bypass Detection、Credential Exposure Count。

特别重要的是 Gateway Bypass Detection，理想目标是 0 successful bypasses。

65、所有 Production Action 都应该产生 Execution Receipt

执行完成后 Action Gateway 返回：

{
  "command_id": "cmd_9921",
  "capability_id": "cap_7811",
  "decision_id": "dec_6612",
  "status": "SUCCESS",
  "provider": "wordpress",
  "resource": {
    "type": "post",
    "id": 1842
  },
  "before_version": "91",
  "after_version": "92",
  "executed_at": "2026-09-21T14:28:19Z"
}

这就是 Execution Receipt。

66、Execution Receipt 应继续写入 Decision Trace

第（二十六）篇的 Decision Trace：Evidence → Risk → Policy → Decision。现在进一步延长为：

Evidence
↓
Risk
↓
Policy
↓
Decision
↓
Capability
↓
Enforcement
↓
Command
↓
Outcome

这样最终网站上的每一次生产修改，都可以追溯到当时是谁申请、基于什么 Evidence、Risk 如何、Policy 如何匹配、谁批准、签发了什么 Capability、哪个 Gateway 执行、最后发生了什么。

67、Command ID 应成为生产变更的统一关联键

未来所有平台——WordPress、GitHub、Database、Cloudflare、Email、Analytics Configuration——都应该能够关联 command_id。

Command Center → cmd_9921 → WordPress Request → Deployment Log → Monitoring Event，最终构建 Cross-system Action Trace。

68、Action Gateway 可以进一步支持 Dry Run

很多操作应该先 DRY_RUN，返回 what_will_change、affected_resources、validation_result、estimated_blast_radius，然后把新的 Evidence 再送回 Risk Engine。

Plan
↓
Dry Run
↓
Evidence
↓
Risk
↓
Approval
↓
Execute

这比直接执行安全得多。

69、Dry Run 结果本身应该进入 Capability

例如 dry_run_hash=sha256:921…。真正执行时如果 execution_plan_hash != dry_run_hash，则 REAUTHORIZE。这可以防止 Plan Drift。

70、Bulk Action 最好拆成 Capability Set

假设 Update 10,000 URLs，不要签一个 update_everything Capability。可以拆成 Batch 1:100 URLs、Batch 2:100 URLs 等，然后 Canary → Observe → Continue。

如果出现异常，remaining capabilities revoked。

71、这让 Canary 第一次成为真正可执行控制

过去 Canary 10% 可能只写在 Deployment SOP。现在可以变成 Capability:max_resources=1000。执行第一批后 monitor，只有 Validation=PASS 才签发下一批 Capability。

这就是 Machine-enforced Progressive Delivery。

72、Capability Delegation 必须非常谨慎

假设 Orchestrator Agent 授权 Publisher Agent 执行某个动作，不能简单把自己的全部 Token 转给下游。

Parent Capability
↓
Delegation
↓
Narrower Child Capability

必须满足 Child Authority ⊆ Parent Authority，不能出现 Privilege Expansion。

73、Delegation Chain 应进入 Trace

例如 Human → Orchestrator → SEO Agent → Publisher Agent → WordPress Adapter。Decision Trace 应该看到 delegation_chain，否则最后只能看到 Publisher Agent executed，却无法知道谁最初授权了 Publisher Agent。

74、Confused Deputy 是 Agent 系统必须重点防范的问题

假设低权限 Agent 无法访问 Database，但它可以调用 Database Tool Agent。如果 Database Tool Agent 没有验证 original principal、decision、capability、resource，就可能被利用成为 Confused Deputy——高权限服务替低权限调用者完成了本来不允许的动作。

Capability Chain 正是防止这种问题的重要手段之一。

75、Tool Adapter 不应该信任上游传来的“role=admin”

role=admin 不能来自 Agent 自己。Identity、Decision、Capability 等安全关键属性必须来自 Trusted Control Plane，而不是 Untrusted Request Payload。

76、Capability Issuer 必须和普通 Agent 权限隔离

否则 Agent 可以直接调用 mint_capability(action=”DELETE_DATABASE”)，整个系统又回到了原点。

Capability Issuer 只能根据 Valid Governance Decision 签发 Capability。也就是说：

No valid decision
=
No capability

77、第二条硬规则：No Decision ID, No Capability

Capability Issuer 可以建立三个不变量：

Invariant 1
decision_id required

Invariant 2
decision must be ALLOW
or approved REQUIRE_APPROVAL

Invariant 3
decision must not be expired/revoked

78、第三条硬规则：No Capability, No Production Mutation

整个架构最终形成三个连续的不变量：

No Evidence / Context
→ No Valid Decision

No Valid Decision
→ No Capability

No Capability
→ No Production Mutation

这三条构成 Agent Production Safety Chain。

79、Approval 不应该直接产生执行动作

错误方式：Human clicks Approve → System immediately publishes。

更好的架构：

Human clicks Approve
↓
Approval Record
↓
Governance resolves decision
↓
Capability Issuer
↓
Action Gateway
↓
Execution

Approval 仍然只是 Authorization Input，而不是 Direct Execution Trigger。

80、Action Gateway 必须保持业务语义

一个非常危险的设计是 POST /execute {“command”:”anything”}，这等于创建 Universal Remote Code Execution Gateway。

正确设计应该使用 Typed Actions，例如 wordpress.update_post、github.create_pr、cloudflare.deploy_worker、email.send_message，并为每种 Action 建立明确 Schema。

81、禁止 Arbitrary Shell 成为普通 Capability

EXECUTE_SHELL:”rm -rf …” 几乎无法精确治理。生产 Agent 应尽量使用 High-level typed actions，而不是 General shell access。

如果确实需要 Shell，应该进入 Privileged Execution Plane，使用更高等级 Approval 和隔离环境。

82、Capability Schema 必须版本化

例如 capability_schema_version=1.3。因为未来 action、resource、obligations、delegation、proof-of-possession 都会变化。PEP 必须知道自己正在验证哪一版授权语义。

83、Policy Version 也应该进入 Capability

例如 policy_version=2026.09.21.8。否则 Policy 在 Capability 签发以后发生变化，很难判断这个 Token 是按照哪一版规则批准的。

84、高风险 Policy 更新可能需要主动撤销 Capability

例如安全团队刚刚新增 DENY production deploy during incident，那么过去五分钟签发、尚未执行的 DEPLOY Capability 可能应该 REVOKE。

因此 Policy Deployment 可能需要触发 Capability Revocation Evaluation。

85、Capability Revocation 必须是一等能力

至少支持：

revoke by capability_id
revoke by decision_id
revoke by principal
revoke by resource
revoke by action
revoke by incident
revoke all production writes

最后一个就是 Emergency Freeze。

86、PEP 必须能区分 DENY 与 DEFER

例如 Capability 无效、bad signature 应该 DENY；dependency temporarily unavailable 则可能应该 DEFER。

这样上游 Orchestrator 才知道不能盲目重试，还是稍后重试。

87、Action Gateway 还需要 Rate Limit

即使 Agent 拥有合法 Capability，也不代表它应该每秒执行 10,000 次修改。因此 PEP 可以加入 execution rate、concurrency、daily budget、resource budget，形成 Operational Capability Limits。

88、Autonomy Budget 可以直接落到 Capability 层

例如低风险 Agent 每天允许 100 个低风险 Draft Update，超过 Autonomy Budget 后 REQUIRE_APPROVAL。这让“Agent 自主权”第一次变成可量化资源。

89、Capability Token 还可以绑定 Cost Budget

对于 LLM、Crawler、Paid API、Cloud Compute，可以加入 max_cost_usd，或者 max_tokens、max_requests、max_runtime，防止一个合法 Action 演变成 Unlimited Consumption。

90、Action Gateway 最终会成为 Command Bus

随着系统成熟，Action Gateway 可能不只是 HTTP Proxy，而会逐渐变成 Governed Command Bus。

任何生产修改都表达成 Command：

{
  "command_id": "cmd_9001",
  "action": "UPDATE_TITLE",
  "resource": "wp:post:1842",
  "payload_ref": "payload:771",
  "capability": "cap_982"
}

然后由专门 Executor 消费。

91、同步 Action 与异步 Command 必须统一治理

Send Email 可能同步执行，而 Rebuild 20,000-page Sitemap 可能异步进入 Queue。两种模式都必须保留 decision_id、capability_id、command_id，不能一进入 Queue 就丢失 Governance Context。

92、Queue 本身不能成为绕过点

错误：

Agent
↓
Queue
↓
Worker
↓
Production

如果 Queue Worker 不验证 Capability，只要有人能向 Queue 写消息，就可以绕过 Governance。

正确：

Agent
↓
Governance
↓
Capability
↓
Queue
↓
Worker PEP
↓
Execution

Worker 在消费时仍然要验证授权状态。

93、长时间排队的 Capability 可能已经失效

例如 Capability TTL=5 min，但 Queue Delay=20 min，Worker 不应该直接执行，而应该 REAUTHORIZE 或 DEFER。因此 Capability 生命周期与 Queue Architecture 必须联动。

94、所有执行动作必须产生 Audit Event

至少记录 principal、action、resource、decision_id、capability_id、approval_id、command_id、adapter、credential_ref、request_hash、result、executed_at。

credential_ref 只能是引用，不能把真正 Secret 写入日志。

95、Capability 本身也不应该随意写进日志

如果它是可直接使用的 Bearer-style Token，完整 Token 写入日志就可能造成 Credential Leakage。日志应该保存 capability_id、token_hash，而不是 raw token。

96、PEP Metrics 应进入 Command Center

未来 Command Center 可以新增 Production Enforcement，展示 Actions Requested、Actions Allowed、Actions Denied、Capabilities Issued、Capabilities Consumed、Capabilities Expired、Capabilities Revoked、Replay Attempts、Approval Required、Gateway Bypass Attempts、Break-glass Events。

这样治理第一次从 Policy Dashboard 变成 Execution Governance Dashboard。

97、最重要的指标不是 ALLOW Rate

不能为了提高自动化率而追求 ALLOW Rate ↑。真正需要关注的是 Safe Autonomous Execution Rate：

在满足 Evidence、Risk、Policy、Capability、Enforcement 和 Validation 的前提下，有多少生产动作可以不依赖人工完成？

这比 Automation Coverage 更有意义。

98、Gateway Bypass Attempt 必须视为 Security Event

如果系统发现 Agent attempted direct WordPress API call 或 Agent attempted direct DB connection，即使最终失败，也不能只作为 Tool Error 处理。

它应该产生 SECURITY EVENT，因为它说明 Expected Enforcement Path 被绕开了。

99、MVP 不需要一开始建设完整 Capability Infrastructure

第一阶段可以先实现：

Action Gateway
+
No Direct Production Credential
+
Decision ID
+
Short-lived Signed Capability
+
Action / Resource Binding
+
Execution Receipt

第二阶段再增加 Payload Hash、Resource Version、Single Use、Revocation、Obligations。

第三阶段增加 Workload Identity、Sender Constraint、Delegation、Capability Chain。

第四阶段增加 Network Enforcement、Progressive Capability、Autonomy Budget、Dynamic Revocation。

100、第一批最值得接入 Gateway 的 Tool

不应该从 Read-only Analytics 开始，而应该优先收口：

WordPress Publish / Update
GitHub Write / Merge
Cloudflare Deploy / Config
Database Write
Email Send
Production File Write
Permission Change

因为这些才是真正拥有 Irreversible or High-impact Side Effects 的工具。

101、第一阶段甚至可以采用“Gateway 拥有 Credential，Agent 没有”

不必一开始就实现复杂 PKI。只要先做到 Agent does not know Production Secret，然后 Action Gateway 根据 decision_id + signed short-lived capability 执行动作，就已经比 Agent Environment Variables = Production Credentials 安全得多。

102、未来的完整 Control Plane

                   AGENT
                     │
                     ▼
                  INTENT
                     │
                     ▼
              EVIDENCE PLANE
                     │
                     ▼
                RISK ENGINE
                     │
                     ▼
             GOVERNANCE ENGINE
                     │
             Policy Decision
                     │
        ┌────────────┼────────────┐
        │            │            │
      DENY      REQUIRE_APPROVAL  ALLOW
        │            │            │
        │            ▼            │
        │        APPROVAL         │
        │            │            │
        └────────────┼────────────┘
                     │
                     ▼
              CAPABILITY ISSUER
                     │
                     ▼
              CAPABILITY TOKEN
                     │
                     ▼
             ┌────────────────┐
             │ ACTION GATEWAY │
             │      PEP       │
             │                │
             │ Identity       │
             │ Capability     │
             │ Action         │
             │ Resource       │
             │ Payload        │
             │ Freshness      │
             │ Obligations    │
             │ System State   │
             └───────┬────────┘
                     │
                     ▼
               TOOL ADAPTER
                     │
                     ▼
            CREDENTIAL BROKER
                     │
                     ▼
             EXTERNAL SYSTEM
                     │
                     ▼
                  OUTCOME
                     │
                     ▼
             EXECUTION RECEIPT
                     │
                     ▼
               DECISION TRACE
                     │
                     ▼
              COMMAND CENTER

这时 Governance Engine 终于不再只是 Decision Service，而成为完整 Agent Control Plane 的一部分。

103、从“最小权限”进一步进入“最小能力”

传统安全强调 Least Privilege：一个主体只拥有完成工作所需要的最少权限。

Agent 系统还应该再向前一步：Least Capability。Agent 不拥有一个长期角色带来的持续权限，只在某个已经治理的具体动作发生时，获得一次最小执行能力。

Editor Role 开始变成：Update this field on this resource once before this time under this decision。

104、真正的 Autonomous Agent 不应该拥有无限授权

很多人会认为 Agent 越自主，就应该拥有越多权限。实际上恰恰相反。

越自主的系统，越需要 Fine-grained、Temporary、Context-bound、Revocable、Auditable Capabilities。

High Intelligence + Broad Permanent Credential 不是成熟自治，而是 Large Blast Radius。

105、Autonomy 应该来自“快速签发能力”，而不是“永久持有权限”

低自治系统是 Human approves every action；危险的“高自治”系统是 Agent has admin credential；真正成熟的高自治系统应该是：

Agent
↓
Evidence
↓
Risk
↓
Policy
↓
Automatically approved
↓
Short-lived Capability
↓
Enforced Execution

自主性来自 Fast Safe Authorization，而不是 Permanent Access。

106、这才是真正的 Risk-adjusted Autonomy

低风险动作：Evidence strong、Risk low、Reversible、Good monitoring，可以 AUTO ALLOW → Capability → Execute。

中风险：REQUIRE_APPROVAL → Capability → Execute。

高风险：DENY。

不确定：DEFER / ESCALATE。

因此 Autonomy Level 本身不再是固定配置，而成为 Risk-adjusted、Decision-bound、Capability-mediated 的动态结果。

107、最终的三个安全问题

未来每一次 Agent Production Action 都必须回答：

1.
Why may this action happen?

2.
What exactly is allowed to happen?

3.
Where is that permission technically enforced?

第一个问题由 Governance Engine 回答；第二个问题由 Capability Token 回答；第三个问题由 Action Gateway / PEP 回答。

108、如果第三个问题回答不了，前两个问题都还不够

这是本篇最重要的结论。

你可以拥有 Perfect Policy，也可以拥有 Perfect Risk Engine，甚至 Perfect Decision Trace；但是只要 Agent still owns production credentials，治理就仍然可能被绕开。

Governance
without Enforcement
=
Advice

而不是 Control。

结语：Agent Governance 的终点不是“告诉 Agent 不要做”，而是“系统不允许它做”

第（二十五）篇用 Policy-as-Code 解决什么情况下允许、拒绝、审批、延迟或升级；第（二十六）篇用 Evidence Plane / Risk Engine / Decision Trace 解决 Governance Engine 凭什么这样决定；第（二十七）篇则进一步解决：决策做出来以后，怎样保证它无法被绕过？

真正成熟的生产链最终应该是：

Intent
↓
Evidence
↓
Risk
↓
Policy
↓
Decision
↓
Approval
↓
Capability
↓
Enforcement
↓
Execution
↓
Validation
↓
Outcome
↓
Trace

其中任何一步都不能偷偷跳成：

Agent
↓
Production Credential
↓
External API

因为只要这条捷径仍然存在，所有治理系统都有可能成为 Optional Governance，而我们真正需要的是 Mandatory Governance。

成熟的 Agent Control Plane 应该建立三个不可破坏的不变量：

No Valid Decision
→
No Capability

No Capability
→
No Production Mutation

No Execution Receipt
→
Action Is Not Complete

到这一阶段，WordPress Password、GitHub Token、Cloudflare API Token、Database Credential、Email Credential，都不再代表 Agent 的权限。它们只是 Action Gateway 内部完成已授权动作所使用的底层实现凭证。

Agent 真正持有的，应该只是 temporary、narrow、decision-bound、resource-bound、auditable、revocable 的一次性执行能力。

这才是从 Agent has access 升级到 Agent receives authority only when the system can justify it 的关键变化。

最终，Governance Engine 不再只是“我认为这个动作可以执行”，而整个系统能够真正证明：

这个 Agent 只能在这个时间窗口内，基于这个 Decision，对这个 Resource，以这个 Payload，执行这一个 Action；除此之外，它没有任何生产执行能力。

这才是真正意义上的 Enforced Agent Governance。

官方依据与工程边界说明

本文中的 Action Gateway、Capability Issuer、Capability Token、Credential Broker、Execution Receipt、Capability Chain、Autonomy Budget 和 Agent Production Safety Chain，是本 SEO / GEO 自动化项目提出的架构抽象，并不是 OASIS、NIST、IETF 或 SPIFFE 官方定义的一套统一 Agent Governance 标准。

OASIS XACML：XACML 明确定义 PDP 负责评估 Policy 并返回 Authorization Decision，PEP 负责保护资源、请求授权决策并执行授权结果；Obligation 可以随决策一起由 PEP 执行。官方资料：https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cd-03-en.html

NIST Zero Trust Architecture：NIST ZTA 区分 Policy Engine、Policy Administrator 与 Policy Enforcement Point。Policy Administrator 可根据 Policy Engine 的决策建立或终止访问路径，并生成会话相关授权 Credential；PEP 位于资源前方执行访问控制。官方资料：https://pages.nist.gov/zero-trust-architecture/VolumeB/architecture.html

OAuth 2.0 Token Exchange / RFC 8693：支持 Token Exchange，并允许为 downstream service 获取不同或更窄权限的 Token，同时使用 resource、audience 和 scope 等参数表达目标服务与权限范围。官方资料：https://www.rfc-editor.org/info/rfc8693

OAuth 2.0 Rich Authorization Requests / RFC 9396：引入结构化 authorization_details，并定义 actions、locations、datatypes、identifier 等可复用字段。官方资料：https://www.rfc-editor.org/rfc/rfc9396.html

JWT Profile for OAuth 2.0 Access Tokens / RFC 9068：提供 JWT Access Token 的标准化 Profile，并通过 aud 等字段表达目标资源。官方资料：https://www.rfc-editor.org/info/rfc9068

OAuth DPoP / RFC 9449：通过 Proof-of-Possession 将 OAuth Token 与密钥持有者绑定，以降低泄漏 Token 被其他主体直接重放的风险。官方资料：https://www.rfc-editor.org/info/rfc9449

OAuth Token Introspection / RFC 7662：Introspection Endpoint 可以返回 Token 是否 active 以及 scope、client、expiration 等信息，为动态撤销或在线授权状态检查提供可借鉴模式。官方资料：https://www.rfc-editor.org/info/rfc7662

SPIFFE：SPIFFE 为分布式工作负载提供可验证软件身份。SPIFFE ID 标识 workload，SVID 用于以密码学方式证明身份，并支持 X.509、JWT 等形式。官方资料：https://spiffe.io/docs/latest/spiffe-about/overview/