当网页开始给 Agent 提供工具：WebMCP 正在重画浏览器安全边界

过去几十年，浏览器安全有一条非常重要的边界：Origin，也就是“源”。

简单来说，浏览器会通过“协议 + 域名 + 端口”判断两个网页是不是属于同一个安全域。

https://shop.com 里的代码，可以比较自由地操作 shop.com 的页面，却不能随便读取另一个网站的数据。

这套以 Same-Origin Policy（同源策略，SOP）为核心的模型，构成了现代 Web 安全的基础。

但 Agent 正在改变这件事。

W3C Web Machine Learning Community Group 正在推进一项名为 WebMCP 的提案，让网页不再只是给人看的页面，还可以直接向 AI Agent 暴露结构化 Tool。

比如一个购物网站可以告诉 Agent：“我这里有搜索商品、加入购物车、查询订单、结账这些工具，你不需要再识别网页按钮，直接调用即可。”

截至 2026 年 8 月，WebMCP 仍是 Community Group Draft，而不是正式 W3C Standard，但它所代表的方向已经很明确：Web 正在从“给 Agent 看”走向“给 Agent 调用”。

问题也随之发生变化。

当网页开始给 Agent 提供能够直接执行动作的工具时，仅仅知道“这个网页来自哪个网站”，可能已经不够了。Agent 还必须知道：

这个 Tool 到底是谁创建的？谁拥有它？什么时候应该失效？执行过程中做了什么？它返回给 Agent 的内容还能不能继续信？以及——在完成这些检查之前，它是否已经被调用了？

2026 年 8 月发布的论文《WebMCP-Phalanx: Enforcing and Characterizing Trust Boundaries for Browser-Integrated LLM Agents》，讨论的正是这个问题。

论文原文（arXiv）

这篇论文真正值得关注的地方，并不是又提出了一个 Prompt Injection 检测器，而是提出了一个更根本的判断：

Agent 进入浏览器之后，Web 的安全边界可能需要从 Origin 进一步细化到 Script、Tool、Lifecycle 和 Execution。

WebMCP 到底改变了什么？

今天很多 Web Agent 操作网站的方式，本质上还是“模仿人”。

Agent 先读取网页 DOM、截图或者 Accessibility Tree，找到“搜索框”“提交”“购买”等控件，再模拟鼠标点击和键盘输入。

这种方式的问题非常明显：网页结构稍微变化，Agent 就可能找错按钮；同一个“购买”动作，在不同网站上也可能有完全不同的页面结构。

WebMCP 想做的是另一条路线。

网页可以直接声明：

search_products get_order add_to_cart checkout

并告诉 Agent 每个 Tool 的用途、输入参数和调用方法。

于是过去：

用户目标
↓
Agent 理解网页
↓
找到按钮
↓
模拟点击
↓
执行动作

开始变成：

用户目标
↓
Agent 发现网页提供的 Tool
↓
选择 Tool
↓
直接调用

对于 Agent 来说，这显然更稳定、更高效。

WebMCP 官方草案也将其定义为一种让 Web 应用通过 JavaScript 向 Agent 暴露工具的接口。

但安全问题也从“Agent 有没有看懂网页”，转向了一个更加危险的问题：

Agent 调用的这个 Tool，到底能不能相信？

为什么过去的“同源策略”突然不够用了？

这里需要先理解一个容易被忽略的 Web 机制。

假设用户打开：https://shop.com

商城为了统计、广告、客服等功能，又加载了很多第三方 JavaScript：

shop.com ├── 商城自己的 JS ├── 广告 SDK ├── Analytics SDK └── 推荐系统 SDK

广告 SDK 的代码文件可能实际下载自 ads.com，但如果它通过普通

也就是说：

代码从哪里下载，和代码以哪个页面的权限运行，并不是同一件事。

过去这已经是 Web 供应链安全里的重要风险：一个被攻破的第三方 SDK，可能读取页面内容、修改 DOM、访问页面 JavaScript 对象或者发起网络请求。

WebMCP 又增加了一层能力：

第三方 JS
↓
访问 WebMCP 接口
↓
注册 Agent Tool
↓
Agent 发现 Tool
↓
Agent 调用 Tool

论文把攻击者设定为被攻破的广告 SDK 或污染的 Analytics Script。

由于这些脚本运行在页面环境中，它们能够与网站自己的程序访问同一套 WebMCP Tool Registry。

论文认为，在其研究的 WebMCP 草案模型下，不同可信程度的脚本之间缺少足够明确的 Tool 信任边界。

这时候只告诉 Agent：

Origin = shop.com

已经没有办法回答最关键的问题：

这个 Tool 究竟是商城官方代码注册的， 还是一个广告 SDK 注册的？

这就是整篇论文最重要的出发点：

Origin 不等于 Tool Identity。

传统浏览器回答的是：

“这段行为发生在哪个网站？”

而 Agent 时代还需要继续回答：

“这个网站里的哪一个代码主体，创建了哪一个工具？”

WebMCP 带来的不只是 Prompt Injection

作者在这个基础上总结了四类问题。

第一类是 Subject Attribution Failure，主体归属失败。

如果 Tool Registry 无法准确表达 Tool 的创建主体，恶意脚本就可能抢占 Tool 名称、尝试删除别人的 Tool，甚至把 Agent 原本准备调用的正常 Tool 替换掉。

第二类是 Lifecycle Loss of Control，工具生命周期失控。

现在大量网站都是 SPA（单页应用）。用户看起来已经从“商品页”进入了“支付页”，但浏览器实际上可能只是调用 pushState() 改变页面状态，并没有真正重新加载网页。

于是会出现一个很反直觉的问题：

页面在用户看来已经换了，但上一页面注册的 Tool 可能还活着。

第三类是 Execution Opacity，执行过程不透明。

一个 Tool 可以声明自己是“只读”的，但真正执行的时候偷偷发送网络请求。对于 Agent 来说，Tool 的声明和 Tool 的真实行为可能并不是一回事。

第四类才是我们比较熟悉的 Semantic Injection，语义注入。

恶意指令可以藏在：

Tool Name Tool Description Input Schema Tool Return

这些 Agent 能够读取的内容中。

于是攻击链就不再只是：

恶意网页文字
↓
Prompt Injection
↓
Agent 被误导

而可能变成：

恶意网页脚本
↓
污染 Tool Surface
↓
操纵 Agent 对工具的发现、选择和调用
↓
改变 Agent 控制流

作者将前两类归为更偏协议和状态层面的攻击，将后面的语义污染视为内容层攻击，并认为它们不能单靠一个 LLM Guardrail 解决。

这也是这篇工作和普通“网页提示词注入”研究最大的区别。

第一道防线：让浏览器成为 Tool 的信任根

WebMCP-Phalanx 因此没有先从训练一个更强的安全模型入手。

作者首先做的是：

把 Tool 的所有权从 JavaScript 世界下沉到浏览器 Native Layer。

他们设计了一个 Tool Ownership Authority，工具所有权管理器。

当某段脚本注册一个 Tool 时，浏览器为其生成一个不可伪造的 Capability Credential，可以理解为这个 Tool 的“持有凭证”。

以后想修改、删除或者覆盖这个 Tool，就必须持有对应凭证。

于是安全模型从同一个页面里的脚本都能操作 Tool Registry

变成：

Script A
↓
Tool A
↓
Credential A
Script B
↓
Tool B
↓
Credential B

Script B 即使和 Script A 位于同一个 Origin，也不能拿自己的 Credential 去修改 Tool A。

论文实验中，针对正常 Tool 的 overwrite 和 revocation 攻击从 20/20 成功下降到 0/20。

这里需要注意，Capability-based Security 并不是新的安全思想。真正的新意在于：

作者试图把 Capability Ownership 引入 WebMCP Tool Registry，让浏览器而不是 LLM 成为 Tool Ownership 的信任根。

因为“这个 Tool 属于谁”本质上不是一个语言理解问题。

它不应该让 Agent 看完 Tool Description 后自己猜：

“这看起来挺像官方 Tool。”

它应该由底层系统直接提供确定性的安全事实。

Tool 可信不是一次认证，而是一个持续变化的状态

只有 Tool Ownership 还远远不够。

WebMCP-Phalanx 又增加了三组浏览器侧信号。

第一组是 Registry Attribution，记录 Tool 的注册来源。

第二组是 Lifecycle Monitor。Tool 注册时声明自己的生命周期，例如：

session navigation

浏览器监控 SPA 中的 pushState、replaceState等逻辑页面切换，一旦导航发生，就清除只属于上一页面的 Tool。

第三组更加重要：Runtime Observation，运行时观察。

比如一个 Tool 宣称：

read_only = true

但真正执行的时候突然出现：

网络请求 数据外传 DOM 修改

系统就认为：

Tool 声明行为 ≠ Tool 实际行为

并将它的 Trust Label 降级。

作者监控了 fetch、sendBeacon、Image.src 等外发路径以及 DOM Mutation，并根据运行时行为重新计算 Tool 的可信等级。

最终，每个 Tool 得到 Green、Yellow、Red 三种 Trust Tier：

Green
来源可信 + 行为符合声明
↓
可以正常执行

Yellow
来源可信，但操作存在一定风险
↓
需要额外检查

Red
来源异常或运行时行为违规
↓
隔离或阻断

这背后其实对应一个很重要的 Agent 安全原则：

信任不是 Tool 注册时盖一次章，而应该贯穿 Tool 的整个生命周期。

第二道防线：能看危险内容的 Agent，没有执行权限

浏览器可以判断 Tool 的来源、生命周期和实际行为，但仍然解决不了一个问题：

语言本身是不是恶意的。

比如一个来源完全正常的 Tool，其 Return 中仍然可能包含 Prompt Injection。

于是 WebMCP-Phalanx 又设计了第二层：双 Agent 权限隔离。

整个系统里存在两个角色：

Quarantine Agent（Q-LLM，隔离 Agent）负责读取和分析可疑内容，但没有 Tool Calling 权限。

Privileged Agent（P-LLM，特权 Agent）负责真正完成任务和调用 Tool，但不应该直接接触未经检查的不可信内容。

于是数据流变成：

可疑 Tool / 内容
↓
Q-LLM
   语义安全检查
↓
通过
↓
P-LLM
↓
Tool Execution

Q-LLM 主要检查两个位置：

Tool 注册前
↓
Description / Schema

Tool 执行后
↓
Return Content

攻击内容即使把 Q-LLM“骗了进去”，由于 Q 没有 Tool 权限，也无法直接把语义攻击转换成高权限动作。

本质上，这是传统安全工程中的 Privilege Separation，权限分离：

接触不可信输入的组件，不应该同时拥有高权限执行能力。

这套思想本身并不新，但 Phalanx 的价值在于，它把浏览器产生的确定性 Trust Label 与 Agent Runtime 的语义判断连接了起来：

Browser Trust
↓
Tool Label
↓
Data Routing
↓
Q-LLM / P-LLM
↓
Execution

也就是说，“工具是谁”由系统回答，“工具说了什么”才交给模型回答。

实验一开始很好看：69/80 直接降到了 0/80

作者设计了四档防御：

L0：没有防御 L1：只使用 Trust Label L2：规则化删除可疑内容 L3：多 Agent 语义判断

对于 Tool Description 中的 Prompt Injection，攻击结果是：

而对于 Tool Return Injection：

有意思的是，只增加 Trust Label 几乎解决不了语义注入。

这是合理的。

你可以证明：

这个 Tool 确实是 A 注册的

却无法因此证明：

这个 Tool 返回的文字一定安全

身份安全与内容安全解决的是两个不同问题。

另一方面，L3 对 Description Injection 的攻击成功率从 69/80 降到了 0/80，而且与无攻击基线相比，作者没有观察到具有统计显著性的正常任务能力损失。

乍看之下，这似乎已经是一套相当成功的防御系统。

但整篇论文真正有意思的地方，恰恰从这里才开始。

检测器没有失效，系统却还是被攻破了

作者随后引入了更强的 White-box Adaptive Attacker，白盒自适应攻击者。

攻击者知道 Q-LLM 用什么 Prompt 做判断，也能够根据攻击是否成功不断调整 Payload。

结果非常醒目：

16 个 Description-layer 攻击中，有 15 个最终成功绕过，攻击者中位数只需要一次改写。

但这里有一个非常关键的细节。

攻击者并没有真正“打败”Q-LLM。

它没有找到一句神奇的 Prompt，让安全模型把明显的恶意内容判断成安全。

攻击者做了另一件事：

把攻击从 Q-LLM 正在检查的位置，搬到了 Tool Name，并利用与用户任务高度相关的工具名称，让 Agent 在安全检查完成之前就产生了 Tool Call。

论文发现，随着 Tool Name 与任务相关度增加，仅靠规则删除 Description 的 L2 防御攻击成功率从 0% 一路增长到 70%。

这揭示了一个比“检测模型准确率”更深的问题：

Tool 被 Agent 看见
↓
Agent 根据 Name 选择 Tool
↓
Tool 已经被调用
↓
安全系统检查 Description

检查器可能完全正确。

只是它来晚了。

这就是论文最值得 Agent 安全工程关注的结论之一：

Security Check 的存在，并不等于 Security Check 位于正确的控制流位置。

因此作者提出需要增加 Call-Timing Gate，工具调用时序门：

Tool 出现
↓
检查所有 Agent 可见 Metadata
↓
建立 Trust
↓
允许参与 Tool Selection
↓
允许 Tool Invocation

而不是：

Tool Selection
↓
Tool Invocation
↓
Security Check

换句话说：

Agent 安全不仅要回答“检查什么”，还必须回答“在什么时候检查”。

这已经不只是内容安全问题，而是 Agent Runtime Control Flow Security——Agent 运行时控制流安全。

Tool 消失了，攻击为什么还能继续？

论文还发现了另一个很容易被忽略的问题：Cross-page Semantic Residual，跨页面语义残留。

假设 Agent 在 Page A 调用了一个恶意 Tool。

Tool Return 中写入了一条恶意指令。

随后 Agent 跳转 Page B。

Lifecycle Monitor 正确工作：

Page A Tool
↓
页面切换
↓
Tool 被删除

从传统资源生命周期来看，问题似乎已经解决。

但真正的问题是：

恶意 Tool Return
↓
已经进入 Agent Context
↓
Tool 被删除
↓
恶意语义仍然留在 Conversation History

作者的实验中：

无防御：攻击成功率 80% 只清理 Tool：攻击成功率仍有 70% Lifecycle Monitor + Phalanx：攻击成功率 0%

这意味着 Agent 时代的“生命周期”也需要重新定义。

传统系统里：

Object 被删除，生命周期就结束。

Agent 系统里却可能是：

Tool 被删除，但 Tool 曾经产生的信息还活在模型 Context 里。

因此 Tool 的 Trust Lifecycle 不能只绑定：

Tool Object

还必须传播到：

Tool
↓
Tool Output
↓
Conversation Context
↓
后续 Planning

这是一个非常值得延伸的结论：

在 Agent 系统里，数据的信任生命周期可能比数据源本身活得更久。

这和今天讨论的 Agent Memory Poisoning、RAG Poisoning 其实存在非常相似的安全逻辑。

Phalanx 还没有真正解决“谁注册了这个 Tool”

到这里可能会产生一个误解：

既然浏览器给 Tool 发了不可伪造的 Capability，是不是已经知道这个 Tool 到底是谁注册的？

实际上没有完全解决。

Capability 能证明：

现在拿着这把钥匙的人，就是当初注册这个 Tool 的主体。

但它不能证明：

这个主体究竟是商城官方 JS，还是商城主动加载的某个广告 SDK。

如果恶意 partner.js 自己合法调用 registerTool()，浏览器同样可以给它发一把合法的 Capability。

于是：

Capability可以证明 Ownership,但不能自动证明 Identity / Trustworthiness.

作者因此明确承认，Subject Attribution 仍然没有被彻底解决。

他们认为未来 WebMCP 需要进一步增加两个原语。

一个是 Native Script Provenance：

由浏览器底层记录真正不可伪造的 Script 来源，而不是依赖 JavaScript 自己报告。

另一个是 Declarative Trust Topology：

网站需要明确告诉浏览器：

我加载了这个第三方 SDK ≠ 我授权这个 SDK 成为 Agent Tool Provider

因为：

Loaded by 并不等于 Trusted by。

作者认为这种信任关系需要像 Content Security Policy 一样，由站点显式声明，而不是让浏览器自己猜。

这实际上把文章最开始那个问题进一步推进了一层：

Origin
↓
Script Provenance
↓
Tool Ownership
↓
Tool Runtime Behavior
↓
Tool-generated Content
↓
Agent Execution

Agent 时代需要的，可能正是这样一条更加细粒度的信任链。

这篇论文也远没有把问题解决完

WebMCP-Phalanx 是一个很有意思的安全架构，但距离真正可部署的浏览器级安全机制还有明显距离。

首先，论文的参考实现仍然主要是 JavaScript Polyfill。真正意义上的 Native Browser API Integrity 和不可伪造的 Script Provenance，并没有完整落到 Chrome、Edge 等浏览器 Native Layer 中，其中一些安全属性实际上还是架构假设。

其次，Runtime Observation 更多是 detect and contain，而不是完全的 prevent。

如果一个 Tool 第一次执行时已经完成数据外传，系统事后发现“这个 Tool 行为异常”并把它标红，并不能撤销已经发生的副作用。作者也因此指出，更强的确定性防护最终可能仍需要 Browser-level Sandbox。

第三，Capability 本质上是一种 bearer credential。如果持有者主动泄露 Capability，或者暴露了一个替别人执行敏感操作的接口，仍然可能出现经典的 Confused Deputy 等问题。

最后还有一个必须强调的背景：WebMCP 本身仍在快速变化。

论文实验使用的是 2026 年 6 月 17 日版本草案；而截至 8 月 26 日，官方 Community Group Draft 已经继续演进，并增加了更完整的 Security and Privacy Considerations。

当前 WebMCP 也仍明确标注为 Community Group Report，而不是正式的 W3C Standard。

所以更准确的理解不是：

“研究人员发现了一个已经固化在所有浏览器里的 WebMCP 漏洞。”

而是：

WebMCP 仍处于安全模型可以被重新设计的阶段，而这篇论文试图在标准大规模落地之前，把 Tool Trust Boundary 这个问题提前暴露出来。

从安全工程角度看，这反而可能是它最有价值的地方。

Agent 安全真正缺的可能不是更多检测器

过去一年，大量 Agent 安全工作仍然围绕一个问题展开：

这段输入是不是恶意的？

于是我们不断增加：

Prompt Injection Detector Guard Model Safety Classifier LLM Judge

这些当然重要。

但 WebMCP-Phalanx 提醒我们，还有另一类问题根本无法靠“把检测模型做得更准”解决。

比如：

这个 Tool 到底是谁创建的？ 这个主体有没有权限注册它？ Tool 是否已经过期？ 它声明和实际执行是否一致？ 它产生的内容是否应该继续进入 Context？ 安全检查发生在 Tool Call 之前还是之后？

这些问题，本质上属于：

Identity、Authorization、Lifecycle、Data Flow 和 Control Flow。

换句话说：

模型负责理解语义，系统负责建立边界。

如果安全架构本身无法告诉模型：

什么是可信输入 谁拥有执行权限 哪些数据可以流向哪里 什么时候允许产生副作用

那么即使模型拥有非常强的安全判断能力，最终仍然可能工作在一个错误的信任基础上。

这也是为什么这篇论文中最值得记住的实验，不是：

“69/80 降到了 0/80。”

而是：

检测器没有判断错，系统仍然被绕过了。

因为攻击者绕过的不是模型本身，而是 模型在整个 Agent Runtime 中所处的位置。

Agent 正在迫使浏览器重新定义“谁值得信任”

过去浏览器最重要的问题之一是：

这个网页来自哪里？

于是我们有了 Origin、Same-Origin Policy、CORS、CSP 等一整套围绕 Web 主体建立起来的安全机制。

但当 Web 页面开始主动向 Agent 提供能够执行动作的 Tool 后，问题正在变成：

这个 Tool 是谁创建的？

谁拥有它？

它现在还应该存在吗？

它真正执行了什么？

它产生的信息还能信多久？

在 Agent 调用它以前，安全检查完成了吗？

这也是 WebMCP-Phalanx 最重要的意义。

它并没有证明现有浏览器安全模型已经失效，更没有解决 WebMCP 的所有安全问题。

但它非常清楚地指出了一件事：

Origin 仍然重要，却已经不足以独自承担 Agent 时代的 Tool Trust Boundary。

未来浏览器可能不仅需要知道：

这是哪个网站。

还需要建立一条更加完整的链：

Origin
↓
Script Provenance
↓
Tool Identity / Ownership
↓
Lifecycle
↓
Runtime Behavior
↓
Generated Content
↓
Agent Call Timing
↓
Execution

当网页只是给人看的时候，Origin 是一条非常成功的安全边界。

当网页开始直接给 Agent 提供工具之后，我们可能需要重新回答一个更加基础的问题：

究竟什么，才应该成为 Agent 可以信任并执行的最小安全主体？

这场变化，或许才刚刚开始。