Agent Trust Card 规范 ATC/1.0 发布：让 Agent 身份验证有据可查

Agent Trust Card 规范 ATC/1.0 发布：让 Agent 身份验证有据可查 | 前端进阶之旅

Full translation

完整中文译文

几周前，我注意到了一个令人不安的现象。7月13日我在 dev.to 上发布了 ATC（Agent Trust Card）概念——据我能查到的，这是该名称首次公开使用，架构为 CA + Ed25519 + trust score——之后，Microsoft AutoGen、OpenAI Cookbook、Continue 以及其他地方开始出现同名提案。我不会指责任何人抄袭——在 Agent 信任基础设施上出现巧合性趋同是可能的，因为这个问题是真实存在的，而且显而易见。

但事实是：谁先想到的并不重要。重要的是谁先交付了一份正式的、可版本化的、可测试的规范。

所以今天我发布 ATC/1.0——一份面向 Agent Trust Cards 的开放规范，包含：

10 项控制项（8 项必选，2 项可选）

JSON Schema 封装格式

Node.js 参考实现（使用 node:crypto + canonicalize）

5 个测试向量（最小有效实例、篡改实例、过期实例、错误 CA 实例、能力样本）

RFC 8032 Ed25519 签名

RFC 8785 JCS 规范 JSON

发布采用双许可证：规范本身开放（贡献者使用 W3C CG-FSA 条款），参考实现为 MNNC-1.0（AliceLabs 专有），测试向量为公共领域（CC0）。

如果你正在构建 Agent 运行时、MCP 服务器、A2A 客户端或 Agent 市场——请实现 ATC/1.0。符合性测试在仓库中。参考实现通过了所有测试。

为什么发布规范而不是捍卫优先级

1. 优先级争论在公开场合是无法赢的

我可以证明我7月13日的发布是"Agent Trust Card (ATC)"这一名称与完整架构（CA + Ed25519 + 信任分数）结合使用的最早公开记录。我无法证明后续发布类似工作的人是否先看到了我的文章。互联网不记录意图。所以优先级声明变成了一场"我说的/他们说的"游戏——这场游戏在公开场合是无法赢的。

而规范则是一个事实。它存在、有版本化、有测试向量。你可以运行它。这比按时间顺序主张优先级要难反驳得多。

2. 标准靠采用取胜，而非靠优先级

SSL 获胜不是因为 Netscape 发明了 HTTPS。SSL 获胜是因为每个浏览器都实现了它。TLS 工作组没有争论谁先想到了证书固定——他们发布了 RFC 7469，让采用率来决定胜负。

如果 ATC/1.0 成为 Microsoft AutoGen、OpenAI、Cline、Continue 和独立 Agent 运行时实现的规范，优先级问题就变得无关紧要了。规范本身就是答案。

3. 市场正在趋同——必须有人率先交付

在过去一个月里，我看到了：

A2A Agent Card（Google，2026年5月）——能力描述符，无加密信任

AgentCards（学术，2026年6月）——身份 + 能力凭证

OpenA2A AIP（Internet-Draft，2026年7月22日）——Ed25519 + 行为信任 + DID + 透明度日志

OATI（GitHub 主题，2026年7月29日）——更广范围：身份 + 委托授权 + 策略 + 签名收据

ATC（Edison Flores，2026年7月13日）——首次公开使用该名称，架构为 CA + Ed25519 + 撤销 + 能力 + 支付

所有这些都是从不同角度趋同于同一个问题。这不是威胁——这是市场验证。窗口期还在。必须有人来交付这份正式规范。

ATC/1.0 的具体内容

加密核心

Ed25519（RFC 8032）用于签名——快速、确定性、各语言标准库均支持

RFC 8785 JCS 用于规范 JSON——确定性 JSON 编码的唯一真正的标准

SHA-256 用于 payload 哈希（记录在 signed_payload_hash 中，以便验证者在检查签名前检测篡改）

签名过程有点微妙，因为存在先有鸡还是先有蛋的问题：signed_payload_hash 字段是信封的一部分，但不能是签名 payload 的一部分（你不能哈希一个包含自身哈希值的东西）。规范通过在规范化前同时设置 signature = "" 和 signed_payload_hash = "" 来解决这个问题——然后计算哈希，再签名，再存储两个值。

能力清单

ATC-003 声明了一个 Agent 在 5 个类别中被允许执行的操作：

Filesystem（read: none/own_dir/temp_dir/home_dir/system/all; write: 同上枚举）

Network（egress: none/allowlist/all; ingress: none/bound_ports/all）

Shell（exec: none/sandboxed/unrestricted; spawn: 同上）

Credentials（read_env: none/allowlist/all; read_files: 同上）

Process（subprocess: none/sandboxed/unrestricted; signals: none/own/all）

这直接映射到 OWASP MCP Cheat Sheet 对能力声明的要求。ATC/1.0 就是其具体格式。

信任分数语义

ATC-005 携带一个 trust_score，范围从 0（不信任）到 10（高度信任），外加一个派生的 risk_level：

关键在于，ATC-005 要求 decision_authority: "consumer"——意味着 ATC 携带的是一条建议，但托管消费 Agent 的运行时做出最终的信任决策。这是一个刻意的设计选择。CA 不会覆盖运行时的安全策略。

ATC-007 支持三种撤销检查方法：

ocsp——RFC 6960 OCSP，用于高安全部署

crl——RFC 5280 证书撤销列表

simple_json——由 CA 签名的 JSON 列表，用于低摩擦部署（这是 MarketNow 目前使用的方式）

撤销列表本身使用与 ATC-006 相同的 Ed25519 + JCS 流程由 CA 签名。

符合规范的验证者可以在无需任何网络调用的情况下验证 ATC，只要它缓存了 CA 的公钥。ATC 携带自己的证据（审计分数、沙箱结果、恶意软件扫描结果），所以验证者不需要重新审计。

如果 revocation_check_required: true，验证者必须在信任之前获取撤销列表——并且如果列表不可达，必须拒绝。

参考实现

Node.js 参考实现约 200 行，仅使用标准库加 canonicalize（RFC 8785 JCS）：

import { generateKeyPairSync, sign, verify, createHash, createPublicKey } from 'node:crypto';
import canonicalize from 'canonicalize';

export function issueATC(caKeyPair, agentKeyPair, partialPayload) {
  const atc = { /* ... build the envelope ... */ };
  // Set signature="" AND signed_payload_hash="" before canonicalizing
  const canonical = canonicalize({ ...atc, attestation: { ...atc.attestation, signature: '', signed_payload_hash: '' } });
  atc.attestation.signed_payload_hash = createHash('sha256').update(canonical).digest('hex');
  atc.attestation.signature = sign(null, Buffer.from(canonical), caKeyPair.rawPrivateKey).toString('base64');
  return atc;
}

export function verifyATC(atc, caPublicKeyBase64) {
  // Re-canonicalize with signature="" AND signed_payload_hash=""
  const canonical = canonicalize({ ...atc, attestation: { ...atc.attestation, signature: '', signed_payload_hash: '' } });
  // Check the hash
  const computedHash = createHash('sha256').update(canonical).digest('hex');
  if (computedHash !== atc.attestation.signed_payload_hash) return { valid: false, errors: ['hash mismatch'] };
  // Verify the signature
  const caPublicKey = createPublicKey({ key: Buffer.from(caPublicKeyBase64, 'base64'), format: 'der', type: 'spki' });
  const valid = verify(null, Buffer.from(canonical), caPublicKey, Buffer.from(atc.attestation.signature, 'base64'));
  return { valid, errors: valid ? [] : ['signature verification failed'] };
}

这就是整个加密核心。

测试向量（你现在就可以运行）

仓库附带 5 个测试向量，覆盖完整规范：

git clone https://github.com/edgarfloresguerra2011-a11y/marketnow.git
cd marketnow/docs/atc-spec
npm install canonicalize
node ./test-vectors/generate.mjs

=== ATC/1.0 Test Vectors Generator ===

CA public key: MCowBQYDK2VwAyEA...
Agent public key: MCowBQYDK2VwAyEA...

Issued minimal ATC: ATC-2026-0000001
  signature: CQnixwP9zmqQGrtMp6JjVBJHmgWYQVLo...
  signed_payload_hash: 7ccfc2081c5b94a6d2a9bfd4adc6c92f899aa9968fa605d71ccdba3cf3b02551

Verification (minimal valid): { valid: true, errors: [] }
Verification (tampered):       { valid: false, errors: ['signed_payload_hash mismatch', 'Ed25519 signature verification failed'] }
Verification (expired):        { valid: false, errors: [..., 'ATC expired'] }
Verification (wrong CA):       { valid: false, errors: ['CA public key mismatch', ...] }

=== All test vectors generated and verified ===

如果你在 Rust 或 Python 中实现 ATC/1.0，可以使用这些相同的测试向量来验证你的实现产生字节级相同的签名。这就是符合性的含义。

先前技术和公开记录

我想对 ATC 之前存在什么、之后出现了什么保持诚实。

A2A Agent Card（Google，2026年5月22日）——能力描述符，无加密信任，无 CA，无撤销。这是 Agent 元数据的先前技术，而非信任方面的。

AgentCards（学术 / Emergent Mind，2026年7月2日）——机器可验证的身份 + 能力凭证。仅概念层面——无 CA，无 Ed25519 要求，无运行时强制执行。

我并不声称自己发明了 Agent 身份或 Agent 凭证。A2A 和 AgentCards 先于 ATC 出现，并解决了重叠的问题空间。

ATC 起源（2026年7月13日）

我的 dev.to 文章"AI agents need SSL certificates too — so I built ATC (Agent Trust Card)"，据我最佳调研，是将特定名称"Agent Trust Card (ATC)"与 CA + Ed25519 + Sentinel trust score + verify + revoke + capabilities + payment integration + Agent A → ATC → Agent B 流程结合使用的最早公开记录。

我不声称 Microsoft、OpenAI 或 Continue 抄袭了 Edison。巧合性趋同是可能的，而且问题是真实的。我只声明时间顺序。

带有引用的完整时间线在 PRIOR-ART-TIMELINE.md 中。

行动呼吁

1. 如果你构建 Agent 运行时

如果你构建 Agent 运行时（Claude Desktop 插件、Cursor 扩展、Cline 插件、Continue 插件、LangChain 工具、LlamaIndex 工具、AutoGen 扩展），实现 ATC/1.0 验证。参考实现约 200 行。测试向量是公共领域的。

如果你不确定是否信任向你出示 ATC 的 Agent，就不要信任它——这就是 decision_authority: "consumer" 的含义。ATC 是证据，不是裁决。

2. 挑战先前技术时间线

如果你找到了早于2026年7月13日的公开可验证 artifact，描述了特定的 ATC 架构（CA + Ed25519 + trust score + 撤销 + 能力），请对 PRIOR-ART-TIMELINE.md 发起 PR。我会更新时间线并给你署名。

我不会删除与我叙事相矛盾的条目。该文档的目的是真相，而非宣传。

3. 在规范上竞争，而非在优先级上

如果你有竞争性提案（OpenA2A AIP、OATI、你自己的）——我们来谈谈互操作性。标准靠采用取胜。如果你的规范更好且被采用，你就赢了。如果 ATC/1.0 更好且被采用，我就赢了。市场来决定。优先级不算。

路线图

ATC/1.0 是 v1.x 的底线。路线图如下：

ATC/1.0（本文件，2026年8月10日）：厂商规范、参考实现、测试向量

ATC/1.0 + 采用（2026年Q3-Q4）：至少 2 个独立实现通过符合性测试

ATC/1.1（2026年Q4）：ML-DSA 后量子签名、CA 密钥轮换协议、委托链

W3C CG 提交（2027年Q1）：提交至 W3C 社区组进行更广泛评审

IETF Internet-Draft（2027年Q2）：作为 IETF 个人草案提交

ATC/2.0（2027年）：透明度日志（Merkle）、DID 集成、能力撤销（对比卡片撤销）

我们不急于进入标准机构。标准机构奖励实现而非想法。ATC/1.0 先交付；标准化随后跟进。

npx -y marketnow-mcp@1.9.0

然后问 Claude Desktop："验证 card_id ATC-2026-7777670 的 ATC"——Claude 会用 card_id 调用 marketnow_verify_trust，它会访问 MarketNow ATC API 并返回验证结果。

或直接阅读规范：

Spec: https://github.com/edgarfloresguerra2011-a11y/marketnow/blob/master/docs/atc-spec/SPEC.md

JSON Schema: https://github.com/edgarfloresguerra2011-a11y/marketnow/blob/master/docs/atc-spec/schemas/atc-1.0.json

参考实现: https://github.com/edgarfloresguerra2011-a11y/marketnow/blob/master/docs/atc-spec/reference-impl/atc-1.0.mjs

测试向量: https://github.com/edgarfloresguerra2011-a11y/marketnow/tree/master/docs/atc-spec/test-vectors

先前技术时间线: https://github.com/edgarfloresguerra2011-a11y/marketnow/blob/master/docs/atc-spec/PRIOR-ART-TIMELINE.md

PR 欢迎。Issue 欢迎。竞争性规范欢迎。

市场正在趋同。让我们交付这份规范。

MarketNow 是 AI Agent 的安全基础设施，由 AliceLabs LLC（美国怀俄明州）构建。创始人：Edison Flores。Sentinel 审计管道已执行 1,211,488 次安全检查，隔离了 80 个恶意技能。审计报告：marketnow.site/api/audit-report.json。ATC/1.0 规范：github.com/edgarfloresguerra2011-a11y/marketnow/tree/master/docs/atc-spec。