九月十六日的两件事
同一天里出现了两条方向相反的新闻。
一条是 Mozilla 与 Mistral 宣布合作：Firefox 的 AI 浏览助手 Smart Window 测试版改由 Mistral 的模型驱动，选中的是 Mistral Small 4，官方给出的选型依据是评测中的多语言表现。首批覆盖美国、加拿大与法国，英国与德国预计年内跟进。
另一条是研究者公布了一个叫 BragJack 的漏洞类别：一个恶意浏览器扩展可以越过「不可信扩展」与「高权限智能体」之间的边界，在特权上下文里执行代码，从而拿到读取本地文件、浏览历史、截图以及调用摄像头与麦克风的能力。五款主流浏览器受影响，两家厂商为此发布了 CVE，相关厂商均已修复并发放赏金。
一条在把 AI 装进浏览器，一条在说明装进去之后会发生什么。把它们放在一起看，浏览器智能体的竞争焦点已经很清楚了：不是谁更聪明，而是把信任放在哪一层。
Smart Window 把默认答案押在「不存」上
先说合作本身的设计取舍。
公开承诺集中在数据这一侧：对话默认不保存在 Mozilla 的服务器上，合作方 Mistral 承诺零数据保留，两家都表示不出售个人数据、不用对话训练模型。
这个组合在浏览器的语境里是有针对性的。浏览器助手天然会接触到用户最私密的上下文——正在写的邮件、正在填的表单、正在比价的页面、点开又放弃的搜索路径。功能描述里的三条能力（理清复杂搜索链路、找回点开又离开的内容、按打开的标签页组织信息）恰好都建立在这类上下文之上。越是有用的能力，对数据的依赖越深，所以「不存」这个默认值才成了一个有意义的产品决策。
另一层是模型来源。Mozilla 的公开表述里，这次合作被放在「开放生态对默认管道」这个框架下讲——浏览器不该成为通向单一厂商的单向漏斗，用户应当能在多家模型之间切换。对 Mistral 来说，这条路让它在不拥有浏览器的情况下触达到消费者；对 Mozilla 来说，它拿到了一个不属于大厂默认管道的模型来源。这是两家各自的需要接在一起，而不是一方对另一方的让步。
选型过程也值得一提。Mozilla 表示，在评估 Smart Window 测试版表现时把多语言能力作为重要一项，最终选中 Mistral Small 4；两家把多语言与多文化调校当作模型的核心特性来做，而不是把英语优先的体验搬到新市场。法国是新增市场里提供官方法语支持的一个。
需要打折扣来读的一处
这条合作里最需要标注来源的一句话是「隐私是架构，还是承诺」。
第三方观察指出：这是一个「伙伴承诺」模型，而不是端上推理。数据不出本机这件事并没有发生在技术层面——它发生在合同与流程层面。这不削弱承诺的价值，但决定了由谁来核对它：如果信任依赖的是厂商如何处理数据，那么核对方式就只能是审计、合规材料与采购条款，而不是浏览器里的一个开关。
把它放进采购场景里，推论很直接：零数据保留是合同条款，需要写进文件，并且需要保留复核权。写进合同与写进宣传材料，是两件事。
BragJack 指出的那个边界
再看另一条新闻。BragJack 的技术细节是这样的：恶意扩展滥用 Chromium 的 declarativeNetRequest 接口，削弱页面加载时的安全响应头，并把 JavaScript 资源重定向到攻击者控制的地址，从而在特权上下文里执行代码。
研究者强调的一点是：这次攻击不需要绕过模型护栏，也不需要提示词注入。他们不需要巧妙地把指令藏在智能体要读的内容里碰运气——他们可以直接一条接一条地发指令，直到智能体被说服去做任何事。
这处表述值得停一下。过去两年关于智能体安全的主流叙事是「注入」：攻击者把指令藏在网页、文档或工具返回里，等模型读到。BragJack 展示的是另一种结构——攻击者不需要骗过模型，它要骗的是应用。扩展与特权上下文之间的边界没有被守住，那么扩展说的话就被当成了合法指令，模型只是照做。
研究者还指出，五款浏览器各有各的漏洞，但都允许扩展越过同一条不该被越过的边界。按他的估计，受影响人群是那些在五款浏览器上安装了至少一个扩展的使用者，量级在数亿。
这件事与 Smart Window 的合作没有直接关系，但它给出了同一个问题的另一面：浏览器里已经有了用户登录过的一切，而一个能读页面、能点击、能提交的智能体，等于一个持有用户全部授权的自动化面。当欺骗发生在智能体身上而不是用户身上时，用户不会察觉。
三条路线，三种信任模型
把近期的几个动作并排放在一起，浏览器智能体大致分成了三条路线。
浏览器内置智能体：体验最顺，不需要额外安装，权限来自浏览器自身。风险集中在内部分层上——BragJack 落在的就是扩展与特权上下文之间的那条边界。
空白沙箱实例：给智能体一个干净的浏览器，隔离做得彻底。代价是丢掉真实登录态，也随之丢掉真实上下文。
外部桥接：把智能体接到用户已经登录的浏览器上，但通过独立的本机进程与扩展中转，权限开关放在浏览器设置里而不是命令行参数里，每次调用留痕可查，任务在独立可见的窗口里运行。腾讯开源的 BrowserSkill 走的是这条路。
三条路线的差别不在能力上限，而在「谁决定智能体能做什么」被放在哪一层，以及这个决定能不能被用户看见和修改。内置路线把决定权留在厂商内部；沙箱路线把决定权交给隔离配置；桥接路线把决定权交给浏览器设置与扩展权限清单。
为什么这一层今年变得重要
有几件事在今年同时发生，把浏览器推到了智能体的中心位置。
一是模型能力的重心从「回答问题」转向「完成任务」。要在网页上完成任务，就要能读页面、能操作、能保持会话，这三件事浏览器本来就有。
二是浏览器的分发位置没有替代品。桌面端的入口、已经登录好的一切、以及默认就知道用户在看什么，这三点是任何独立应用都难以复制的。
三是扩展权限模型的历史包袱。第三方观察里有一句评论很准：扩展的权限模型比智能体助手早了十年，它按页面授予访问权，而这个粒度无法区分「读一篇文章」与「读一段对话」。当同一个扩展权限既能读普通网页又能读到你的助手会话时，隔离就成了一个纸面上的概念。
这三点叠加的结果是：浏览器不再只是智能体的一个使用场景，而是它权限最集中、上下文最真实、也最难被替代的地方。
对企业采购与 IT 的四条提示
其一，把「扩展清单」和「浏览器内智能体」当成组合风险来评估。单看任何一项都不算出格，组合在一起才是被演示过的攻击面。
其二，浏览器内智能体的权限边界要能枚举出来。如果连它可以访问哪些页面、哪些接口、哪些数据都列不全，那就不具备做风险评估的前提。
其三，零数据保留这类承诺要落在合同里，并保留复核权。它描述的是某家厂商在某个时刻的处理方式，而处理方式会随版本与政策变化。
其四，如果业务确实依赖浏览器自动化，优先选权限外置、调用可审计的形态。原因不是这类形态更安全，而是它的权限位置更清楚——出了问题能定位到是哪一条权限被用掉了。
接下来要看什么
一是英国与德国的落地时间表。多语言微调的效果能不能在更多市场成立，要看这一步。
二是其他浏览器是否会跟进开放权重模型。如果只有一家这样做，它更像是差异化定位；如果形成趋势，浏览器与模型之间的默认绑定关系就会松动。
三是扩展权限模型会不会引入「能读取对话内容」这一级的区分度。这是把 BragJack 那一类问题从架构上收窄的前提，也是目前看不到动静的一处。
四是企业内部会不会默认关闭浏览器内的智能体功能。有安全机构已经给出了这类建议，但它在「可用」与「可控」之间的取舍，最终要由使用场景决定，而不是由安全团队单独决定。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。