[论文学习]CellMate:浏览器AI代理的沙箱化方案

HK2KING

343人浏览 · 2026-08-19 00:15:00

HK2KING · 2026-08-19 00:15:00 发布

Cellmate: Sandboxing Browser AI Agents (2026)

论文重点

本文提出了CellMate，一个针对浏览器使用代理（Browser-Using Agents, BUAs）的浏览器级沙箱框架。其核心洞察在于将沙箱策略的执行从语义模糊的UI操作层（点击、键盘输入）上移到语义明确的HTTP请求层，因为所有产生副作用的UI操作最终都会表现为网路请求。实验结果表明，该方法能够在WASP基准测试中有效阻断提示注入攻击，且仅带来7.25%至15%的延迟开销。

核心研究内容

问题定义

浏览器使用代理（如OpenAI Atlas、Perplexity Comet、Anthropic Claude-for-Chrome等）能够像人类一样与网页互动——点击、滚动、填写表单、跨页面导航。然而，这类代理继承了底层LLM的提示注入漏洞：攻击者可以通过在网页中嵌入恶意指令，诱导代理执行未经授权的操作，如洩露私人信息或发起非预期的状态变更请求。

传统的防禦思路是在UI工具层面（如点击、键击）约束代理行为，但这种方法存在根本性的「语义鸿沟」（semantic gap）问题——策略的表述层次（如「购买金额不得超过50美元」）与执行层次（如「禁止点击座标(246,1023)」）完全不在同一抽象级别，导致策略既难以撰写也难以正确执行。此外，浏览器状态可以通过无数种不同的操作序列到达，穷举封锁所有路径在实践中不可行。

创新方法

CellMate的核心创新在于将沙箱执行从UI层转移到HTTP层。这一设计背后的关键洞察是：无论代理通过何种UI操作序列达成目标，所有会产生实际影响的操作最终都会表现为HTTP请求发往网站后端。与点击、键击等缺乏内在意义的UI操作不同，HTTP请求本身具有明确的语义——例如，POST https://gitlab.com/-/user_settings/ssh_keys 对应的就是「为用户添加SSH密钥」这一动作。

为了解决「哪些HTTP请求需要被拦截」以及「策略如何在运行时获取参数」的问题，论文引入了「代理站点地图」（agent sitemap）的概念。这是一种由网站开发者维护的结构化文件，类似于传统的robots.txt或CSP（Content Security Policy）头部，用于将网站内的HTTP请求映射到对应的语义动作。基于代理站点地图，政策制定者（网站开发者、企业管理员或经过审核的第三方）可以定义一系列策略——允许、拒绝或在特定条件下允许某个语义动作。

CellMate採用三阶段工作流程：

註册阶段：网站开发者提供代理站点地图，信任来源提供策略生成器；
策略实例化阶段：根据用户的自然语言任务，策略选择器自动选取并实例化最小必要策略集；
策略执行阶段：代理执行过程中，CellMate在专用浏览器会话中严格中介所有HTTP请求。

CellMate的设计是代理无关的（agent-agnostic），以Chrome扩展的形式实现，因此可以保护用户而无需对具体的BUA做任何修改。

研究成果

论文的主要研究成果包括：

安全性验证：在WASP基准测试中，CellMate成功阻断了提示注入攻击。
性能开销：仅带来7.25%至15%的延迟开销。
策略选择准确率：使用最先进的LLM进行策略选择和实例化，在所有任务类别上的总体准确率超过94%。
开源实现：CellMate已在GitHub上开源（https://cellmate-sandbox.github.io）。

实际落地应用的可能性

CellMate的设计充分考虑了现实生态系统的协作需求：

网站开发者：已有维护CSP、robots.txt、OAuth作用域等安全元数据的经验，代理站点地图可自然融入现有工作流程。
企业用户：企业往往是浏览器代理的早期採用者，系统管理员可以通过Chrome策略定义必要的浏览器级约束。
终端用户：无需具备安全专业知识，CellMate会根据用户的自然语言任务自动选择适当策略。

论文作者期望代理站点地图能发展成为一项公开标准，帮助网站遵守如欧盟AI安全法案等即将出台的AI安全法规。

技术细节

HTTP层沙箱的核心逻辑

CellMate的沙箱逻辑可以用以下伪代码概括：

function enforcePolicy(httpRequest, policySet):
    semanticAction = agentSitemap.lookup(httpRequest)
    if semanticAction is None:
        // 未在代理站点地图中定义的请求，预设行为
        return DENY  // 或根据配置决定
    for policy in policySet:
        if policy.appliesTo(semanticAction):
            if policy.effect == DENY:
                return DENY
            if policy.effect == CONDITIONAL:
                if evaluateCondition(policy.condition, httpRequest):
                    return ALLOW
                else:
                    return DENY
    return ALLOW  // 默认允许已定义且未被策略拒绝的动作

代理站点地图结构

论文以Amazon为例展示了代理站点地图的结构：

{
  "semantic_action": "PlaceOrder",
  "description": "Submit the final purchase request to complete the transaction",
  "url": "https://www.amazon.com/checkout/p/*/spc/place-order*",
  "method": "POST",
  "body": {},
  "args": {
    "totalAmount": {
      "type": "number",
      "source": {
        "type": "dom",
        "url": "https://www.amazon.com/checkout/p/*",
        "selector": "#subtotals-marketplace-table li:nth-child(4) .order-summary-line-definition"
      }
    }
  }
}

每个条目包含：(1) 用于识别请求的匹配数据（HTTP方法、URL模式、请求体）；(2) 语义数据，包括唯一标识符（semantic_action）和自然语言描述。可选的args字段标识该动作的安全相关参数及其运行时提取方式。

策略定义示例

对应的策略定义如下：

{
  "name": "view_shopping_cart",
  "effect": "allow",
  "actions": ["ViewCart"],
  "description": "Allow viewing the shopping cart, including item details and quantities, total price, and applicable discounts."
}

Chrome扩展实现

CellMate作为Chrome扩展实现，利用浏览器的webRequest API拦截HTTP流量。这意味着它能够在请求发往网路之前进行检查和决策，实现完整的、稳定的中介——所有与域名的通信都会在HTTP层被一致地检查，无论动作是通过何种UI操作触发的。

研究设定

威胁模型

论文假设提示注入攻击者在现实约束下运作：

攻击者可控制受信任域名的非信任部分（如GitHub issue的标题和描述、Amazon的产品评论）；
攻击者可控制用户可能误导代理访问的互联网域名；
攻击者可利用重定向和TOCTOU（Time-of-Check to Time-of-Use）攻击；
攻击者的目标是利用BUAs的环境权限（ambient privilege），违反用户数据的机密性和完整性。

系统假设

标准的可信浏览器运行时；
BUAs被限制在网页上下文内的操作（点击、键入、导航），不能更改浏览器设置、访问本地文件或使用开发者工具；
代理站点地图由网站开发者或其安全团队创建并托管在知名位置；
CellMate目前专注于单轮任务，可扩展至多轮交互（留待未来工作）。

硬体与软体需求

浏览器：Chrome（以扩展形式实现）；
代理框架：兼容任何使用Playwright或Puppeteer等浏览器自动化框架的BUA；
部署模式：代理可与浏览器同机部署，也可运行在独立机器上。

综合分析

与现有工作的对比

现有的提示注入防禦方案主要分为两类：一类是训练模型抵抗或检测提示注入，这类方法陷入了对抗性机器学习的「军备竞赛」——自适应攻击者似乎总能突破基于ML的防禦；另一类是系统级方案，如CaMeL、Fides和Progent，通过分离可信与非可信上下文、在工具调用层面执行权限控制来限制代理行为。

然而，这些系统级方案都隐含假设工具接口与安全边界之间存在清晰的映射——这一假设在BUAs场景中并不成立。BUAs的工具是低级的、缺乏语义的操作（点击、键击），其效果由执行上下文动态决定。CellMate的关键突破在于，它是第一个将策略执行与低级工具接口解耦的系统级防禦方案。

设计哲学的深度剖析

CellMate的设计体现了几个深刻的洞察：

第一，安全边界的选择决定了一切。 在传统系统中，策略的表述层次和执行层次天然对齐——Linux在文件层面做ACL，Android在系统服务层面做权限。但BUAs打破了这种对齐：策略是语义层面的（「不能删除邮件」），执行却是座标层面的（「不能点击(100,200)」）。CellMate通过HTTP层重新建立了这种对齐。

第二，信任委託的现实主义。 CellMate不要求终端用户具备安全专业知识，而是将策略制定委託给最有能力且最有动力的一方——网站开发者。这种设计借鉴了Android和OAuth的成功经验，反映了对现实生态系统中激励机制的深刻理解。

第三，失败闭合（fail closed）的保守策略。 当用户提示过于模糊（如「执行网站上的指令」）时，CellMate选择不授予访问权限。这虽然降低了代理的实用性，但避免了权限提升的风险——在安全与功能之间做出了明确的取捨。

潜在局限与改进方向

从批判性角度来看，CellMate仍有几个值得关注的局限：

依赖网站开发者的配合：代理站点地图需要网站开发者主动创建和维护，这在缺乏激励或资源不足的网站上可能难以推广。论文作者对此的乐观预期建立在与CSP、robots.txt类比的基础上，但这些标准的普及率其实参差不齐。
WebSocket等非HTTP协议的处理：论文承认WebSocket流量的执行需要进一步讨论，这在现代Web应用中越来越普遍。
多轮任务的支持：当前设计专注于单轮任务，多轮交互中动态管理累积上下文和权限的问题留待未来工作。
策略选择的准确性依赖于提示质量：虽然LLM在策略选择上达到了94%以上的准确率，但这建立在用户提示明确、意图清晰的前提下。

实践应用

对网站开发者的建议

及早规划代理站点地图：随着BUAs的普及，为AI代理提供结构化的操作边界将成为网站安全基础设施的一部分。建议从安全相关的关键操作（如支付、帐户设置、数据导出）开始构建。
借鉴现有路由结构：对于使用Rails等MVC框架的应用，HTTP路由到控制器动作的映射可直接作为代理站点地图的基础。
与CSP、OAuth等现有安全机制协同：代理站点地图应被视为现有安全元数据生态系统的自然延伸。

对企业IT管理员的建议

优先在高风险场景部署：涉及敏感数据访问或财务操作的BUA应用场景应优先部署CellMate。
结合企业现有Chrome策略：CellMate可与企业已有的Chrome策略管理框架结合使用。
制定分层策略：根据不同部门、不同任务类型制定差异化的策略集。

对BUA开发者的启示

CellMate是代理无关的：无需修改现有代理即可获得保护；
可考虑与CellMate进行更深层集成：例如在代理的决策循环中纳入策略反馈，帮助代理在执行前预判操作是否会被拒绝。

对研究者的启示

自动化代理站点地图生成：论文作者提到这是未来工作方向，具有重要的研究价值；
多轮对话中的动态权限管理：当前CellMate专注于单轮任务，多轮场景中的权限累积和撤回机制是值得探索的方向；
策略制定的形式化验证：如何确保策略本身是正确且完整的，避免策略本身的漏洞导致安全问题。

参考资料来源

原始论文：Meng, L., Feng, H., Shumailov, I., & Fernandes, E. (2026). ceLLMate: Sandboxing Browser AI Agents. arXiv preprint arXiv:2512.12594. https://arxiv.org/abs/2512.12594