Manus 如何在云浏览器中处理登录状态和用户凭据

想象一下：你让 AI 代理为你预订机票、查收邮件或更新 CRM。为此，它需要访问你的线上账号。但它怎么能在不反复向你索要密码的情况下安全登录呢？

代理可以代表用户处理许多任务。要做到这一点，它们通常需要访问第三方服务，如网站、数据库或外部 API。虽然代理有时可以通过编程方式连接这些服务，但许多任务仍然需要传统登录方式和用户交互。

在上一篇文章中，我们已经讨论了涉及的安全风险，尤其是浏览器管理用户凭据时，可能引入的漏洞。https://blog.logto.io/agent-auth#chatgpt-operator-agent-auth-experience

虽然这个流程确实带来了安全顾虑，但我们也无法忽视它给终端用户带来的便利性。可用性和安全性的这种张力，使这个领域在技术上极具研究价值。

本文将探讨部分代理已经在如何解决**“基于浏览器的登录与身份验证”**问题上的实践。

我们会深入了解 Manus 怎样处理这个问题，还存在哪些安全隐患，以及在由代理驱动的环境下，未来的身份验证可能会走向何方。

Manus 的方法：“一次登录，保持在线”#

Manus 设计了一个名为 云浏览器（Cloud Browser） 的功能，它就像一台远程的、隔离的电脑，完全在云端运行。你可以把它想象成代理的专属网页浏览器，并且有一个关键特点：它能够记住你的登录状态，无论你切换多少设备和任务。

具体流程如下：

1. 你在云浏览器里手动登录一个网站。每个站点只需登录一次。
2. Manus 捕获你的会话数据： 包括 cookie、本地存储等能让你保持登录状态的信息。
3. 这些数据会被加密两次： 先在本地加密，再在云端加密。绝不会明文存储。
4. 当代理需要再次访问该网站时， Manus 会自动在一个新的隔离沙箱中注入会话。网站会认为你一直在线。
5. 你可以跨设备同步， 也能随时在设置中手动清除会话数据。

这就像给你的代理发了一张只在自己“上锁房间”内有效的安全门禁卡。

本地浏览器（如 Chrome）与基于代理的云浏览器#

你可能会问：“这不就跟用 Chrome 一样吗？为什么基于代理的云浏览器风险更高？”我们来拆解一下背后的原因。

• 为什么把凭据交给 Chrome 通常是安全的
• 为什么给代理驱动的云浏览器可能有风险
• 在每种场景下，谁是“第一方”，谁是“第三方”

核心区别：本地浏览器 vs. 代理云浏览器#

为什么给 Chrome 输账号密码更安全#

1. 你是操作员 Chrome 是第一方界面，你亲自掌控、亲眼所见，并且属于你的计算环境。你带着明确意图输入密码，浏览器提供可见、可审计的提示。

2. 紧密集成的安全性 Chrome 等浏览器通过操作系统的安全存储保存密码，解锁常需生物认证或设备登录。自动填充也只在预期范围（如相符域名）下生效。

3. 最小化委托 你不是“长期交付”密码给 Chrome，而是记忆你输入的信息，并征得你的明确同意。行动主体是你，而不是第三方。

为什么代理云浏览器具有风险#

1. 它们代表你操作，却不在你眼前 云浏览器通常以编程方式操控。当你交出凭据，它们会代你登录，但常常没有任何界面或反馈。这导致可见性和责任界限模糊。

2. 存储风险 如果你把凭据明文交给代理，可能被记录、缓存，甚至滞留于内存。若没有严格的访问控制，将成为隐患。

3. 信任边界不清晰 你可能信任代理服务商，但不像 Chrome，有操作系统或物理级别的保护。如果服务器被攻破或代理实现不佳，凭据可能泄露。

第一方 VS. 第三方#

让我们明确“第一方”和“第三方”的含义，以及为何 Chrome 属于第一方，而基于代理的云浏览器不是。

把密码输给 Chrome 很安心，因为你亲自在你掌控的程序，且有你的操作系统多重保护下输入。Google 也不会将密码存储在服务器上。

但正如 Manus 所解释的：

我们将你的登录信息保存为一组加密文件，并安全上传至我们的存储服务器。这些信息包括：

• Cookie
• 本地存储

这意味着你的登录信息会存在 Manus 的后端服务器。用户必须信任代理开发团队，这与标准安全最佳实践并不完全一致。

把凭据交给由代理控制的云浏览器，本质上属于委托（delegation）。即使你亲自操作该浏览器，对于你要登录的服务来说，它仍然是第三方。你在依赖别人的基础设施、安全措施和职业操守，这引入了信任与安全风险。

在这种情况下，安全最好通过编程规范协议来保证，而不仅仅是品牌或公司承诺的信任。

Manus 做对了什么（什么还可能出错）#

可取之处：#

• 真正丝滑的会话体验：不必每次都重新登录，换设备也不用。
• 以用户为中心的安全性：所有数据全程加密，你能完全掌控存储内容。
• 公开透明且尊重隐私：Manus 不会用你的登录数据做训练或分析。

仍需注意的问题：#

• 重放攻击：若有人窃取你的会话文件，就能冒充你。
• 指纹识别冲突：有些网站用高级指纹技术把登录关联到特定设备，容易导致隔离沙箱内重放失败。
• 无法绕过验证码（CAPTCHA）：对那些启用强安全机制（如验证码）的第三方网站，云浏览器的操作容易被识别为机器人，验证码验证会失败。
• 数据合规问题：会话若跨境/跨设备同步，可能涉及隐私或合规风险。
• 对系统的信任：保护你数据的加密密钥，必须足够安全、严格把控。

代理登录的其他方式#

Manus 提供了一种聪明的解决方案，但这并非唯一选项。让我们看看代理为用户登录还常用的其他方法：

输入凭据#

最直接的方法就是代理像人一样“帮你输入”用户名和密码。实现简单，但如果凭据泄漏，任何人都能进入你的账户，极其不安全。因此，大多数开发者会极力回避这种方式。

如果必须采用这一方法，通常会结合 凭据保险库 或 密钥管理器 等工具，来更安全地处理 cookie 或凭据，实现额外保护。

OAuth 令牌#

这是授权访问的金标准。你通过 OAuth 流程授权代理，代理获得有限且可撤销的令牌。安全、细粒度、易于撤销，但只有被授权网站支持 OAuth 时才行。

其他编程方式（如 API Key）#

有些服务支持为编程用途分发 API key 或其他访问密钥。这比输密码安全，但通常权限较大且密钥管理要求高。

每种方式都在可用性与安全性间权衡。Manus 的会话重放法大致属于中间地带，比 OAuth 灵活，但安全性略逊一筹。

理想状态下，在这种基于浏览器的方案中，Manus 能与特定网站预集成（如一份受支持站点清单）。用户预先同意授权，代理便可安全用 OAuth 令牌操作，无需存储凭据或重放会话。

未来趋势：代理成为受信任的“专业代理人”#

代理能力越来越强，就需要比“冒充人操作”更高级的认证方式。

我们正朝着以下方向发展：

• API 优先：不再点按钮，代理用令牌调用 API。
• 短时、严格的访问权限：杜绝“全权神令牌”，只访问所需资源，权限生效时间极短。
• 硬件级别的安全方案：会话数据存于安全隔离区（enclave），而不仅是软件保险库。
• 用户自有的凭据保险库：你会管理安全的令牌、密钥和会话“钱包”，只对信任的代理开放共享。

简言之：代理会从“帮手机器人”进阶为“经授权的操作员”，他们也得配备合适的凭证。

什么是 Vault，为何如此重要？#

如果你觉得这一切很难管理……我认为，随着基于浏览器的自动化日益普及，必须配合一套专业的配套工具来安全透明地处理凭据与会话。

所以，诸如 Vault 或 密钥（Encryption Key）管理系统（EKM） 就显得极其重要。

Vault 是一种 机密信息管理（secrets management）解决方案，能让团队：

• 安全地存储令牌、API key 和凭据
• 按需动态颁发短时凭据
• 控制谁能访问什么，并全程审计日志
• 自动轮换密钥，瞬时吊销权限
• 与 CI/CD 流水线及云应用集成

在“代理驱动”的世界里，Vault 成为凭据安全的“大脑”。你的代理从 Vault 申请访问授权，从不自己存储明文密码。即使出了问题，令牌很快失效，而你真正的密钥依然安全无虞。

总结#

Manus 在代理登录上开创了一种易用、周到的实践：跨设备的安全会话重放，由用户全程掌控。这是大踏步的进步，也提醒我们登录流程本身很脆弱。要格外关注重放攻击、沙箱兼容性，以及密钥管理等细节。

未来趋势已明：代理会为我们办理更多事务，但也必须安全掌管所需凭据。Vault 等工具将变得举足轻重，不仅用于管理密码，更是实现信任的保障。

当你的 AI 拥有你数字世界的钥匙时，你必须明白：这些钥匙是怎么发放的，能用多久，究竟能打开哪扇门。

Logto 正在推出 Vault 来安全存储第三方 API 令牌， 支持代理安全访问外部服务，比如 Google 这类社交账户或远程 MCP 服务器。未来我们计划支持存储更多种类的敏感数据，包括用户凭据、密钥及其他机密内容。

与此同时，Logto 也是一套完整的 身份认证、授权与身份管理平台。如果你在从零开发 AI 代理，Logto 专为 AI 开发者而生， 提供在代理驱动环境下所需的安全性、灵活性与基础设施能力来管理身份。