智能体的身份、授权、加密

智能体的身份、授权、加密通信是智能体安全的核心，也是两个智能体能够进行高效、安全协作的基础。

今天尝试完整的阐述下我对这三个问题的理解。

智能体身份

智能体身份的说明

第一个问题，我们在讨论智能体身份的时候，到底在谈论谁的身份？智能体有身份吗？

我认为在一般的交互场景中，智能体作为一个软件，其本身是没有身份的。它只是被人授权，使用人的身份，帮助人完成一些任务。

所以，我们在讨论的智能体身份的问题，本质上是，如何让智能体能够安全、高效的代表人来和其他智能体进行交互，帮助人完成任务。

智能体身份的两种模式

身份个人所有；
身份属于平台；

智能体身份相对于传统的身份方案，最急迫的是什么

我们现在已经有很多身份的方案，比如OIDC、DID、SAML，到底哪个方案更适合智能体？

这需要回答一个问题，对于智能体的身份认证来说，什么是最重要、最急迫的？

我认为是身份的互操作性（Identity Interoperability）。

身份的互操作性是指：一个平台的身份能够被另一个平台识别和信任，从而实现跨平台的互相认证与使用。这与email非常像：你有一个email邮箱账户，就可以和全网所有的email用户进行通信。

互操作性为什么对智能体非常重要？

因为我认为现有的互联网就是一个个孤岛，每个平台都有自己的身份体系，自己的用户，自己的数据。这极大的阻碍智能体获得完整的上下文，也阻碍智能体帮助人们执行任务，让我们无法获得一个聪明、理解你，同时帮助你做很多事情的智能体。

所以，我们认为，只有一个所有智能体互联互通、开放的互联网，才能够更大程度的释放AI的能力，让我们构建出强大的智能体网络。

而互联互通的第一步，特别是不同平台智能体互联互通的第一步，就是他们相互之间能够进行跨平台的身份认证。

最适合智能体的身份方案

在目前我们已知的所有方案中，DID的互操作性是最好的。所以，我一直认为，DID是最适合智能体身份认证的方案。当然，DID并不是没有问题，比如应用范围不够广泛，缺少标准的授权方案，等等。

幸运的是，智能体大部分都是新构建的软件，我们完全可以采用新的方案。W3C的ZCAP-LD项目虽然没有成为推荐标准，但是它提供了一种使用DID进行细粒度授权的方案，值得我们关注。

不过，其他的方案也在考虑如何提升身份验证的互操作性，未来也许会有更多的选择。

智能体授权

智能体授权和智能体身份是相关而又不同的问题，相关是因为授权往往依赖身份认证，不同是因为他们解决了不同的问题，一个是你是谁的问题，一个是你能干什么的问题。

让我们先来看看未来可能有哪几种授权模式：

• 智能体读取原有互联网应用的数据
• 不同的智能体拥有用户不同的数据，用户可以跨智能体授权数据访问
• 用户数据统一存储，授权不同智能体访问不同的数据
• 用户授权智能体代表自己与其他用户/企业的智能体进行交互

智能体读取原有互联网应用的数据

智能体读取原有互联网应用的数据，是智能体获得完整上下文的重要方式。比如，我通过我的智能体，访问谷歌问题、github的代码。这个时候，我的智能体需要获得谷歌或github的授权。这个流程一般使用OAuth，这也是目前互联网中使用最广泛的一个技术。

跨智能体授权数据访问

未来一个实体（人或组织）可能拥有多个智能体，用户在每个智能体拥有独立的身份ID，并且每个智能体都维护用户不同的数据。为了让一个智能体获得用户更加完整的上下文，用户可以授权此智能体访问用户在其他智能体上的数据。

如图所示，跨智能体的数据访问分为两个步骤：

• 用户在智能体B中，授权智能体C访问B的部分数据权限。比如，可以通过用户对其在智能体C的身份ID授权来实现。
• 智能体C使用用户的授权，访问智能体B中的用户数据，智能体B验证通过后返回数据。

统一数据存储的授权

这是我最喜欢的一种模式：未来人的数据可以统一、安全的存储在一个地方，人拥有对数据的绝对主权。智能体不拥有数据的权限，而是被用户授权访问（读或写）用户的部分数据。用户可以随时撤销智能体对数据的访问，这样用户可以随意的选择他使用的智能体。

在这种模式下，用户在智能体A、B、C中拥有独立的身份ID，但是用户数据统一存储在数据中心。用户可以授权智能体A、B、C访问数据中心中的部分数据。

这种模式也许可以更进一步，用户也拥有一个或多个自己绝对控制的账号，然后授权智能体使用这个账号访问用户在数据中心的数据。

跨智能体交互的授权

这种模式描述的是，用户授权智能体代表自己与其他用户/企业的智能体进行交互。

比如，Alice要让Alice的智能体帮她预订一个酒店，Alice的智能体就需要使用Alice的身份ID，代表Alice去访问酒店的智能体，并使用Alice的身份ID预订酒店。

这里面涉及两类不同的授权：

• 一类普通的授权，即Alice授权智能体使用她的身份ID，代表她去访问酒店的智能体一般信息，比如房间、价格等。这类信息的访问不需要Alice每次都进行手动授权，授权一次即可。否则交互过程太繁琐。
• 一类是特殊授权，即Alice授权智能体使用她的身份ID，代表她去做一些重要的操作，比如预订酒店、支付订单。这类授权非常重要，需要Alice每次都进行手动授权。否则会有安全风险。

智能体授权的方案

如果要和原有的系统互通，那就使用原有系统支持的授权方案就可以，比如原有的系统只支持OAuth，那就使用OAuth。

不过，对于新构建的智能体，我们应该探索更合适智能体的授权方案。

在上面我们介绍智能体身份的部分说过，我认为DID是最适合智能体的身份方案，不过基于DID的授权方案还不是很完善。首先，和W3C DID配套的W3C VC（可验证凭证）可以用于一部分授权的场景，特别是表达属性、权限或资格，比如"某用户是某组织的员工"，"某用户已经成年"等。

VC的方案在表达类似"30分钟内读取某一个资源权限"时有些复杂，其签发、验证、撤销的成本可能会比较高。W3C ZCAP-LD在解决这个问题上是一个比较有意思的技术，不过目前还是社区草案的状态。

IETF的GNAP (Grant Negotiation and Authorization Protocol)由 IETF GNAP 工作组提出，目标是成为 OAuth 2.0 的继任者，解决了 OAuth 2.0 在灵活性、安全性和扩展性上的不足，使授权协议能适配 AI Agent、IoT、去中心化身份等新兴场景。

GNAP也支持DID，是一个可以关注的方案。

端到端加密

如果两个智能体之间进行消息通信，而他们又使用了一个第三方的服务做消息中转，那这个通信很可能是不安全的，消息可能会被第三方截获甚至解密。

这个时候就需要一个端到端加密的技术，以让第三方服务可以方便的中转消息，但是无法解密其内容。

如果这两个智能体是直接通信的，比如，两个智能体，他们分别属于两个不同的平台，平台为他们申请了一个公网的端点，这个时候他们能够直接连接，使用传统的HTTPS或者WSS即可保证消息的安全性，无需使用端到端加密。