技术深度解析
FIDO联盟应对AI代理身份问题的方案，堪称密码学工程的一堂大师课。它建立在已保护数十亿次通行密钥认证的WebAuthn和CTAP协议之上。核心挑战在于：AI代理并非静态实体，而是一个动态、有状态、甚至可能自我修改的软件。标准的公钥基础设施（PKI）证书远远不够，因为它只能证明某个特定密钥在某个特定时间被使用，却无法证明运行该密钥的软件正是预期中未经篡改的代理。
拟议的解决方案——我们暂且称之为“Agent Attestation”（代理证明）——引入了三层绑定机制：
1. 身份层（Identity Layer）： 为代理分配一个全局唯一的去中心化标识符（DID），锚定于一个公钥。这是代理的“名字”。
2. 完整性层（Integrity Layer）： 包含代理可执行代码的加密哈希值、其运行时环境（例如容器镜像哈希值）以及一份经签名的允许操作清单（作用域）。这是代理的“指纹”。
3. 授权层（Authorization Layer）： 一组经加密签名的凭证，授予代理特定权限（例如“可读取数据库A”、“可转账不超过1000美元”）。这些凭证与完整性层绑定，意味着只有当代理的代码哈希值与凭证中的哈希值匹配时，凭证才有效。
关键的技术突破在于将远程证明（Remote Attestation）与密钥证明（Key Attestation）相结合。当代理启动时，它必须向可信平台模块（TPM）或硬件安全模块（HSM）证明自己正在运行正确且未经修改的代码。随后，TPM会签署一份声明，将代理的公钥与该代码哈希值关联起来。这份经签名的声明就是代理的“出生证明”。任何与代理交互的系统都可以对照可信代理发布者的公共注册表来验证这份证明。
这一架构直接应对了多种攻击向量：
- 身份伪造（Identity Spoofing）： 攻击者无法声称自己是“代理A”，除非拥有对应的私钥，而该私钥是硬件绑定的。
- 代码篡改（Code Tampering）： 如果攻击者修改了代理的代码（例如窃取数据），代码哈希值会改变，从而使所有现有凭证失效。代理必须重新接受证明。
- 重放攻击（Replay Attacks）： 每次交互都包含一个随机数（nonce）和时间戳，并由代理的私钥签名，从而防止攻击者重用捕获的会话。
- 权限提升（Privilege Escalation）： 即使代理获得了系统访问权限，也无法执行其签名作用域之外的操作，因为目标系统可以通过密码学方式验证代理的权限。
相关开源项目：
社区已经在构建基础组件。由CNCF托管的SPIFFE（Secure Production Identity Framework for Everyone）项目为动态环境中的工作负载提供身份标准。其实现SPIRE是最成熟的用于工作负载证明的开源解决方案。虽然SPIFFE专注于集群内的服务间认证，但FIDO标准旨在将其扩展到开放互联网，实现跨组织的代理信任。另一个关键项目是Keylime，它提供可扩展的远程启动证明和运行时完整性监控系统。这些项目虽不直接属于FIDO标准，但展示了底层概念的技术可行性。
性能考量：
密码学证明并非没有代价。生成和验证证明语句的开销会影响延迟，尤其是在高频代理交互场景中。
| 操作 | 延迟（TPM 2.0，软件） | 延迟（HSM，硬件） |
|---|---|---|
| 密钥生成（ECDSA P-256） | 50-100 毫秒 | 5-10 毫秒 |
| 证明语句创建 | 200-500 毫秒 | 20-50 毫秒 |
| 证明验证 | 10-30 毫秒 | 1-5 毫秒 |
| 凭证签名 | 100-200 毫秒 | 10-20 毫秒 |
数据要点： 硬件支持的证明（HSM）相比基于软件的TPM提供了10倍到50倍的性能提升。对于延迟敏感的代理交互（例如高频交易机器人），硬件证明将是强制性的。FIDO标准很可能会强制要求支持硬件绑定的密钥，从而推动云服务提供商为AI代理提供HSM即服务。
关键参与者与案例研究
FIDO联盟是一个联合体，其标准由董事会成员共同制定。推动这项AI代理身份倡议的关键参与者，正是那些对安全机器间商业活动有既得利益的“老面孔”。
- Apple、Google、Microsoft： 这三家公司控制着主流的操作系统和浏览器生态系统。它们的兴趣在于为AI代理与用户设备及云服务的交互创建一种无缝且安全的方式。Apple的Secure Enclave和Google的Titan M芯片是代理证明的理想硬件信任根。Microsoft的Azure Attestation服务则是直接面向市场的商业产品。