浏览器智能体继承用户权限的隐患

能替用户点按钮、填表单的 AI 助手，也可能直接继承用户的全部操作权限。Token 开发的 Rehearsal 就遇到了这个问题：它在用户已登录的浏览器会话里行动，服务器无法区分一次点击来自真人还是助手。

原文的核心提醒是：助手能执行什么，不能只由用户账号的权限决定。Token 同时掌握应用和助手，因而能补上访问限制、敏感操作审批与会话记录；接入其他网站的通用助手，却未必具备这些条件。

登录的是用户，执行的却可能是助手

Rehearsal 最初用于回答 Token 平台内的问题，但它不只提供文字说明，还会打开浏览器标签页、设置筛选条件、填写表单。

关键在于，它运行在用户现有的浏览器会话中。用户能访问的数据、能使用的功能，助手也拥有相同的权限。对于接收请求的系统，一次操作沿用了有效的登录身份，就很难仅凭这个身份判断操作者是谁。

账号有权执行，不等于助手获得了执行授权。

标题中的「违反安全规则」，容易让人想到漏洞利用。但原文描述的主要问题，是助手默认继承了人的权限，服务端又无法区分两者。它没有给出具体攻击过程，也没有说明究竟违反了哪些既有规则。因此，更准确的理解是：产品原先的权限边界没有充分考虑代理操作。

Token 补上的限制，分别解决什么问题

Token 同时控制 Rehearsal 和被操作的应用，可以在产品内部加入约束。原文列出了几类措施：

• 助手活动时调暗应用界面，让用户知道当前由助手操作。
• 记录每次会话中的操作过程，方便事后追溯。
• 限制助手只能查看指定信息，未经用户批准不能保存数据。
• 禁止填写隐藏或敏感表单，阻止未经授权的请求。

这些措施作用不同。界面提示解决「现在是谁在操作」，会话记录解决「刚才发生了什么」，访问和请求限制才直接约束「允许做什么」。

其中的只读限制尤其值得借鉴：查看信息与修改状态应当分开授权。不过，原文没有交代这些限制落在助手内部、浏览器端还是服务端，也没有描述审批如何与具体操作绑定。它提供了治理方向，还不足以作为可直接复用的实现方案。

原文还称，Chrome 和 Edge 正在引入自动浏览的同意要求、按站点设置等功能，也有标准尝试帮助应用和服务器识别自动助手访问。但文中没有提供版本号、功能名称或标准名称，无法据此判断这些能力的可用范围。

我的判断

我认同它最重要的判断：助手的操作权限需要单独设计。 一个账号可以管理数据，并不能自动推导出它安装的每个助手都能代为修改数据。

但 Token 的做法有明显前提：他们同时控制应用和助手。通用浏览器助手跨网站工作时，未必能要求目标网站配合增加审批入口、限制可见字段或识别代理身份。

与直接继承浏览器会话相比，通过专门接口为助手授予有限权限，是另一种值得比较的设计思路。不过，原文没有提供两种方案在开发成本、任务成功率或安全性上的对照数据，不能据此宣布哪种方案全面胜出。

会话录像也不能替代权限校验。它有助于追溯，却不会自动阻止一次错误提交。原文同样没说明录像包含哪些信息、保存多久、谁能查看，这些都是采用类似方案前需要补齐的问题。

这是一则有价值的产品安全案例，但不是经过量化验证的最佳实践报告。

能拿来做什么

• 给现有管理后台接入 AI 操作时，先列出查询、筛选、保存、提交等动作，再为助手单独划定可执行范围，避免把登录用户的全部权限直接交过去。
• 在前端明确展示助手正在操作的状态，并为敏感提交设置针对当前动作的明确确认。界面提示负责让用户知情，后端仍需校验请求是否获得授权。
• 引入浏览器 AI 扩展或自动操作工具时，记录使用者、关联身份与操作过程。原文没有给出 Chrome、Edge 的具体功能版本，落地时应先核实实际支持情况。