SEO / GEO 工作自动化部署与实践规范（三十五）：Workload Identity / Attestation / Secretless Agent / Credential Broker / Delegation Chain / Identity Federation / Non-repudiation——把 Agent 权限落实为可验证、短周期、可追溯的生产身份

创作日期：2026年9月29日

第（三十四）篇，我们建立了：

Identity
↓
Authority
↓
Ownership
↓
Coordination
↓
Lease
↓
Version
↓
Fencing
↓
Execution

并提出一个核心原则：

Authorization tells us who may act; coordination determines who may act now.

也就是说：

Authority
=
这个主体有没有权做？

Ownership
=
这个状态归谁治理？

Coordination
=
现在轮到谁做？

但这里仍然隐藏着一个更加底层的问题。

假设 Action Gateway 收到：

principal = seo-agent-7

系统怎么知道：调用者真的就是 seo-agent-7？

如果只是 HTTP Header：

X-Agent-ID: seo-agent-7

任何能够调用 API 的程序都可能伪造。

如果依赖：

SEO_AGENT_API_KEY

那么又会出现：

Who owns the key?
Where is it stored?
How long is it valid?
Can it be copied?
Can another Agent reuse it?
Can it leak into logs?
Can it enter an LLM context?
Can it survive after the Agent dies?

于是第（三十五）篇要解决的核心问题正式出现：

一个生产 Agent 应该怎样证明“我是谁”？

进一步：

Who is this workload?

Why should we believe it?

What runtime evidence
supports that identity?

What authority may
that identity obtain?

How does it get
production credentials?

How long are those
credentials valid?

Can they be delegated?

Can they be replayed?

Can they be revoked?

Can every action later
be tied back to the
actual workload instance?

这意味着我们需要从 Agent Name 升级为 Verifiable Workload Identity，再从 Static Production Secret 升级为：

Attested Identity
↓
Policy
↓
Short-lived Credential
↓
Scoped Access
↓
Verifiable Execution Evidence

这就是第（三十五）篇要建立的：

Workload Identity Control Plane

以及：

Secretless Production Access Architecture

一、Agent Name 不是 Identity

假设 Orchestrator 启动一个 seo-agent，在配置文件里写：

{
  "agent": "seo-agent"
}

这只是一个 Logical Name，不是安全身份。

真正的身份系统必须回答：

Which executable?
Which process?
Which container?
Which runner?
Which workload?
Which repository?
Which workflow?
Which environment?
Which node?
Which deployment?
Which runtime instance?

二、Role Identity 与 Runtime Identity 必须分开

SEO_PUBLISHER 可以是一种 Agent Role，但真正执行任务的可能是 seo-publisher-instance-8f7c。

Role Identity
≠
Runtime Instance Identity

Role 决定：

What authority
may this class of Agent obtain?

Runtime Identity 决定：

Which concrete workload
is making this request?

三、Authority Graph 还缺最后一个锚点

此前：

Principal
↓
Authority Edge
↓
Resource

现在必须升级为：

Attested Runtime Identity
↓
Principal Mapping
↓
Authority Graph
↓
Capability
↓
Production Action

否则 Authority Graph 只是把权限绑定给一个名字，而不是绑定给一个 cryptographically verifiable workload。

四、Workload Identity 到底是什么？

在本文语境下，可以定义为：一个运行中的软件工作负载能够向其他系统证明的、与其运行环境和生命周期相关联的机器身份。

它不同于 Human Account，也不同于 API Key，更不是 Agent display name。

五、SPIFFE 正是围绕这个问题建立的

SPIFFE 定义了跨动态、异构环境识别软件工作负载的标准框架，包括 SPIFFE ID、SVID 和 Workload API；SVID 是工作负载用来证明 SPIFFE Identity 的可验证身份文档。

Running Workload
↓
SPIFFE ID
↓
SVID
↓
Cryptographic Verification

六、例如一个 Agent 可以拥有

spiffe://seo.example.com/agent/publisher

但仍然需要证明当前这个进程真的有资格获得这个身份。于是进入：Attestation。

七、Identity Issuance 之前必须先有 Attestation

Attestation 回答的不是 What identity do you claim? 而是：

What evidence proves
what workload you are?

八、SPIRE 把 Attestation 拆成两个层次

SPIRE 作为 SPIFFE 的实现，通过 Node Attestation 和 Workload Attestation 识别运行环境和具体 workload，然后根据预先定义的条件签发 SVID。

Node Attestation
↓
Workload Attestation
↓
Identity Assignment

九、Node Attestation 回答

Which machine /
node / execution
environment is this?

十、Workload Attestation 回答

Which process /
container /
service account /
image /
namespace
is calling?

SPIRE 的 Workload Attestation 可以根据 Unix 属性，也可以在 Kubernetes 环境中使用 namespace、service account、labels 等运行时属性建立 selector。

十一、因此身份不能只绑定“代码是谁写的”

真正的 Production Identity 应该尽量绑定：

Source
+
Artifact
+
Runtime
+
Environment

例如：

repository:
seo-publisher

commit:
abc123

workflow:
deploy.yml

environment:
production

runtime:
runner-882

role:
publisher

十二、这可以形成 Agent Identity Evidence

{
  "identity_request_id": "idr_882",
  "workload": "seo-publisher",
  "runtime": "runner-882",
  "environment": "production",
  "source_revision": "abc123",
  "attestation": {
    "type": "github_oidc",
    "issuer": "github",
    "status": "VERIFIED"
  }
}

十三、Attestation 与 Authentication 不完全相同

Authentication 通常回答：

Can you prove
you control credential X?

Attestation 更进一步：

What evidence connects
credential X
to this workload?

十四、这一区别对 Agent 极其重要

如果一个 API Key 被复制，original Agent + attacker 都能够证明 I know the secret，但系统无法知道 which runtime actually owns it。

十五、于是第一条新的安全原则出现

Claimed Agent Identity
≠
Verified Workload Identity

十六、Secretless Agent 到底是什么意思？

这里必须非常谨慎。

Secretless Agent 不是 There are no secrets anywhere in the system。

这个说法在现实生产系统中通常不成立。

更准确的定义是：

Agent Runtime 尽量不预先持有长期、静态、可复制、可重复使用的生产凭证。

No Long-lived
Production Secret
Inside Agent Runtime

十七、传统模式

GitHub Secret
↓
API_KEY
↓
Agent Environment Variable
↓
Production API

问题是：

credential copied
credential logged
credential exfiltrated
credential reused
credential survives job
credential rotated manually

十八、Secretless 模式

Runtime Identity
↓
Attestation
↓
Identity Token
↓
Federation / Broker
↓
Short-lived Credential
↓
Production API

核心变化：

Credential
is derived
at runtime.

而不是：

Credential
was stored there
before runtime.

十九、这就是 Credential Minting，而不是 Credential Storage

成熟系统逐渐从：

Where do we store
the production key?

转向：

How do we mint
a temporary credential
for an attested workload?

二十、SPIFFE Workload API 就体现了这种思路

SPIFFE Workload Endpoint 的设计考虑了 workload 在启动阶段没有现成 Secret 的情况，因此 Workload API 不要求 workload 提供直接认证 Secret，而由实现通过操作系统、socket、orchestrator 等带外机制确认调用者身份。

Bootstrap Identity
without
pre-provisioned app secret

二十一、这解决的是经典 Secret Zero 问题的一部分

传统问题：

To get a secret
you need a secret.

例如 Agent needs Vault password to retrieve WordPress password，那么 Where does the Vault password live? 问题只是向上移动了一层。

二十二、Attestation 可以作为 Bootstrap Root

Runtime Evidence
↓
Attestation
↓
Workload Identity
↓
Credential Broker

这样初始信任来自 environment evidence，而不是 another embedded password。

二十三、第二条原则

Identity should bootstrap
credentials.

Credentials should not
bootstrap identity
whenever avoidable.

二十四、SVID 通常应该是短周期身份材料

SPIFFE Workload API 可以向 workload 提供 X.509-SVID 或 JWT-SVID，以及相关信任材料；SPIFFE 文档描述 X.509-SVID 为短期证书，并允许 Workload API 持续向 workload 推送更新后的身份材料。

二十五、短期 Credential 为什么重要？

假设泄露 Permanent API Key，攻击窗口可能持续到被检测并手工撤销；而泄露 5-minute token，最坏窗口天然受到生命周期约束。

二十六、因此风险可以粗略理解为

Credential Exposure Risk
≈
Privilege
×
Lifetime
×
Replayability
×
Exposure Surface

这是本项目工程化风险模型，不是任何标准机构发布的正式公式。

二十七、降低长期风险的四个方向

Less Privilege
Shorter Lifetime
Less Replayability
Smaller Exposure Surface

二十八、于是出现一个非常重要的架构组件：Credential Broker

Agent 不直接持有 Production Master Credential，而是向 Credential Broker 请求 Purpose-bound、Short-lived、Scoped Credential。

二十九、Credential Broker 不只是 Secret Manager

Secret Manager 通常解决 Store / Retrieve / Rotate。

Credential Broker 更偏向：

Verify identity
↓
Evaluate authority
↓
Derive credential
↓
Bind scope
↓
Set TTL
↓
Issue
↓
Audit
↓
Expire / revoke

三十、Credential Broker 输入应该至少包括

Workload Identity
Action
Resource
Environment
Capability
Decision
Delegation Chain
Requested Lifetime
Audience

三十一、输出则可能是

OIDC Access Token
Cloud STS Credential
Temporary DB User
X.509 Certificate
Short-lived API Token
Signed Request Credential

三十二、一个统一 Credential Request 可以是

{
  "principal": "spiffe://seo.example.com/agent/publisher",
  "action": "PUBLISH_POST",
  "resource": "wordpress:site:1",
  "environment": "production",
  "capability_id": "cap_771",
  "requested_ttl": 300,
  "audience": "wordpress-publisher"
}

三十三、Broker 决定的不是“给不给密码”

而是：

Which credential
is minimally sufficient
for this exact action?

三十四、Credential ≠ Capability

这是第（三十五）篇必须再次强调的区别。

Capability 回答：

What is this actor
authorized to do?

Credential 回答：

How does this actor
authenticate to
the target system?

Capability
≠
Credential

三十五、错误架构

ALLOW
↓
Give Admin Password

三十六、更成熟的架构

Governance Decision
↓
Capability
↓
Credential Broker
↓
Target-specific
minimum credential

三十七、Capability 应约束 Credential Issuance

例如 Capability: UPDATE_POST / post_id = 1000060，Credential Broker 不应该返回 WordPress Site Administrator。

三十八、理想情况应该尽可能实现

Credential Privilege
≤
Capability Scope

三十九、如果下游系统能力太粗怎么办？

例如某个 API 只能提供 Site-wide write token，但 Capability 只允许 post:1000060。

Downstream Credential Scope
>
Governance Scope

四十、这时不能假装权限已经足够细

必须通过 Action Gateway 再次收窄：

Broad Backend Credential
↓
Trusted Gateway
↓
Narrow Capability Enforcement
↓
Specific Operation

四十一、所以 Credential Broker 与 Action Gateway 是互补关系

Credential Broker
=
credential minimization

Action Gateway
=
effect minimization

四十二、GitHub Actions OIDC 是 Secretless CI/CD 的典型例子

GitHub Actions 可以为 Job 申请 OIDC Token，然后让支持 OIDC 的云服务根据该 Token 换取短期访问凭证，从而避免把长期云凭证存储为 GitHub Secret。

GitHub Workflow
↓
GitHub OIDC Token
↓
Cloud Trust Policy
↓
Temporary Credential
↓
Deployment

四十三、GitHub OIDC Token 本身也不是“万能云权限”

真正权限来自：

Cloud Trust Policy
+
OIDC Claims
+
Role Policy

因此 id-token: write 并不等于 production admin。

四十四、真正关键的是 Claims Binding

例如约束：

repository
branch
environment
workflow
subject
audience

只有 repo = seo-publisher / environment = production / workflow = deploy.yml 才能换取 Production Credential。

四十五、Google Cloud Workload Identity Federation 展示了完整模式

Google Cloud 的 Workload Identity Federation 可以信任 GitHub Actions 等外部身份提供方，让外部 workload 使用 OIDC 等环境身份换取短期 Google Cloud 凭证，而无需长期 Service Account Key。

External Workload
↓
External Identity
↓
Federation Provider
↓
STS
↓
Short-lived Google Credential

四十六、Google 将 Federation 作为外部 workload 的优先模式之一

对于运行在 Google Cloud 外的 workload，可以使用 Workload Identity Federation 借助 AWS、Azure、GitHub、GitLab 等外部身份生成短期凭证，而不是依赖长期 Service Account Key。

四十七、AWS STS 展示了另一个典型模式

AWS STS 可以签发临时安全凭证，用于 federation、delegation、cross-account access 和 IAM roles。使用 Web Identity 时，AssumeRoleWithWebIdentity 可以根据 OIDC 等身份提供方的 Token 返回临时 AWS Credential，而调用本身不需要预先携带长期 AWS 凭证。

四十八、因此“身份联邦”真正解决的是

Trust External Identity
↓
Map To Local Authority
↓
Mint Local Credential

而不是 Copy External Password Into Local System。

四十九、这就是 Identity Federation

Identity Domain A
↓
Trust Relationship
↓
Identity Translation
↓
Authority Mapping
↓
Resource Domain B

五十、Federation 不是 Shared Account

错误方式：

All Agents
↓
shared-production-user

正确方向：

Agent Identity A
Agent Identity B
Agent Identity C
↓
Federation
↓
distinct sessions

五十一、这样 Audit 才能区分 which workload actually acted

而不是 service-account did it。

五十二、Identity Federation 需要 Trust Policy

不能 trust entire GitHub。

应该 trust specific issuer + specific audience + specific subject + specific claims。

五十三、GitHub Actions 生产发布尤其要绑定 Environment

例如 repository: seo-publisher，environment: production，再结合 GitHub Environment Protection Rules。

Workflow Identity
+
Environment Gate

共同参与 Credential Issuance。

五十四、这和第三十二篇 Release Gate 正式连接

Release Gate
↓
Approved Production Phase
↓
Production Identity Eligible
↓
Credential Minted

No Release Authorization
→
No Production Credential

五十五、于是新的硬约束出现

No Verified Workload Identity
→
No Production Credential

五十六、第二条

No Valid Capability
→
No Privileged Credential

五十七、第三条

Credential Scope
must not exceed
authorized execution scope
unless a trusted
enforcement gateway
narrows the effect.

五十八、不能联邦的传统系统怎么办？

现实环境里并不是每一个系统都支持 OIDC / STS / SPIFFE / mTLS。

例如 legacy database、old WordPress integration、third-party API、vendor system 仍然可能要求 username/password 或 API token。

五十九、这时 Secretless Agent 的目标不是假装 Secret 不存在

而是：

Agent
does not permanently
own the secret.

六十、可以通过动态 Credential 解决

HashiCorp Vault 的 Database Secrets Engine 可以按需生成数据库用户名和密码，并控制这些 Credential 的生命周期；动态、短周期 Credential 可以减少共享凭证和长期泄露窗口。

Attested Agent
↓
Vault Auth
↓
Dynamic DB Credential
↓
Use
↓
Expire / Revoke

六十一、GitHub Actions 也可以通过 OIDC 登录 Vault

GitHub Job 可以使用 GitHub OIDC 身份访问 Vault，使 Vault 根据 repository、environment、ref 或 workflow 等 Claims 判断角色并签发短期 Token，而不需要预存在 GitHub 中的 Vault 长期 Credential。

六十二、于是 Secretless 可以分成三个成熟度层次

第一层：

STATIC_SECRET

第二层：

BROKERED_SECRET

第三层：

FEDERATED_IDENTITY

六十三、架构优先顺序可以是

Native Workload Identity
>
Federated Short-lived Credential
>
Brokered Dynamic Secret
>
Rotated Static Secret
>
Permanent Shared Secret

这是本项目的架构优先级，不是通用行业排名。

六十四、Agent Runtime 不应该保存 Production Credential

尤其不应写入 Prompt、Memory、Chat Transcript、Artifact、Debug Log、Error Message、Git Repository、Generated HTML、Execution Trace Payload。

六十五、Credential 应被视为高敏瞬态数据

理想生命周期：

Mint
↓
Inject
↓
Use
↓
Destroy

而不是：

Mint
↓
Save
↓
Reuse
↓
Forget

六十六、这需要 Credential Exposure Boundary

Agent Reasoning 不一定需要看到 actual credential value。

六十七、更成熟的模式是 Tool-side Credential Injection

Agent
↓
Action Request
↓
Action Gateway
↓
Credential Broker
↓
Tool Adapter
↓
Production

Agent 本身只知道 credential_ref，甚至完全不知道 Credential。

六十八、这比把 API Key 放进 Agent Tool 参数安全得多

Agent 发送：

{
  "action": "publish_post",
  "capability_id": "cap_882"
}

而不是：

{
  "api_key": "secret...",
  "action": "publish_post"
}

六十九、于是可以建立 Credential Isolation

Reasoning Plane
≠
Credential Plane

七十、这是 Agent 安全架构非常关键的一次分层

Reasoning Plane：decide what to do。

Credential Plane：enable an approved effect without exposing credentials to the reasoning context。

七十一、Credential Broker 应该绑定 Audience

Token 不应简单是 valid everywhere，而应 audience = specific target service，这样被盗以后不能轻易跨系统使用。

七十二、还应该绑定 Resource / Scope

scope:
wordpress.publish

而不是 wordpress.admin。

七十三、还应该绑定 TTL

expires_in:
300 seconds

而不是 never。

七十四、还应该绑定 Environment

environment: production 与 staging credential 不能混用。

七十五、Credential Broker 还应该检查 Lease

第（三十四）篇已经建立 Lease，所以对需要排他控制的资源：

No Valid Lease
→
No Write Credential

七十六、这样 Authority、Coordination 与 Identity 正式合并

Attested Identity
+
Authority
+
Capability
+
Lease
=
Credential Eligibility

七十七、可以定义 Credential Eligibility

Identity Valid
AND
Capability Valid
AND
Authority Current
AND
Policy Current
AND
Coordination Current
AND
Environment Allowed

才进入 ISSUE。

七十八、Credential Broker 输出不应该只有 ISSUE / DENY

ISSUE
DENY
REQUIRE_APPROVAL
DEFER
REAUTHENTICATE
RE_ATTEST
REDUCE_SCOPE

七十九、为什么需要 RE_ATTEST？

因为 identity evidence 也会变旧。

例如 workload restarted、node changed、image changed、deployment changed，旧 Runtime Identity 不一定仍然适用。

八十、所以 Identity 也需要 Freshness

Identity Confidence
≈
Attestation Strength
×
Attestation Freshness
×
Credential Freshness
×
Trust Chain Health

仍然是本项目工程抽象。

八十一、Workload Identity 应该和 Workload 生命周期一致

Workload dies
↓
Identity session ends

而不是：

Workload dies
↓
API key remains valid
for another year

八十二、这里出现另一个巨大风险：Bearer Token

如果 Token 的安全模型是 whoever possesses it can use it，那么 token theft = identity theft。

八十三、SPIFFE 对 JWT-SVID 的 Replay 风险也有明确提醒

SPIFFE 文档指出 JWT Token 容易受到 Replay Attack，因此在可行场景下建议优先使用 X.509-SVID；X.509-SVID 能结合私钥持有建立更强的双向认证。

八十四、因此不能只看 Token 是否“短”

还要考虑：

Is it bearer?
Is it bound
to key possession?
Can it be replayed?

八十五、于是 Credential Risk 继续扩展

Privilege
×
Lifetime
×
Replayability
×
Portability
×
Exposure

八十六、对于内部高价值 Agent-to-Agent 通信

优先可以考虑：

mTLS
+
Workload Identity

让双方都证明 who they are。

八十七、这比“内网 IP 白名单”更适合动态 Agent

NIST SP 800-207A 强调，在云原生、多云环境中，访问控制应从基于 IP、子网和网络位置的传统边界进一步转向 application/service identity，并讨论 SPIFFE 一类应用身份基础设施。

八十八、所以新的原则是

Network Location
≠
Workload Identity

八十九、运行在同一服务器也不自动代表可信

localhost
≠
trusted principal

九十、进入 Delegation Chain

第（三十四）篇已经建立 Parent Authority → Delegation → Child Authority。

现在必须进一步回答：Delegation 如何在 Credential 层表达？

九十一、OAuth 2.0 Token Exchange 提供了重要标准模型

RFC 8693 定义了 Security Token Service 风格的 Token Exchange，并明确讨论 delegation 与 impersonation。

九十二、Delegation 与 Impersonation 必须区分

Delegation 的语义可以理解为：

A acts
on behalf of B

while A remains
identifiable as A

而 Impersonation 更接近：

A acts
as B

九十三、对于 Agent 系统，优先保留 Delegation Chain 往往更适合审计

Human
↓
Orchestrator
↓
SEO Agent
↓
Publisher Agent

执行时最好能够知道 Publisher Agent acted on behalf of SEO Agent which acted under Orchestrator task。

九十四、而不是全部变成 seo-admin

九十五、RFC 8693 的 act Claim 提供了一种标准化思路

它允许 Token 中表达 subject + actor，即 Who owns the delegated authority? 与 Who is actually performing the action?

九十六、这与第三十四篇 Authority Graph 几乎天然连接

Root Principal
↓
Delegator
↓
Actor
↓
Capability
↓
Credential
↓
Execution

九十七、因此 Credential 不应该抹掉 Delegation Provenance

如果换取新 Token 后只剩 service_account = publisher，而所有上游 Delegation 消失，未来就无法回答 Why was publisher allowed to act?

九十八、所以需要 Delegation Chain Preservation

至少保存：

root_principal
delegator
actor
delegation_id
capability_id
decision_id

九十九、Credential Broker 可以生成 Delegation Receipt

{
  "credential_session_id": "cred_882",
  "subject": "orchestrator",
  "actor": "publisher-agent",
  "delegation_id": "del_991",
  "capability_id": "cap_882",
  "audience": "wordpress",
  "issued_at": "...",
  "expires_at": "..."
}

一百、Delegation 必须继续遵守 Attenuation

第（三十四）篇：

Delegated Authority
⊆
Parent Authority

第（三十五）篇继续增加：

Delegated Credential Scope
⊆
Delegated Authority

一百零一、因此完整收缩链应该是

Root Authority
⊇
Delegated Authority
⊇
Capability
⊇
Credential Scope
⊇
Actual Side Effect

一百零二、任何一层扩大都应该被视为异常

例如 Capability: UPDATE_ONE_POST，而 Credential: ADMIN_ALL_SITES，这是 Credential Overreach。

一百零三、Identity Federation 本质上也形成 Trust Graph

GitHub
↓ trusts
Google WIF
↓ maps
Google Principal

或者：

GitHub OIDC
↓
Vault
↓
Dynamic Credential

一百零四、所以 Authority Graph 可以进一步连接 Trust Graph

Identity Provider
↓
Trust Relationship
↓
Federated Identity
↓
Authority Graph
↓
Credential Broker

一百零五、本项目可以建立 Identity Trust Graph

Node：

Issuer
Trust Domain
Workload
Principal
Role
Credential Broker
Target System

Edge：

TRUSTS
ATTESTS
ISSUES_IDENTITY
FEDERATES_TO
MAY_EXCHANGE
MAY_IMPERSONATE
MAY_DELEGATE

一百零六、Identity Trust Graph 不是普通 IAM Role 图

它回答：

Why should
System B believe
Identity A?

一百零七、跨 Trust Domain 时尤其重要

SPIFFE 定义 Trust Domain 和 Federation，用于让不同信任域中的 workload 验证彼此的 SVID，而不是默认把所有 workload 放入同一个统一信任边界。

一百零八、不要建立“Global Trusted Agent”

这是非常危险的抽象。

更合理是：

Trusted by whom?
For what?
In which domain?
For which audience?
Until when?

一百零九、Identity Federation 同样需要最小信任

例如 Trust GitHub OIDC 还不够。

应该：

Trust issuer
ONLY WHEN

repository = X
workflow = Y
environment = production
audience = Z

一百一十、否则 Federation 会成为新的超级后门

如果 any repository 都能换取 Production Credential，那么系统虽然 removed static secret，却扩大了 identity trust boundary，风险可能反而更高。

一百一十一、所以 Secretless ≠ Secure by Default

无静态 Secret 只解决了一类风险。仍然需要：

Trust Policy
Audience
Scope
Claims
TTL
Authorization
Monitoring
Revocation

一百一十二、短期 Credential 也不意味着不需要 Revocation

例如 5-minute token，如果发现 workload compromised，仍然可能不能等待 5 分钟。

一百一十三、因此 Revocation 有多层

Authority Revocation
Capability Revocation
Lease Revocation
Credential Revocation
Identity Revocation
Trust Relationship Revocation

一百一十四、其中并不是所有 Token 都支持实时撤销

所以对于某些短期 Token，实际防御可能依赖 Short TTL + Issuer Policy Change + Gateway Deny + Capability Revocation。

一百一十五、再次证明 Action Gateway 很重要

即使 credential still technically valid，Action Gateway 仍可以发现 capability revoked，然后拒绝 Side Effect。

一百一十六、所以最终控制不能完全委托给 Credential

Credential Valid
≠
Action Allowed

这是第三十五篇一个非常重要的原则。

一百一十七、Credential 证明身份和访问资格

Capability + Policy + Coordination 决定 this action right now 是否真正允许执行。

一百一十八、现在进入 Non-repudiation

这个概念非常容易被错误使用。

很多系统认为 signed JWT = non-repudiation，这过于简单。

一百一十九、NIST 对 Non-repudiation 的定义更严格

NIST 将 Non-repudiation 描述为防止主体对自己执行过的特定行为进行虚假否认，并具备确定主体是否执行过该行为的能力。相关控制还涉及 Association of Identities、Validation of Producer Identity Binding、Chain of Custody。

一百二十、因此在本项目中更稳妥的表述应该是 Verifiable Execution Attribution

Can we reliably
attribute this action
to a verified workload identity?

一百二十一、而不是轻率宣称 Legally undeniable

因为真正强意义上的 Non-repudiation 还涉及 Key Control、Signature、Identity Binding、Audit Integrity、Time、Chain of Custody、Evidence Retention、Operational Procedures。

一百二十二、数字签名确实能够提供关键基础

NIST FIPS 186-5 指出，数字签名可以用于检测数据的未授权修改、验证签名者身份，并可以作为向第三方证明签名来自所声称签名者的证据。

但 signature verified 仍然需要结合 Who controlled the signing key?

一百二十三、如果一个 Signing Key 被 50 个 Agent 共享

那么 valid signature 最多说明 someone with this key signed it，不能可靠回答 which workload?

一百二十四、所以 Non-repudiation 的第一层仍然是 Unique Identity

而不是 Shared Secret。

一百二十五、第二层是 Key Binding

Workload Identity
↔
Private Key

一百二十六、第三层是 Action Binding

签名或可验证记录至少要绑定：

action
resource
payload hash
time
decision
capability

一百二十七、例如 Execution Evidence

{
  "execution_id": "exec_882",
  "principal": "spiffe://seo.example.com/agent/publisher",
  "action": "UPDATE_POST",
  "resource": "wp:post:1000060",
  "payload_hash": "sha256:...",
  "decision_id": "dec_331",
  "capability_id": "cap_551",
  "credential_session_id": "cred_771",
  "executed_at": "..."
}

一百二十八、第四层是 Evidence Integrity

如果 Agent 可以 execute action 又可以 rewrite its own audit log，那么证据价值极低。

一百二十九、所以 Audit Plane 必须隔离

Execution Plane
↓
Append Audit Evidence
↓
Independent Audit Store

而不是 Agent writes editable text log。

一百三十、第五层是可信时间

如果 timestamp 可以由 Agent 任意填写，那么时间证据没有足够可信度。

需要 Trusted Service Time 或至少 server-side timestamp，而不是客户端自由声明。

一百三十一、第六层是 Chain of Custody

尤其对于 Human Approval、High-risk Publish、Incident Override、Production Migration，需要能够追踪：

who created
who reviewed
who approved
who executed
who verified

一百三十二、这正好把多个 Trace 统一起来

此前已经有 Decision Trace、Coordination Trace、Execution Trace、Release Trace、Incident Trace。

现在再增加 Identity Trace、Credential Trace。

一百三十三、最终形成 Execution Evidence Chain

Attestation
↓
Identity
↓
Authority
↓
Delegation
↓
Decision
↓
Capability
↓
Coordination
↓
Credential
↓
Execution
↓
Verification

一百三十四、任何生产操作都应该能够沿链逆向追踪

例如 Why did WordPress Post 1000060 change? 系统应该能够回答：

Execution:
exec_882

Credential:
cred_771

Workload:
publisher-runner-8

Identity:
spiffe://.../publisher

Capability:
cap_551

Decision:
dec_331

Change:
chg_119

Release:
rel_902

Source:
commit abc123

一百三十五、这就是 Provenance 的进一步深化

第三十三篇：Configuration Provenance。

第三十五篇增加 Identity Provenance、Credential Provenance、Execution Provenance。

一百三十六、Credential Provenance 回答

Why did this workload
receive this credential?

至少关联：

issuer
subject
actor
attestation
scope
audience
policy
capability
issued_at
expires_at

一百三十七、没有 Credential Provenance 会发生什么？

你可能只看到 API request authenticated，却无法知道 Why did this credential exist?

一百三十八、这会让泄露调查非常困难

因为无法区分 legitimate issuance、stolen credential、mis-issued credential、stale credential、delegation abuse。

一百三十九、Credential Broker 因此必须有 Journal

ISSUED
USED
RENEWED
REVOKED
EXPIRED
FAILED

一百四十、Credential 使用也应该绑定 Session ID

例如 cred_session_771。不要把原始 Secret 写进日志。

一百四十一、日志记录 Reference，不记录 Credential Value

正确：

credential_session_id:
cred_771

错误：

authorization:
Bearer eyJ...

一百四十二、这是 Agent 系统尤其需要的 Guard

因为 Agent Runtime 经常存在 tool logs、prompt traces、debug traces、observability，Credential 非常容易被意外采集。

一百四十三、所以需要 Secret Redaction Policy

任何 Observability Pipeline 进入前：

Authorization Header
Cookie
API Key
Private Key
Password
Access Token
Refresh Token

都必须被 DROP / REDACT / HASH_REFERENCE。

一百四十四、LLM Prompt 也必须成为禁止 Credential 区域

新的 Safety Invariant：

Production Credential
→
Never enter
LLM reasoning context
unless technically unavoidable
and explicitly governed.

一百四十五、理想状态则是

LLM never sees it.

一百四十六、Agent Tool 应使用 Credential Handle

例如 credential_handle: cred_771。Tool Adapter 内部再向 Broker resolve credential。

一百四十七、Credential Handle 不能自动成为能力证明

否则窃取 cred_771 就又能访问。所以 Broker 仍必须检查 caller identity。

一百四十八、这叫 Credential Binding

Credential Session
↔
Workload Identity

最好还进一步绑定 Capability、Audience、Action。

一百四十九、GitHub Actions 可以成为项目最直接的现实案例

目前一类常见部署方式是：

GitHub Actions
↓
Stored Cloud Token
↓
Cloud Provider

长期目标可以逐渐迁移为：

GitHub Actions
↓
OIDC Job Identity
↓
Federation / Broker
↓
Short-lived Deployment Credential

前提是目标 Provider 支持合适的 Federation 或存在可信 Broker。

一百五十、不能因为某个服务暂时不支持 Federation 就强行“Secretless”

应使用 Best Available Credential Model，而不是为了架构纯洁性 invent insecure workaround。

一百五十一、例如 WordPress Application Password

如果 WordPress 原生集成暂时仍依赖 Application Password，那么改进方向可以是：

Agent
↓
Action Gateway
↓
Credential Broker
↓
Retrieve Application Password
↓
Call WordPress

而不是 Every Agent stores WordPress Password。

一百五十二、这样至少把长期 Secret 限制在 Credential Plane

Agent Plane:
No Secret

Gateway:
No persistent copy

Credential Store:
Controlled Secret

Adapter:
Temporary exposure

一百五十三、进一步还可以为 Application Password 建立 Rotation

rotation_epoch
last_rotated
next_rotation
credential_owner
allowed_adapter

一百五十四、所以“不能完全 Secretless”不意味着“放弃 Secretless Architecture”

目标仍然是：

Reduce
where secrets exist

Reduce
who can read them

Reduce
how long they exist

Reduce
where they can be used

一百五十五、Credential Broker 本身会成为 Tier-0 Component

因为它可以 mint production access，所以它不能只是 another Agent。

一百五十六、Credential Broker 应有更高保障

至少包括：

Strong Workload Identity
Policy Enforcement
Minimal Network Exposure
Hardened Audit
Rate Limits
No LLM Reasoning
No Arbitrary Tool Access
Deterministic Issuance

一百五十七、为什么“不让 LLM 决定 Credential”？

因为 Should credential be issued? 应该由 structured policy 决定，而不是 LLM thinks this request looks reasonable。

一百五十八、LLM 可以辅助分析

例如 Explain why request may be risky，但 Credential Issuance 应该由机器可验证 Policy 决定。

一百五十九、完整 Credential Issuance State Machine

REQUESTED
↓
IDENTITY_VERIFIED
↓
ATTESTATION_VERIFIED
↓
AUTHORITY_VERIFIED
↓
CAPABILITY_VERIFIED
↓
POLICY_EVALUATED
↓
ISSUED
↓
ACTIVE
↓
EXPIRED

异常状态：

DENIED
REVOKED
INVALIDATED
COMPROMISED

一百六十、Credential Rotation 和 Credential Renewal 不一样

Renewal：same authority context extends session。

Rotation：new credential material replaces old material。

一百六十一、自动 Renewal 也需要重新检查上下文

不能 once authorized → renew forever。

一百六十二、Renewal 至少应该检查

Identity still valid?
Capability still valid?
Authority epoch current?
Policy epoch current?
Lease still current?
Incident state safe?

一百六十三、否则短期 Credential 会被 Renewal 机制重新变成长寿命 Credential

5 min
×
infinite renewal
=
effectively permanent

一百六十四、因此再增加一条原则

Short TTL
without
bounded renewal
does not guarantee
short-lived authority.

一百六十五、Identity Drift 也必须监控

第三十三篇已经建立 Configuration Drift / Policy Drift。

第三十五篇增加 Identity Drift / Trust Drift / Credential Drift。

一百六十六、Identity Drift 示例

Desired：

publisher workflow
→
publisher identity

Actual：

unapproved workflow
→
publisher identity

这是 Identity Mapping Drift。

一百六十七、Trust Drift 示例

原本：

trusted repo:
seo-publisher

后来误配置为：

repo = *

这是 Trust Policy Drift。

一百六十八、Credential Drift 示例

Policy：

TTL <= 15 min

实际：

credential valid
24 hours

这是 Credential Policy Drift。

一百六十九、这些都必须回到 Desired State Control Plane

Desired Identity Policy
↓
Actual Identity Configuration
↓
Diff
↓
Drift Detection

一百七十、Identity Configuration 本身也应该 GitOps 化

适合进入 Desired State 的包括 Trust Policies、Issuer Configuration、Audience Rules、Role Mapping、Federation Mapping、Credential TTL、Delegation Policy、Allowed Claims、Broker Policy。

一百七十一、但 Private Key 不进入 Git

Git 可以存 policy / reference / identifier，而不是 secret material。

一百七十二、Security Baseline 也应增加 Identity Baseline

No static cloud admin key
in GitHub Secrets

No production credential
in Agent prompts

Production credential TTL
<= 15 minutes

Every production action
must carry workload identity

Every credential issuance
must carry decision_id
and capability_id

一百七十三、Identity Health 必须可观测

Attestation Success Rate
Credential Issuance Rate
Credential Denial Rate
Expired Credential Use
Unknown Identity Requests
Federation Failure Rate
Trust Policy Drift
Credential TTL Distribution
Static Secret Count
Shared Secret Count
Credential Renewal Count
Revocation Latency

一百七十四、一个特别重要的指标：Static Production Secret Count

目标不是立刻 0，而是 continuously decreasing。

一百七十五、第二个关键指标：Credential Exposure Time

即 credential issued → credential expired/revoked。

一百七十六、第三个关键指标：Unattributed Production Action Rate

表示有多少 Production Mutation 无法可靠关联 Workload Identity + Credential Session + Capability。

理想值：0。

一百七十七、第四个关键指标：Delegation Depth

Delegation Chain 越深，provenance complexity 通常越高。

一百七十八、第五个关键指标：Credential Scope Excess

例如 Credential Scope / Required Action Scope。偏差越大，说明 downstream privilege 越粗。

一百七十九、Chaos / Game Day 同样需要 Identity Test

例如：

Steal expired token
↓
Attempt action
↓
DENY

一百八十、再测试 Replay

Replay token
from different workload

观察 Does binding reject it?

一百八十一、再测试

Valid Identity
+
Revoked Capability
↓
DENY

一百八十二、再测试 Wrong Audience

Valid Credential
+
Wrong Audience
↓
DENY

一百八十三、再测试 GitHub OIDC from unapproved branch

必须无法获得 production credential。

一百八十四、再测试 Delegation Abuse

Agent A
delegates authority
it does not own
to Agent B
↓
DENY

一百八十五、再测试 Identity Provider Compromise Scenario

如果 Federation Issuer 发生异常，系统应该能够：

disable trust
freeze credential issuance
invalidate capabilities
activate incident control

一百八十六、所以 Identity Provider 也进入 Dependency Risk

Identity Infrastructure is Tier-0 Dependency。

一百八十七、完整架构

                         INTENT
                           │
                           ▼
                  WORKLOAD INSTANCE
                           │
                           ▼
                     ATTESTATION
                           │
                           ▼
                  WORKLOAD IDENTITY
                           │
                           ▼
                    AUTHORITY GRAPH
                           │
                           ▼
                    GOVERNANCE ENGINE
                           │
                           ▼
                       DECISION
                           │
                           ▼
                      CAPABILITY
                           │
                           ▼
                 COORDINATION ENGINE
                           │
                           ▼
                  CREDENTIAL BROKER
                           │
              ┌────────────┼────────────┐
              │            │            │
              ▼            ▼            ▼
          FEDERATION     STS TOKEN    DYNAMIC SECRET
              │            │            │
              └────────────┼────────────┘
                           ▼
                     TOOL ADAPTER
                           │
                           ▼
                    ACTION GATEWAY
                           │
                           ▼
                    TARGET SYSTEM
                           │
                           ▼
                     VERIFICATION
                           │
                           ▼
              EXECUTION / IDENTITY RECEIPT
                           │
                           ▼
                  IMMUTABLE AUDIT EVIDENCE

一百八十八、系统由此形成四个平面

Identity Plane 回答 Who is calling?

Authority Plane 回答 What may this identity do?

Credential Plane 回答 How does this authorized identity access the target?

Evidence Plane 回答 Can we later prove what identity, authority, credential and action were involved?

一百八十九、四个平面不能互相替代

Identity:
who

Authority:
may what

Credential:
authenticate how

Evidence:
prove afterwards

一百九十、一个 JWT 不能同时自动解决四个问题

一百九十一、Identity Token 也不等于 Access Token

Identity Token asserts identity。

Access Token authorizes access within a resource context。

Capability encodes project-level authorized action。

这三者必须分开。

一百九十二、否则系统最终会变成

Token exists
→
Allow everything

重新回到 API Key 模式。

一百九十三、第（三十五）篇新的 Safety Invariants

此前已经有：

No Valid Decision
→
No Capability

No Capability
→
No Production Mutation

No Valid Coordination Right
→
No Exclusive Write

Stale Lease Epoch
→
No Production Mutation

现在增加：

No Verified Workload Identity
→
No Privileged Credential

一百九十四、再增加

No Valid Capability
→
No Production Credential

一百九十五、再增加

Expired Credential
→
No Production Access

一百九十六、再增加

Wrong Audience
→
No Credential Acceptance

一百九十七、再增加

Credential Scope
must not silently
expand Authority Scope

一百九十八、再增加

Delegated Credential
must not exceed
Delegated Authority

一百九十九、再增加

Production Credential
must not enter
Reasoning Context
by default

二百、再增加

No Credential Provenance
→
No Trusted Credential Session

二百零一、最后增加

No Verifiable Identity Binding
→
No Strong Attribution Claim

结语：真正的 Agent 身份，不是一个名称，也不是一串 API Key，而是一条从运行环境到生产行为都能够验证的信任链

第（三十四）篇解决的是 Who may act now?

第三十五篇继续向下追问：Who exactly is this actor?

如果这个问题回答不了，那么 Authority Graph、Capability、Lease、Governance 最终都可能建立在 spoofable principal name 之上。

于是生产 Agent 必须从：

Agent Name
+
Static API Key

升级到：

Runtime
↓
Attestation
↓
Workload Identity
↓
Authority
↓
Capability
↓
Credential Broker
↓
Short-lived Credential
↓
Production Action
↓
Verifiable Evidence

真正成熟的 Identity Architecture 不应该再不断问 Where do we store the API key? 而应该逐步转向：

Can this workload
prove who it is?

Can the system
derive only the credential
it currently needs?

Can that credential
expire automatically?

Can it be restricted
to one audience?

Can delegation remain
visible?

Can stale authority
be rejected?

Can every production action
be tied back to the
actual workload instance?

这时 Identity 不再是登录系统中的一个账号，而成为 Production Control Primitive。

同样，Credential 不再是长期保存的资产，而开始成为 Ephemeral Execution Material。

这也是 Secretless Agent 真正应该追求的目标：

不是假装系统不存在任何 Secret，而是让生产 Agent 不再需要长期拥有可复制的生产 Secret。

因此我们目前形成的完整原则可以继续扩展为：

Execute Fast
Stop Faster
Recover Carefully
Learn Permanently
Release Progressively
Reconcile Continuously
Coordinate Explicitly
Identify Cryptographically

第三十五篇最核心的原则则可以压缩为：

Identity should be proven at runtime; privilege should be minted only when needed.

Prove Identity
↓
Evaluate Authority
↓
Mint Minimum Credential
↓
Perform Approved Action
↓
Destroy Credential
↓
Preserve Evidence

只有到这一步，所谓 No Agent Production Credential 才不再是一句安全口号。它开始成为真正可以实施的：

Secretless Agent Production Architecture

而 Authority Graph 也终于从 logical permission model 落到了 cryptographically grounded production identity system。

官方依据与工程边界说明

本文提出的 Workload Identity Control Plane、Credential Plane、Credential Broker、Credential Eligibility、Credential Provenance、Identity Trust Graph、Credential Scope Excess、Identity Drift、Credential Drift、Verifiable Execution Attribution 等，是本 SEO / GEO 自动化体系基于前述 Governance、Authority Graph、Desired State 与 Action Gateway 进一步形成的工程抽象，并不是 SPIFFE、SPIRE、GitHub、Google Cloud、AWS、HashiCorp、IETF 或 NIST 共同定义的一套统一 Agent Identity 标准。

SPIFFE / SPIRE：SPIFFE 为动态和异构环境定义软件工作负载身份标准，包括 SPIFFE ID、SVID 和 Workload API；SPIRE 是其生产级实现之一，通过 Node 与 Workload Attestation 识别工作负载并签发身份材料。官方资料：https://spiffe.io/docs/latest/spiffe-specs/spiffe_workload_api/

SPIFFE Workload Endpoint：Workload Endpoint 的设计允许 workload 在没有预先持有应用认证 Secret 的情况下通过本地端点获取身份，由实现通过操作系统或 orchestrator 等带外信息判断调用者真实性，是本文 Secretless Bootstrap 模型的重要依据。官方资料：https://spiffe.io/docs/latest/spiffe-specs/spiffe_workload_endpoint/

GitHub Actions OIDC：GitHub Actions 支持 Workflow 申请 OIDC Token，并通过与云服务建立 OIDC Trust 换取短期访问 Token，从而减少在 GitHub Secrets 中存储长期云 Credential 的需要。官方资料：https://docs.github.com/en/actions/concepts/security/openid-connect

Google Cloud Workload Identity Federation：Google Cloud WIF 允许 GitHub、GitLab、AWS、Azure 及其他 OIDC/SAML 身份提供方的 workload 使用外部身份换取短期 Google Cloud Credential，而不依赖长期 Service Account Key。官方资料：https://docs.cloud.google.com/iam/docs/workload-identity-federation-with-deployment-pipelines

AWS STS：AWS STS 提供临时 Security Credentials；AssumeRoleWithWebIdentity 可依据受信任 Web Identity / OIDC Token 签发临时角色 Credential，无需在调用应用中预先部署长期 AWS Credential。官方资料：https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html

HashiCorp Vault：Vault Dynamic Secrets 可以为数据库等系统动态生成生命周期受控的 Credential；GitHub Actions 也可以使用 OIDC/JWT 身份向 Vault 认证，再获取短期 Token 或 Secret。官方资料：https://developer.hashicorp.com/vault/tutorials/db-credentials/database-secrets

OAuth 2.0 Token Exchange：RFC 8693 定义了 Token Exchange，并明确区分 Delegation 与 Impersonation，同时提供 act 等 Actor 表达方式。本文借鉴这一语义构建 Agent Delegation Chain，但本文的 Agent Capability / Credential Binding Schema 属于项目自定义设计。官方资料：https://www.rfc-editor.org/info/rfc8693

NIST Zero Trust：NIST SP 800-207 强调不应因为网络位置、资产归属等因素自动给予隐式信任；SP 800-207A 进一步强调云原生和多云访问控制应重视 application/service identities，并讨论 SPIFFE 一类应用身份基础设施。官方资料：https://csrc.nist.gov/pubs/sp/800/207/final

NIST Non-repudiation：NIST 将 Non-repudiation 与主体行为归属、身份绑定、Chain of Custody 等控制联系起来；FIPS 186-5 则说明数字签名能够帮助验证数据完整性和签名者身份，并可形成向第三方证明签名来源的证据。因此本文有意把多数 Agent 审计场景称为 Verifiable Execution Attribution，而不是仅凭 JWT 或普通日志就宣称达到完整法律或密码学意义上的 Non-repudiation。官方资料：https://csrc.nist.gov/pubs/fips/186-5/final

第（三十六）篇自然承接方向

第三十五篇建立以后，我们已经拥有：

Who is the workload?
↓
Why should we trust
that identity?
↓
What authority
may it receive?
↓
What short-lived credential
may it obtain?

下一层自然会出现另一个问题：

What happens when
an Agent talks to
another Agent?

How is context propagated?

How do we preserve
causality across
multiple services?

How do we prevent
confused-deputy attacks?

How do downstream services
know which original intent
caused a request?

How do we bind
user intent,
agent delegation,
capability,
trace and message
across an entire
distributed workflow?

因此第（三十六）篇最自然的方向是：

End-to-End Context Propagation / Causality / Request Identity / Confused Deputy / Deputy Authorization / Trace Context / Intent Binding / Message Integrity

把 Identity 继续向 Distributed Causality 推进。

Original Intent
↓
Request Identity
↓
Delegation Context
↓
Capability
↓
Trace Context
↓
Agent A
↓
Agent B
↓
Tool
↓
Production Effect

真正解决：当一次生产行为跨越多个 Agent、Service、Queue 和 Tool 以后，系统怎样仍然能够证明这个最终 Side Effect 到底来自哪个原始 Intent，又有没有在传递过程中被“权限更大的中间 Agent”错误放大。