让智能体接管Chrome？企业别把家底全交出去

开源项目 Browser Use 作者近期梳理了让智能体接管Chrome的六种方案，对比了 Claude Code、Codex、Gemini CLI 等工具接入日常已登录浏览器的路径。很多开发者看到的第一反应是太方便了：自动化脚本再也不用卡在二次验证、短信验证码和设备绑定上，智能体提笔就能抓数据、点后台、调接口。

但我必须给各位提个醒：智能体接管Chrome的背后，藏着企业权限管理的巨大隐患。

一家做精密仪器出口的企业，其跨境市场负责人为了让编程智能体批量下载后台竞品数据，直接把日常办公使用的 Chrome 挂载给终端智能体。结果智能体在解析第三方公开页面时遭遇 Prompt 注入提示词，直接在后台发起了一次未授权的导出操作。日常浏览器里躺着企业的 Google Workspace、飞书企业版、AWS 控制台以及各类社媒后台的持久登录态，你图省事全盘交出去，无异于让一个实习生带着公司的全套公章到处跑。

为什么编程智能体自动化总想用你的 Chrome？

做过浏览器自动化的人都知道，以前靠复制 Cookie 就能在无头浏览器里跑任务。但从安全机制来看，这套逻辑正在快速失效。

首先是设备绑定凭证（Device Bound Session Credentials）。现在的 Chrome 会把会话私钥锁在可信平台模块（TPM）等安全硬件里。短生命周期的 Cookie 一旦过期，浏览器必须出示硬件层面的私钥才能完成刷新。你直接导出 Cookie 换一台设备或者起一个干净的自动化环境，往往立刻失效，要求重新走多因素认证。

其次是老旧调试通道被封堵。在 Chrome 136 之后，Google 强制关闭了默认数据目录下的远程调试参数（--remote-debugging-port 和 --remote-debugging-pipe），就是为了防止攻击者直接从运行中的 Chrome 偷取登录凭据。

这导致市面上的主流做法走向了极端：既然隔离环境不好登，那就索性让智能体连进你当前正在使用的 Chrome 里。

智能体接管Chrome的六种方案：Browser Use 权限到底有多大？

资讯原文拆解了当前主流工具对接已登录浏览器的六种路径。每种方案拿到的 Browser Use 权限 和作用域完全不同：

1. Claude in Chrome 扩展：Anthropic 官方方案。面向付费订阅（Pro、Max、Team、Enterprise）用户，通过 claude --chrome 连接。它在独立标签页组里工作，遇到登录页和验证码会自动停下来交给人，相对可控。
2. Playwright MCP（扩展模式）：通过安装 Playwright Extension 连接正在运行的 Chrome 或 Edge。它的特点是由人明确挑选指定标签页分给智能体，其他标签页对它不可见。
3. Chrome DevTools MCP（自动连接模式）：在 Chrome 144 及以上版本中，开启远程调试后通过 --autoConnect 接入。一旦连接，它能看到该配置文件下打开的所有窗口。
4. Gemini CLI 内置浏览器智能体：默认是隔离配置文件，只有将 sessionMode 设为 existing 时才会接管当前 Chrome。内置了域名白名单（allowedDomains）和单次任务最多 100 次动作的限制。
5. Codex（桌面客户端扩展）：OpenAI 的桌面端通过浏览器扩展接入，默认在每个新站点执行前都需要人工批准，全站放通会被标记为高风险。
6. Browser Harness：通过 Chrome DevTools Protocol 直连当前运行的浏览器。智能体在后台静默操作，但它看到的是整个浏览器的所有窗口和标签页，默认还会收集使用情况统计。

企业技术与市场负责人在做选型时，不能只看哪个装起来最快，更要看它的权限边界停在哪：

做好智能体 Session 隔离：安全自查清单与三原则

智能体 Session 隔离 不是给技术人员添麻烦，而是防止不可控指令穿透的底线。企业在使用编程智能体做浏览器自动化时，需要落实以下三项原则：

第一，独立配置文件原则。严禁将员工日常办公的默认 Chrome Profile 挂载给自动化智能体。即使必须共用浏览器，也必须在 Chrome 中新建一个专用的自动化 Profile，只在其中登录该项自动化任务所需的系统，杜绝企业内部 SSO 单点登录态混用。

第二，最小标签页暴露原则。优先选用 Playwright MCP 扩展模式这类「按需授权特定标签页」的工具，杜绝使用一键扫描全窗口的后台常驻方案。

第三，域名白名单与阻断原则。对于涉及后台增删改、敏感数据拉取的流程，必须配置明确的域名限制和表单提交二次拦截，不能给智能体开放全网跳转权限。

读者可以直接对照这份清单，排查团队内的配置：

• [ ] 是否严禁在挂载了企业主邮箱、主通讯录的浏览器配置文件上直接运行调试连接？
• [ ] 智能体运行环境是否开启了域名白名单，限制其只能在预设业务站内跳转？
• [ ] 针对表单提交、导出按钮、支付确认等高危动作，是否强制保留了人工弹窗确认？
• [ ] 连接协议是否默认关闭了向第三方服务器上报使用遥测（Telemetry）数据的开关？
• [ ] 员工使用的接管插件是否来自官方受信任渠道，并且定期清理废弃的连接 Token？

从星盒的实践看

很多团队之所以冒着风险去接管日常浏览器，根源在于外部采集和内容发布的链路太碎。很多市场负责人跟我说，不用已登录浏览器，人工去处理扫码、换号、重新登录，一天的大半时间就耗进去了。

从星盒服务 500+ 家企业的实践来看，内容与数据自动化并不需要靠牺牲安全来换取。星盒的新媒体内容工厂系统，是基于企业专属知识库和多维度写稿智能体稳定产出内容，把单条内容创作时间从 2–4 小时缩短到 5–10 分钟。如果企业需要全员协同，通过「星盒星盒！」企业全能 AI 营销智能体，员工直接在微信里私聊就能调用全公司共享的知识库与能力，管理层在驾驶舱看全局数据，根本不需要员工私自开放本地浏览器的高危权限。

自动化越往下走，拼的越不是谁能绕过安全验证，而是谁能在安全边界内把标准流程沉淀成系统。

把日常使用的浏览器交给智能体，就像把开着门的自家保险库借给跑腿小哥。你以为只是让他帮忙取一盒印泥，但他一旦走错房间、碰倒架子，代价只能由你全额买单。给智能体一套限定范围的工卡，永远比把自己的工牌直接借给它更明智。