简体中文
AI 代理身份验证：用例和身份需求
2025 是人工智能之年。随着大型语言模型（LLMs）和代理体验的发展，身份验证和授权方面出现了新的挑战。本文探讨了 AI 代理交互，突出了关键的安全性和身份验证场景。
Guamian
Product & Design
Product & Design
2025 是人工智能之年。随着大型语言模型（LLMs）和代理体验的发展，身份验证和授权方面出现了新的挑战。本文探讨了 AI 代理交互，突出了关键的安全性和身份验证场景。
2025 年塑造成为人工智能之年。随着大型语言模型和代理体验的快速增长，我们经常被问到：如何拥抱这个新时代？AI 代理身份验证和授权的新用例是什么？在本文中，我们将探讨典型的代理体验，并在此过程中指出安全性和身份验证场景。
我最近购买了 ChatGPT 操作员，并探索了一些常见的工作流程。其中一个例子是在日本东京预订住宿。操作员根据我的提示，使找到合适的房间变得极其容易。
结账时，它让我登录，然后将控制权交还给我。
这种体验让我感到不安。尽管我拥有控制权且代理无法为我登录，我仍然必须在操作员的浏览器中输入我的电子邮件和密码。这意味着，如果你通过操作员登录你的电子邮件（或任何服务），你的凭据将存储在 cookies 中。
OpenAI 的操作员声称它从不存储用户凭据，并遵循 SOC II 等合规标准。然而，当第三方代理代表你与外部服务交互时，安全风险显著增加。
一般来说，直接向代理提供你的账户访问权限和凭据是个坏主意。
还有很大的改进空间。在下一节中，我将深入不同的身份验证和凭据管理方法，权衡它们的优缺点。
正如 X Threads 所讨论的那样。
在这种方法中，AI 代表你输入明文凭据（如电子邮件和密码）。例如，一个 AI 代理可能会请求你的登录详细信息并为你输入它们。
然而，这种方法存在安全风险，因为它可能会暴露敏感信息。如果需要实现，集成密码管理器或秘密管理系统更为安全。此外，限制凭据的存储时间可以帮助尽量减少泄漏风险。
与明文凭据相比，个人访问令牌（PATs） 提供了一种更安全的方式，允许在不需要密码或交互式登录的情况下授权访问。PATs 对 CI/CD、脚本和需要以编程方式访问资源的自动化应用很有用。为了增强安全性，最好限制 PAT 范围、设置过期时间并允许撤销以防止泄漏和账户劫持。
OAuth（开放授权） 是一种广泛使用的网页委派授权标准。它允许用户向第三方应用授予其在其他服务上的数据的有限访问权限，而无需共享其登录凭据。
本质上，OAuth 解决了安全访问委托的问题：例如，你可以授权一个旅游应用读取你的 Google 日历，而无需向该应用提供你的 Google 密码。这是通过让用户在数据提供商处（如 Google）进行身份验证，然后向第三方应用颁发令牌来代替用户的凭据曝光来实现的。
处理此场景的更好方式是授权 ChatGPT 操作员（或任何其他代理）在 Airbnb 上读取和写入，而无需共享你的密码或凭据。与让操作员直接登录不同，你可以通过安全的授权流程授予访问权限。
在我看来，如果 OpenAI 操作员希望提高信任和身份安全性，有几种方法可以实现这一目标。
将登录过程移出操作员：在 ChatGPT 操作员之外处理用户登录。这意味着你可以点击“用[服务]登录”按钮并被重定向到该服务的安全登录页面进行身份验证，完全在聊天或 ChatGPT 操作员之外。例如，如果有一个 Airbnb 插件，你将被发送到 Airbnb 的网站输入你的凭据并授权 ChatGPT，然后插件将接收到一个令牌。ChatGPT 仅接收一个临时访问令牌或密钥，授予有限的访问权限（例如“读取我的行程”），而不会看到你的实际密码。
让用户在 AI 代理执行任何任务之前完成同意流程。这种方法类似于许多产品处理集成、市场和连接服务的方式。
Notion 连接页面
这是另一个例子，就像 Slack 的市场与 Notion 的集成一样。Slack 请求访问 Notion 的特定工作区，它可以读取文章并在你的 Slack 频道中展示它们。
同时，Slack 还提供了一个同意页面，以授权 Notion 在此过程中访问工作区。
ChatGPT 操作员应采用类似的方法，通过集成 OAuth，允许代理安全地访问多个第三方服务。这样，它可以获得访问令牌，并以必要的权限安全地执行任务。
AI 代理可以独立和自主地处理常规任务，但对于高风险操作，还需额外的验证以确保安全性，例如发送资金或修改安全设置，用户必须通过 多因素身份验证 (MFA) 验证其身份。这可以通过推送通知、一次性密码 (OTPs) 或生物特征验证来完成。
然而，频繁的逐步身份验证可能导致用户沮丧，特别是如果过于频繁触发。所以代理特定体验需要在这个新范式中考虑用户体验。
为了在不影响用户体验的情况下增强安全性，自适应身份验证和 MFA 应该用来确定何时需要额外验证。基于风险的触发器，如 IP 变化或异常行为，帮助尽量减少不必要的身份验证请求。
在多代理企业生态系统中，AI 代理经常需要在不同平台之间进行互动。为了简化身份验证，用户通过身份提供者（如 Okta、Azure AD 或 Google Workspace）进行一次认证。代理随后通过 SAML、OpenID Connect (OIDC) 验证身份，并通过基于角色（RBAC） 或 基于属性（ABAC） 的访问控制进行管理。
这种方法消除了用户需要多次登录的需要，同时通过集中身份管理提高了安全性和合规性。它还允许动态访问策略，确保代理在定义的权限范围内操作。
由于操作员和代理可以代表用户行动，因此为人们提供足够的控制并仔细定义 AI 代理的权限很重要。两个关键原则是：
基于角色的访问控制（RBAC）通过为特定任务分配特定角色来帮助管理代理的范围。对于更精细的控制，基于属性的访问控制（ABAC）可以实现动态、上下文感知的权限管理，确保 AI 代理仅在需要时访问所需内容。
MCP 已越来越受欢迎，因为它为 AI 代理提供了更丰富的上下文信息，改善了它们的整体性能和用户体验。
我们之前写过一篇文章帮助你了解什么是 MCP 服务器。
MCP 服务器是模型上下文协议的重要组成部分，作为 AI 模型和外部数据源之间的桥梁。它使得能够从 Slack、Gmail 和 Google 日历等服务进行实时查询和数据检索。通过构建 MCP 服务器，你可以将这些远程服务连接到大型语言模型中，从而提高 AI 驱动的应用程序的上下文信息并实现更智能的任务执行。
与要求生成嵌入并将文档存储在向量数据库的检索增强生成（RAG）系统不同，MCP 服务器无需事先索引即可直接访问数据。这意味着信息不仅更加准确和最新，而且在没有降低安全性情况下集成了较低的计算开销。
资料来源：https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained
对于使用 MCP 服务器的 AI 代理，MCP 服务器、大型语言模型、代理和用户之间会发生多次交互。
在今天的 AI 驱动世界中，代理跨不同服务管理多个任务，将它们与多个 MCP 服务器集成的需求越来越高。
一个很好的例子是 Composio.dev，这是一个面向开发者的集成平台，简化了 AI 代理和大型语言模型与外部应用和服务的连接方式。被称为“AI 代理代表用户行为的身份验证”，实际上它提供了一组可以轻松集成到 AI 驱动产品中的 MCP 服务器（连接器）。
作为身份验证领域的一员，但实际上，它只是更广泛的客户身份和访问管理（CIAM）领域的一小部分。他们构建的实际上是一组 MCP 服务器（连接器），这是非常有用的，但只是一整套 CIAM 解决方案的一部分。
基于前面提到的例子，如果我们将 Google Drive 视为 MCP 服务器而不是 Airbnb，它将不仅仅是第三方集成——它充当外部数据源。这使代理能够访问上下文信息，与大型语言模型交互，并可能获得创建、读取、更新和删除（CRUD）文件的权限。
但是，核心身份验证和授权要求保持不变。
Logto 是一个多功能的 CIAM 解决方案，支持 SaaS 和 AI 代理产品，使身份验证和授权无缝衔接。理由如下：
有问题吗？联系我们的团队，了解 Logto 如何增强你的 AI 代理体验并满足你的安全需求。