当 AI Agent 开始自主调用工具、操作业务系统，甚至代表人类执行交易时，一个过去并不突出的问题正在变得越来越重要：我们究竟如何确认一个 Agent 的身份？

传统软件系统已经有成熟的身份认证体系。用户有账号，服务有 API Key，应用有 OAuth 凭证，服务器有数字证书。

但这些机制能够回答的问题，主要是“谁在发起请求”，而不是“这个 Agent 究竟是什么、运行状态是否可信，以及它凭什么执行当前操作”。

一个拥有合法 API Key 的 Agent，可能已经更换了底层模型；一个通过身份认证的 Agent，可能正在执行超出原始授权范围的操作；一条具有有效数字签名的交易记录，也不意味着系统已经解决了事故发生后的责任认定问题。

对于自主智能体而言，身份不应该只是一个标识符，而应该是一组能够持续验证的安全属性。

2026 年 10 月，来自 BRAC University 等机构的研究团队在 arXiv 发布了一篇论文：《Who is the "I" in AI? Establishing Decentralized Identity and Accountability for Autonomous Agents》。

https://arxiv.org/pdf/2610.17126

论文提出了一个名为 ABCD Framework 的四层身份框架，试图将算法来源、运行时行为、密码学身份以及人类授权关系整合起来，为自主 Agent 建立一套可验证、可追溯的身份机制。

这篇论文最值得关注的地方，并不是又引入了一种新的身份标识，而是尝试回答一个更复杂的问题：

当 Agent 不再只是被动响应请求的软件，而是能够持续采取行动的自主执行主体时，传统身份认证体系还缺少哪些安全能力？

需要说明的是，这是一篇以形式化模型和安全性质论证为主的 arXiv 预印本。论文提出了有价值的架构思路，但尚未通过大规模真实部署实验验证其整体有效性。本文将同时分析它的设计价值与技术局限。

为什么 AI Agent 需要独立的数字身份？

1. 一个合法的 API Key，并不能证明 Agent 仍然可信

假设一家企业部署了一个采购 Agent。它能够查询供应商、比较报价、生成采购订单，并在授权范围内调用财务系统完成付款。

企业为它分配了独立的服务账号，并通过 API Key 控制访问权限。从传统软件安全的角度看，这已经具备了基本的身份认证与访问控制能力。

但当 Agent 开始自主运行后，情况就变得复杂了。

第一，运行实体可能发生变化。 Agent 的基础模型、微调版本、System Prompt、Skill 或工具配置可能被修改。即使身份凭证没有变化，它实际执行的逻辑也可能已经不同。

第二，行为可能偏离预期。 Agent 可能因为上下文变化、模型更新、外部数据污染或运行环境异常，采取与过去明显不同的行动。

第三，授权可能失效。 原本只允许采购普通办公用品的 Agent，可能试图访问其他业务系统，或者继续使用已经过期的权限。

第四，责任链可能断裂。 发生异常交易后，企业可能只能确认某个服务账号执行了操作，却无法完整还原实际运行的是哪个 Agent 实例、由谁部署、依据什么授权行动。

这些问题说明，身份认证与可信验证不是一回事。

一个系统可以成功验证 Agent 持有合法凭证，却仍然无法确认它运行的是不是经过批准的版本，也无法保证它的行为符合预期。

2. 从“证明你是谁”到“证明你是什么、能做什么”

传统身份系统主要关注身份标识、凭证有效性以及访问权限。

而自主 Agent 的身份管理至少需要回答四个问题：

  • 你是谁？ 能否通过可靠的密码学机制确认调用方身份？

  • 你运行的是什么？ 当前模型、配置及关键组件是否来自可信来源？

  • 你的行为是否正常？ 实际运行表现是否偏离经过验证的基线？

  • 你凭什么行动？ 谁授予了你哪些权限，这些权限是否仍然有效？

这四个问题并不完全相同，也不能依靠单一技术解决。

数字签名可以证明某个密钥签署了请求，却不能直接证明请求使用了正确的模型；模型哈希可以识别特定文件，却不能单独证明线上进程正在运行该文件；授权凭证可以限定 Agent 的操作范围，却无法保证 Agent 不会在授权范围内作出错误决策。

论文的 ABCD 框架正是试图把这些不同层次的验证能力整合到一套身份模型中。

ABCD 四层身份框架

论文将 AI Agent 的身份拆分为四个维度：Algorithmic Fingerprint、Behavioural Fingerprint、Cryptographic Identity 和 Delegation。

这四个维度分别对应算法指纹、行为指纹、密码学身份以及授权与责任关系。

1. A：Algorithmic Fingerprint——算法指纹

算法指纹用于描述 Agent 的静态计算属性与来源信息。

论文列出的典型属性包括：

  • modelHash：模型文件的哈希摘要。

  • architectureID：模型架构标识。

  • fineTuneHash：微调版本的哈希。

  • cfgSnap：配置快照。

  • versionTag：版本标签。

  • issuerDID 与 issuerSignature：声明签发者的身份及签名。

这些属性可以组合成一个可验证的算法来源声明。

例如：

Agent ID: procurement-agent-01Model Hash: sha256:...Fine-tune Hash: sha256:...Config Snapshot: sha256:...Version: v2.1Issuer Signature: ...

如果企业规定采购 Agent 只能运行经过审批的 v2.1 版本，那么其他系统就可以检查其登记的版本与签名，确认该声明是否符合要求。

算法指纹的价值，是将 Agent 的身份与其关键计算组件的来源关联起来。

但这里有一个必须区分的概念：

模型指纹证明的是特定模型或文件的身份，不是线上运行时的完整性证明。

如果 Agent 在注册时登记了正确的模型哈希，之后却被替换了底层模型，静态登记信息本身不会自动发生变化。

同样，即使模型权重没有变化，System Prompt、Skill、工具路由或知识库也可能被修改，从而改变 Agent 的实际行为。

因此，算法指纹应被理解为可信来源与版本管理的基础，而不是对运行时完整性的最终证明。

2. B：Behavioural Fingerprint——行为指纹

如果 A 层回答的是“Agent 声明自己运行什么”，那么 B 层关注的就是“Agent 实际表现如何”。

论文将行为指纹定义为特定观测窗口内的动态运行指标集合。

这些指标包括：

  • latency95：推理延迟的第 95 百分位数。

  • refusalRate：拒答率。

  • interactionPattern：交互模式。

  • decisionTraces：决策轨迹。

  • riskProfile：风险特征。

  • benchmarkScore：基准评测得分。

  • taskProfile：任务分布特征。

这些指标可以在一段时间内持续采集，并与已登记的算法属性及历史基线进行比较。

例如，一个经过验证的 Agent，正常情况下推理延迟的第 95 百分位数约为 200ms。如果近期的观测值突然升高至 280ms，系统就可以根据预设阈值判断是否需要触发异常告警。

论文将 A 层和 B 层之间的关系称为 A–B Coherence，即算法与行为的一致性。

其基本逻辑可以概括为：

  • A 层提供静态版本信息和预期属性。

  • B 层持续采集运行时行为指标。

  • 一致性策略比较预期与实际观测。

  • 当偏差超过容忍阈值时，触发异常告警或进一步验证。

这里真正值得关注的是，作者不再将 Agent 身份看成注册时一次性确认的属性，而是试图引入持续验证机制。

不过，行为指纹存在一个根本限制：行为异常不等于模型被篡改，行为正常也不等于模型没有被篡改。

推理延迟上升可能来自 GPU 资源竞争或网络拥塞；拒答率变化可能源于用户输入分布变化；攻击者也可能刻意选择不会明显改变总体统计指标的修改方式。

因此，行为指纹更适合用于发现运行时异常，而不能单独承担确定性的模型身份验证任务。

3. C：Cryptographic Identity——密码学身份

C 层负责为 Agent 建立可验证的密码学身份。

论文采用去中心化标识符 DID（Decentralized Identifier）以及公私钥签名机制，将 Agent 的身份标识与密钥控制权关联起来。

在一个典型的验证流程中：

  • Agent 持有与其身份关联的私钥。

  • 验证方提供随机挑战，或者要求 Agent 对指定内容签名。

  • Agent 使用私钥生成签名。

  • 验证方根据可信的公钥和身份解析结果检查签名。

如果验证成功，系统就能够确认调用方具备相应私钥的控制能力。

这与 API Key 有一定相似之处，但公私钥签名能够提供更明确的签名验证机制，也便于将身份声明、授权凭证和审计记录绑定起来。

DID 则提供了标识符及其解析机制，使不同系统能够按照对应的 DID Method 查找身份文档和公钥等信息。

不过，DID 并不天然意味着去中心化注册表一定可信，也不意味着所有 DID 都必须部署在区块链上。具体信任模型取决于所采用的 DID Method、解析机制及密钥管理方案。

更重要的是，密码学身份只能证明相应密钥的控制权，不能自动证明密钥持有者运行的是可信模型。

一个恶意 Agent 也可以拥有合法的 DID 和有效签名。身份认证成功，只能说明身份验证环节通过了，不能据此认定其所有行为都值得信任。

4. D：Delegation——授权与责任关系

D 层关注 Agent 与人类主体之间的归属、委托和授权关系。

在企业系统中，Agent 通常不是独立于组织之外的行动者。它由某个组织部署，由某个业务主体授权，并在特定范围内执行操作。

论文通过 Ownership 和 Delegation 两类关系表达这种关联。

例如，Alice 将交易权限授予 AgentX：

Owner: AliceAgent: AgentXPermission: Trade up to $50,000Valid From: 2026-10-01Valid Until: 2026-10-31Revocation Status: Active

这里的授权不仅可以限定操作类型，还可以限定有效时间、交易额度以及其他业务约束。

当 Agent 发起操作时，系统需要同时验证身份和授权条件。

授权有效期结束后，Agent 不应继续使用该授权；如果 Alice 提前撤销权限，执行路径也应该及时拒绝后续操作。

论文进一步提出使用可验证凭证（Verifiable Credentials，VC）表达委托关系，以便通过数字签名验证授权声明。

D 层的重要价值，是让每一次 Agent 操作都能够关联到相应的授权来源。

但需要明确：密码学上可追溯的授权关系，并不自动等于法律意义上的责任已经得到完整解决。

如果密钥被盗、企业存在管理过失，或者多个主体共同参与了 Agent 的开发、部署与运行，最终责任仍然需要结合实际事实、合同关系及适用法律判断。

四层机制如何形成安全闭环？

四个维度并不是简单地把四类属性放在一起。

在论文的设计中，C 层提供密码学身份锚点，A 层记录算法来源，B 层持续观察实际行为，D 层则将 Agent 的行动限制在被授权的范围内。

四层组合后，可以形成一条完整的验证链：

身份确认 → 来源校验 → 行为监测 → 授权检查 → 操作执行 → 记录与追溯。

为了说明这套机制如何工作，论文以一个名为 AgentX 的 DeFi 交易机器人构造了案例。

1. 注册阶段：建立可信身份与授权关系

假设 Alice 拥有一个交易 Agent，准备允许它在指定期限内进行交易。

系统首先为 AgentX 建立密码学身份，并登记算法指纹：

  • 模型哈希：sha256:4f7a...

  • 版本：v2.1

  • 预期延迟目标：200ms

  • 所有者：Alice

随后，Alice 授予 AgentX 一项有效期为 30 天、单笔交易额度上限为 50,000 美元的权限。

至此，系统不仅知道 AgentX 的身份，还记录了它声明运行的版本以及授权来源。

2. 运行阶段：发现行为偏离

运行到第 15 天时，系统发现 AgentX 的延迟指标出现明显变化。

论文构造的示例中，历史延迟基线均值为 200ms，标准差为 15ms，系统采用 3 倍标准差作为控制阈值。

计算过程如下：

控制阈值 = 3 × 标准差 = 3 × 15 ms = 45 ms

这里，标准差用来描述历史指标的波动程度。采用 3 倍标准差作为阈值，是一种示例性的统计控制方法，并不意味着所有 Agent 都应该使用这个固定阈值。

近期观测到的延迟指标为 280 ms，因此实际偏差为：

实际偏差 = |观测值 − 基线均值|

实际偏差 = |280 − 200| = 80 ms

因为实际偏差 80 ms 大于控制阈值 45 ms，所以一致性策略触发异常告警。

需要注意，这个结果只说明观测指标超出了预设阈值，并不意味着系统已经确定 Agent 被替换了模型。

告警可能对应模型变化、资源竞争、运行环境异常等多种原因。后续仍然需要结合部署记录、独立遥测和进一步验证来判断。

3. 身份冒用阶段：拒绝伪造身份

在告警处理期间，另一个机器人 AgentY 尝试冒用 AgentX 的身份。

如果 AgentY 无法提供 AgentX 对应的有效签名，系统就会拒绝其身份声明。

这项能力主要依赖密码学签名的不可伪造性，以及可靠的身份解析机制。

它能够防止攻击者在不掌握目标私钥的情况下伪装成已经注册的 Agent，但不能单独解决批量创建大量合法新身份的问题。

4. 撤销阶段：阻止高风险操作继续执行

Alice 根据异常告警决定撤销 AgentX 的交易权限。

论文为超过 10,000 美元的交易设置了 64 个区块的挑战窗口。在每个区块间隔约 12 秒的示例设定下，这相当于约 12.8 分钟。

假设一笔 50,000 美元的交易已提交，而 Alice 在交易提交后第 5 个区块发起撤销。若撤销在第 25 个区块完成确认，就可以早于第 64 个区块的交易执行资格时间生效。

当系统最终检查授权状态时，交易会因为授权已被撤销而被拒绝。

这段流程展示了 ABCD 框架的核心思想：

B 层的异常告警可以触发 D 层的权限治理，而 C 层的身份验证与可信状态读取则为执行决策提供基础。

论文的形式化证明

论文不仅提出架构，还给出了三个主要安全性质的形式化论证，并辅以两个推论。

这部分尤其值得仔细分析，因为“提出安全机制”与“证明安全机制有效”之间存在很大区别。

1. 行为一致性：满足特定条件的模型篡改可以被检测

论文的第一项主要安全性质关注算法指纹与行为指纹之间的一致性。

其核心逻辑是：如果模型被替换后，至少一个被监控的行为指标超出了允许的偏差范围，那么一致性策略就会发现异常。

这个推理在给定前提下是成立的。但它并没有证明所有模型替换都会产生可观测的行为变化。

如果攻击者替换模型后，能够让所有被监控的指标继续处于容忍范围内，那么该检测机制就可能无法发现问题。

论文也通过推论明确讨论了这种规避条件：攻击者如果能让所有受监控指标在整个观测窗口内保持在阈值以内，就可能避开这项保证。

因此，真正尚待解决的问题不是简单地证明“超过阈值就告警”，而是：

面对不同类型的模型替换、Prompt 篡改和 Skill 污染，究竟有多少攻击会产生足够明显的行为偏差？

这需要通过真实攻击样本、正常业务变化和对抗性测试进行评估。

2. 密码学身份：可以抵御冒用，但不等于解决女巫攻击

论文的第二项主要安全性质讨论身份冒用。

在签名算法安全、私钥没有泄露、身份解析正确等前提下，攻击者难以伪装成已经注册的目标 Agent。

这是数字签名体系能够提供的经典安全性质。

但需要区分身份冒用和女巫攻击。

身份冒用是指攻击者试图冒充一个已经存在的 Agent；女巫攻击则可能是攻击者批量创建大量各自合法、但由同一主体控制的身份。

一个攻击者完全可以生成大量独立密钥，并注册一批新的 DID。即使所有签名都有效，也不意味着这些身份对应着独立可信的主体。

论文将注册成本、链上费用等机制作为提高批量注册成本的手段，但这些措施属于经济层面的约束，并不是密码学签名本身提供的保证。

因此，ABCD 能够为身份冒用防御提供基础，却不能单凭这一层解决所有女巫攻击。

3. 授权强制执行：前提是所有关键操作都经过检查

论文的第三项主要安全性质讨论有界授权执行。

它将授权状态表达为归属关系、权限存在、有效时间和未撤销状态的组合。

只要所有条件满足，系统就允许对应操作；如果任一条件不满足，智能合约钱包就拒绝执行。

这个机制可以为授权边界提供较强的形式化保证。

但它依赖一个重要前提：所有受保护的操作都必须经过相应的授权检查。

如果 Agent 还持有可以绕过合约直接调用外部 API 的长期凭证，那么链上的授权逻辑就不能保证这些链下操作也会被阻止。

此外，授权撤销还涉及状态传播、最终确认和执行时机之间的竞态问题，不能仅凭一个“撤销成功”的状态就假设所有运行中的操作都立即失效。

4. 挑战窗口的形式化条件仍需要进一步澄清

论文还提出，通过给高价值交易设置挑战窗口，可以为授权撤销留出时间。

其设计方向是合理的：如果撤销能够在交易执行前完成确认，系统就有机会阻止已不再被授权的操作。

但在 Corollary 5 的证明中，作者将撤销提交时刻写为：

t_rev ≤ t₀ + Δ

并希望由此推出：

t_rev + λ < t₀ + Δ

这里各个符号的含义是：

  • t₀：交易提交时刻。

  • t_rev：授权撤销的提交时刻。

  • Δ：挑战窗口的长度。

  • λ：撤销所需的最大确认延迟。

问题在于，仅仅知道挑战窗口长度大于确认延迟，并不能保证在挑战窗口结束前任意时刻提交的撤销都能完成确认。

真正需要满足的时间条件是：

撤销提交时刻 + 撤销确认延迟 < 挑战窗口结束时刻

也就是：

t_rev + λ < t₀ + Δ

换句话说，撤销必须留出足够的确认时间。

如果将推论中的文字条件理解为“撤销必须在挑战窗口开启之前提交”，那么这一思路可以成立；但正文证明中使用的时间不等式需要与该条件保持一致。

论文的具体案例采用了提前撤销的情形，因此案例中的时间计算没有这个问题。不过，形式化推论的条件仍值得进一步澄清。

这一点并不否定挑战窗口机制本身的价值，而是说明：在 Agent 安全系统中，权限撤销的保证必须落实到明确的时间边界和实际执行路径，不能只停留在架构层面。

ABCD 框架的四个技术边界

整体来看，ABCD 框架建立了一套有价值的身份治理思路，但距离完整的企业级 Agent 可信执行体系仍有差距。

1. 静态指纹不等于运行时完整性证明

算法指纹可以记录模型和配置的来源，但如果缺少可信部署证明或可信执行环境，就无法单凭静态哈希确认线上进程正在运行对应的组件。

而且，一个 Agent 的行为不仅由模型权重决定，还受到 System Prompt、Skill、工具、知识库、长期记忆和编排逻辑等因素影响。

这些组件中的任何一个发生变化，都可能改变 Agent 的实际行为。

因此，企业更适合建立完整的 Agent 运行清单，对关键组件、版本、依赖关系和部署来源进行统一管理，而不是只登记一个模型哈希。

2. 行为监测存在误报、漏报与对抗规避

B 层依赖统计指标和一致性阈值。

阈值太严格，正常业务变化可能频繁触发告警；阈值太宽松，攻击者就可能在不显著改变统计指标的情况下实施恶意行为。

观测窗口也存在权衡：窗口过短，噪声和误报增加；窗口过长，异常发现又会变慢。

此外，如果监控指标完全来自 Agent 自身上报，已经被攻陷的 Agent 还可能伪造这些数据。

因此，企业需要尽可能引入独立采集的运行日志、工具调用记录和部署证明，并将行为异常检测作为持续风险评估机制，而不是将其当作绝对可信的身份凭证。

3. 责任追溯不等于责任已经得到解决

D 层能够将 Agent 的身份、授权人和具体操作关联起来，为事故调查提供证据。

但这不意味着责任认定、赔偿执行和法律争议已经得到解决。

企业需要进一步区分 Agent 的所有者、部署者、授权人、模型供应商和实际业务决策者，并根据具体场景明确各自的责任边界。

尤其在多 Agent 协作场景中，一项最终操作可能经历多个 Agent 的规划、工具调用与结果传递。如果没有完整记录调用链，仅记录最末端的 Agent 身份仍然不足以解释事故是如何发生的。

4. 去中心化身份并不意味着所有场景都必须上链

论文以 DID、可验证凭证和去中心化基础设施构建身份体系，并讨论了链上登记与交易授权机制。

但对于企业内部的 Agent 管理，现有 IAM、PKI、短期工作负载凭证以及集中式策略引擎，已经能够解决相当一部分问题。

去中心化身份的价值主要体现在跨组织、跨平台和多方互不完全信任的场景。

例如，不同企业的 Agent 需要相互验证身份和授权，或者多个组织需要共同维护一套可审计的身份声明。在这种情况下，DID 和可验证凭证可能更有价值。

反过来，如果所有 Agent 都由同一家企业部署和管理，强行引入区块链也可能增加系统复杂度、运维成本和授权撤销延迟。

ABCD 的核心价值是建立多维身份验证模型，而不是证明区块链是 Agent 安全的必要条件。

企业如何将 ABCD 转化为可落地的安全架构？

如果把这篇论文转化为企业级 Agent 安全产品设计，我认为最重要的不是直接复制它的去中心化技术栈，而是把四层模型映射到现有的身份、授权、运行时防护和审计能力中。

1. 建立 Agent 身份注册与版本管理体系

企业应为每个逻辑 Agent 分配独立身份，并为每次运行建立可追踪的实例标识。

身份档案至少应包含：

  • Agent 的所有者、部署者和业务用途。

  • 基础模型、微调版本和关键配置的摘要。

  • Skill、工具及其他重要依赖的版本信息。

  • 身份凭证、签发记录和有效期。

  • 已批准的权限范围和风险等级。

模型升级、Skill 变更或关键配置修改时，应触发版本更新与必要的安全评测。

这里需要区分逻辑身份和运行实例：同一个 Agent 可以拥有多个运行实例，也可以在经过批准的版本之间升级，但不能因此失去身份和审计上的连续性。

2. 把授权检查放在真正的执行路径上

这是整个架构中最重要的控制点。

无论 Agent 使用 MCP、内部工具还是外部 API，都应该在实际执行操作的边界进行授权校验。

例如：

  • 读取知识库：检查数据范围和项目权限。

  • 调用外部 API：检查目标服务、操作类型和访问范围。

  • 发起交易：检查单笔限额、累计预算和审批要求。

  • 修改生产配置：检查是否需要人工确认。

  • 高风险操作：要求二次审批或额外验证。

授权不应只是写在 Agent 的 System Prompt 中，而应该由工具网关、服务端策略引擎或其他可信执行组件强制落实。

这样，即使 Agent 产生了不符合预期的计划，也不能仅凭自身决定突破实际权限边界。

3. 引入持续行为监测与动态收权

B 层最适合转化为运行时风险检测能力。

企业可以从相对容易采集的指标开始，例如工具调用分布、敏感资源访问频率、异常交易规模、错误率、延迟变化以及策略违规事件。

当行为偏离基线时，系统不必只有“允许”和“终止”两种选择，还可以根据风险程度执行分级处置：

  • 低风险：记录事件并持续观察。

  • 中风险：降低调用频率或缩小可访问的数据范围。

  • 高风险：暂停高风险工具，要求人工复核。

  • 确认异常：撤销授权、隔离实例并启动审计。

需要注意，行为偏离应触发调查和风险控制，而不应直接等同于恶意行为的最终判定。

4. 建立完整的 Agent 操作审计链

企业最终需要能够回答：谁授权了 Agent，哪个实例在什么版本下执行了什么操作，使用了什么工具，访问了哪些资源，以及最终产生了什么结果。

一条完整的审计链可以表达为：

授权主体 → Agent 身份 → 运行实例 → 模型与配置版本 → 工具调用 → 资源变更 → 执行结果。

关键日志应由可信组件独立采集，并通过完整性保护机制防止事后篡改。

当 Agent 参与多步工作流时，还应记录不同 Agent 之间的调用关系，避免责任链在任务转交过程中断裂。

5. 分阶段实施，而不是一开始就建设完整的去中心化体系

更现实的落地路线可以分为四个阶段。

第一阶段：身份与授权治理。 为 Agent 分配独立身份，建立最小权限、短期凭证、授权有效期和可撤销机制。

第二阶段：来源与版本治理。 将模型、Prompt、Skill 和工具依赖纳入版本管理，对关键变更建立审批与安全评测流程。

第三阶段：运行时持续验证。 建立行为基线、异常检测、独立日志采集和动态收权机制，重点评估误报率、漏报率和检测延迟。

第四阶段：跨组织身份互认。 当不同企业或平台之间需要相互验证 Agent 的身份、能力声明和委托授权时，再考虑引入 DID、可验证凭证及适合多方信任的基础设施。

这条路线的关键在于：先把身份、权限和执行路径管住，再逐步引入更复杂的可信验证能力。

从 Agent 身份走向 Agent 治理

回到最初的问题：AI Agent 真的需要自己的数字身份证吗？

我的判断是，需要，但不能把它理解为给 Agent 分配一个 ID 就完成了身份建设。

随着 Agent 逐步从对话工具转变为能够自主规划、调用工具和改变外部系统状态的执行主体，企业需要的不仅是知道它叫什么，还需要确认它的来源、运行状态、授权范围和操作记录。

ABCD 框架提供了一种值得参考的组织方式：

  • A 层回答 Agent 声明运行什么。

  • B 层观察 Agent 实际表现如何。

  • C 层验证 Agent 的密码学身份。

  • D 层记录谁授权了它，以及它被允许做什么。

但四层机制仍然存在明确的能力边界。

算法指纹不等于运行时完整性证明，行为异常检测不等于确定性攻击识别，密码学签名不等于主体天然可信，授权记录也不等于法律责任已经得到解决。

因此，这篇论文最值得借鉴的并不是某一种 DID 或区块链实现，而是它提出的治理思路：

Agent 的可信度不能只在注册时确认一次，而应当贯穿部署、运行、授权、执行和审计的整个生命周期。

未来企业面对的可能不再是几十个固定的自动化服务，而是数百甚至数千个能够动态创建、协作和调用工具的 Agent。

在这样的环境中，身份管理、运行时安全和责任追溯将不再是彼此独立的模块，而会逐渐汇聚为 Agent 基础设施中的一层核心安全能力。

而 ABCD 框架所提出的问题，正是这层基础设施需要回答的第一个问题：

当一个 Agent 开始独立行动时，我们如何确认它是谁、它是否仍然可信，以及它究竟有权做什么？

参考资料

  • Ahammod Munim Ramil et al., Who is the "I" in AI? Establishing Decentralized Identity and Accountability for Autonomous Agents, arXiv:2610.17126, 2026.

  • W3C, Decentralized Identifiers (DIDs) v1.0.

  • W3C, Verifiable Credentials Data Model v2.0.

本文基于论文原文进行技术解读，并对其形式化安全论证、适用边界与企业落地路径进行了进一步分析。论文中的交易场景和参数属于作者构造的示例，不应视为真实部署的实验结果。

声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。