简体中文
Manus 如何在云浏览器中处理登录状态和用户凭据
本文介绍了 Manus 如何在其云浏览器中管理登录会话，基于代理的身份验证的安全风险，以及诸如 OAuth 和凭据保险库等替代方案。
Guamian
Product & Design
Product & Design
本文介绍了 Manus 如何在其云浏览器中管理登录会话，基于代理的身份验证的安全风险，以及诸如 OAuth 和凭据保险库等替代方案。
想象一下：你让 AI 代理为你预订机票、查收邮件或更新 CRM。为此，它需要访问你的线上账号。但它怎么能在不反复向你索要密码的情况下安全登录呢？
代理可以代表用户处理许多任务。要做到这一点，它们通常需要访问第三方服务，如网站、数据库或外部 API。虽然代理有时可以通过编程方式连接这些服务，但许多任务仍然需要传统登录方式和用户交互。
在上一篇文章中，我们已经讨论了涉及的安全风险，尤其是浏览器管理用户凭据时，可能引入的漏洞。https://blog.logto.io/agent-auth#chatgpt-operator-agent-auth-experience
虽然这个流程确实带来了安全顾虑，但我们也无法忽视它给终端用户带来的便利性。可用性和安全性的这种张力，使这个领域在技术上极具研究价值。
本文将探讨部分代理已经在如何解决**“基于浏览器的登录与身份验证”**问题上的实践。
我们会深入了解 Manus 怎样处理这个问题，还存在哪些安全隐患，以及在由代理驱动的环境下，未来的身份验证可能会走向何方。
Manus 设计了一个名为 云浏览器（Cloud Browser） 的功能，它就像一台远程的、隔离的电脑，完全在云端运行。你可以把它想象成代理的专属网页浏览器，并且有一个关键特点：它能够记住你的登录状态，无论你切换多少设备和任务。
具体流程如下：
这就像给你的代理发了一张只在自己“上锁房间”内有效的安全门禁卡。
你可能会问：“这不就跟用 Chrome 一样吗？为什么基于代理的云浏览器风险更高？”我们来拆解一下背后的原因。
| 方面 | 本地浏览器（比如 Chrome） | 典型代理云浏览器 |
|---|---|---|
| 位置 | 运行在你个人设备上 | 远程运行在云端 |
| 控制权 | 完全由你掌控 | 由代码或 AI 代理控制 |
| 界面反馈 | 你直接交互（可见表单、自动填充提示） | 有界面且可让用户操作，但大部分交互仍由代理以编程方式静默处理 |
| 存储 | 凭据通过操作系统加密（如 macOS 钥匙串）安全存储 | 凭据或 cookie 可能保存在内存或日志中，暴露风险增加 |
| 安全边界 | 受操作系统 + 浏览器沙箱保护 | 需要专门的隔离措施，若代理失控或数据泄露则有漏洞 |
| 信任模型 | 你信任 Chrome，因为它与你同在，专为人工操作设计 | 你信任 代理开发者，但他们是否足够重视安全无法保证 |
你是操作员 Chrome 是第一方界面，你亲自掌控、亲眼所见，并且属于你的计算环境。你带着明确意图输入密码，浏览器提供可见、可审计的提示。
紧密集成的安全性 Chrome 等浏览器通过操作系统的安全存储保存密码，解锁常需生物认证或设备登录。自动填充也只在预期范围（如相符域名）下生效。
最小化委托 你不是“长期交付”密码给 Chrome，而是记忆你输入的信息，并征得你的明确同意。行动主体是你，而不是第三方。
它们代表你操作，却不在你眼前 云浏览器通常以编程方式操控。当你交出凭据，它们会代你登录，但常常没有任何界面或反馈。这导致可见性和责任界限模糊。
存储风险 如果你把凭据明文交给代理，可能被记录、缓存，甚至滞留于内存。若没有严格的访问控制，将成为隐患。
信任边界不清晰 你可能信任代理服务商，但不像 Chrome，有操作系统或物理级别的保护。如果服务器被攻破或代理实现不佳，凭据可能泄露。
让我们明确“第一方”和“第三方”的含义，以及为何 Chrome 属于第一方，而基于代理的云浏览器不是。
| 角色 | Chrome | 代理云浏览器 |
|---|---|---|
| 你（用户） | 第一方操作员 | 凭据所有者 |
| 浏览器/应用 | 第一方界面（你直接交互） | 第三方代理代表你操作 |
| 凭据处理方 | 操作系统 + Chrome（本地强信任链） | 外部代理服务（信任边界松散） |
| 存储 | 本地操作系统保护 | 远程云端服务器或后端基础设施存储 |
把密码输给 Chrome 很安心，因为你亲自在你掌控的程序，且有你的操作系统多重保护下输入。Google 也不会将密码存储在服务器上。
但正如 Manus 所解释的：
我们将你的登录信息保存为一组加密文件，并安全上传至我们的存储服务器。这些信息包括：
这意味着你的登录信息会存在 Manus 的后端服务器。用户必须信任代理开发团队，这与标准安全最佳实践并不完全一致。
把凭据交给由代理控制的云浏览器，本质上属于委托（delegation）。即使你亲自操作该浏览器，对于你要登录的服务来说，它仍然是第三方。你在依赖别人的基础设施、安全措施和职业操守，这引入了信任与安全风险。
在这种情况下，安全最好通过编程规范协议来保证，而不仅仅是品牌或公司承诺的信任。
Manus 提供了一种聪明的解决方案，但这并非唯一选项。让我们看看代理为用户登录还常用的其他方法：
最直接的方法就是代理像人一样“帮你输入”用户名和密码。实现简单，但如果凭据泄漏，任何人都能进入你的账户，极其不安全。因此，大多数开发者会极力回避这种方式。
如果必须采用这一方法，通常会结合 凭据保险库 或 密钥管理器 等工具，来更安全地处理 cookie 或凭据，实现额外保护。
这是授权访问的金标准。你通过 OAuth 流程授权代理，代理获得有限且可撤销的令牌。安全、细粒度、易于撤销，但只有被授权网站支持 OAuth 时才行。
有些服务支持为编程用途分发 API key 或其他访问密钥。这比输密码安全，但通常权限较大且密钥管理要求高。
每种方式都在可用性与安全性间权衡。Manus 的会话重放法大致属于中间地带，比 OAuth 灵活，但安全性略逊一筹。
理想状态下，在这种基于浏览器的方案中，Manus 能与特定网站预集成（如一份受支持站点清单）。用户预先同意授权，代理便可安全用 OAuth 令牌操作，无需存储凭据或重放会话。
代理能力越来越强，就需要比“冒充人操作”更高级的认证方式。
我们正朝着以下方向发展：
简言之：代理会从“帮手机器人”进阶为“经授权的操作员”，他们也得配备合适的凭证。
如果你觉得这一切很难管理……我认为，随着基于浏览器的自动化日益普及，必须配合一套专业的配套工具来安全透明地处理凭据与会话。
所以，诸如 Vault 或 密钥（Encryption Key）管理系统（EKM） 就显得极其重要。
Vault 是一种 机密信息管理（secrets management）解决方案，能让团队：
在“代理驱动”的世界里，Vault 成为凭据安全的“大脑”。你的代理从 Vault 申请访问授权，从不自己存储明文密码。即使出了问题，令牌很快失效，而你真正的密钥依然安全无虞。
Manus 在代理登录上开创了一种易用、周到的实践：跨设备的安全会话重放，由用户全程掌控。这是大踏步的进步，也提醒我们登录流程本身很脆弱。要格外关注重放攻击、沙箱兼容性，以及密钥管理等细节。
未来趋势已明：代理会为我们办理更多事务，但也必须安全掌管所需凭据。Vault 等工具将变得举足轻重，不仅用于管理密码，更是实现信任的保障。
当你的 AI 拥有你数字世界的钥匙时，你必须明白：这些钥匙是怎么发放的，能用多久，究竟能打开哪扇门。
Logto 正在推出 Vault 来安全存储第三方 API 令牌， 支持代理安全访问外部服务，比如 Google 这类社交账户或远程 MCP 服务器。未来我们计划支持存储更多种类的敏感数据，包括用户凭据、密钥及其他机密内容。
与此同时，Logto 也是一套完整的 身份认证、授权与身份管理平台。如果你在从零开发 AI 代理，Logto 专为 AI 开发者而生， 提供在代理驱动环境下所需的安全性、灵活性与基础设施能力来管理身份。