为什么 Web AI Agent 比独立 LLM 更脆弱——以及我们应该如何真正修复它

Web AI Agent 代表了 AI 在真实系统落地方式的一次大转向：它不再只是“生成文本”，而是会观察实时网页、做决策、并执行真实动作（点击按钮、提交表单、在应用中导航）。能力的跃迁带来巨大价值，但也带来更本质的风险：它更暴露、更容易被利用，如果系统设计草率，后果会比纯文本聊天严重得多。

下面的观点基于近期的安全分析：Web AI Agent 的关键问题不是“模型不够聪明”，而是“系统边界不够硬”。理解脆弱性从何而来、会以什么形态出现、以及应该怎样修复，对于任何在做 AI 产品/平台/研究系统的人都很关键。

✍️ 为什么独立（Standalone）LLM 天然更安全

独立 LLM 通常工作在一个相对“封闭”的世界里：接收输入 → 生成输出 → 结束。即使输出错误、误导或存在偏差，其影响更多停留在“信息层面”。

更重要的是：它不会点击 UI、不会执行命令、也无法直接触达外部系统的真实状态（资金、权限、数据、业务流程）。从安全角度看，这种“只能说不能做”的结构天然把伤害半径限制住了。

✍️ 当我们迈向 Web AI Agent，发生了什么变化

Web AI Agent 直接打破了上述安全边界：它持续与“不受信任的环境”交互——主要就是它并不控制的网页。网页里可能包含任意文本、隐藏指令、误导性内容，甚至恶意 payload。

Agent 会读取这些内容、推理并决定下一步要做什么。于是出现一个紧密的“感知—行动”反馈回路，而脆弱性正是在这个回路里被引入的。

一句话总结：Agent 倾向于相信它看到的内容，但它看到的并不可信。

✍️ Web AI Agent 更脆弱的核心原因

最核心的问题是：“指令（instructions）与数据（data）被混在同一个通道里处理”。

很多 Web Agent 会把网页内容与系统指令一起喂进模型的推理上下文。这样一来，Agent 很难可靠地区分：

哪些是系统允许它做的（policy / system intent）
哪些只是网页在“说”的东西（untrusted content）

恶意或被操纵的网页内容就能利用这种歧义。相比之下，独立 LLM 主要接收来自可信源的结构化提示，攻击面更小。

✍️ 指令注入（Instruction Injection）：最危险的缺口

指令注入是 Web AI Agent 的标志性安全问题。

网页可以塞入一些对人类看起来“无害”的文本，但 Agent 可能把它当作可执行指令。由于 Agent 的目标是完成任务，它甚至可能在不知不觉中遵循这些指令——即便这些指令与系统本意冲突。

这并不是因为模型“太弱”，而是因为架构允许它把“我被允许做什么”和“我读到什么”混为一谈：缺少一道强边界。

✍️ 为什么传统的 Prompt 安全不够用

很多团队会试图用更强的提示词、更复杂的 guardrails，或换更强的模型来“补救”。但这并不可靠。

Prompt 级防护假设输入是合作式的；而 Web 环境天然是对抗式的。只要原始网页内容仍然直接流入 Agent 的推理回路，脆弱性就会持续存在。

这是一道架构题，不是一道提示词题。

✍️ 大多数系统忽略的架构缺口：缺乏关注点分离

安全系统通常会把以下环节拆开：观测（observation）、推理（reasoning）、策略（policy）、执行（action）。

但不少 Agent 实现把它们揉成一个由模型驱动的循环：模型既决定“要做什么”，又决定“是否被允许”。当模型同时扮演执行者与裁判时，控制权就丢了。

✍️ 在真实产品里，这类脆弱性会如何表现

在真实系统中，这会导致 Agent：

点击破坏性 UI（删除/清空/确认等）
泄露敏感信息
执行未授权操作
无意间升级权限
被恶意网页内容操纵

对企业来说，这意味着运营风险、合规失败和信任损失——即便 demo 看起来“效果很好”。

✍️ 我们应该怎样真正修复：把边界做硬，而不是把模型做聪明

正确方向不是“更聪明的模型”，而是“更强的系统边界”。Web AI Agent 需要被设计成：

模型只负责提出动作建议（propose）
独立的策略层/校验层负责验证（validate）
只有通过批准才执行（execute-after-approval）
网页内容一律视为不可信输入（untrusted input）

实践中，就是把“绝对控制权”从模型手里拿走。

1
2
3
4


if policy.allows(action):
    execute(action)
else:
    block(action)

这个简单模式背后是一种关键转变：AI 提建议，系统做决定。

✍️ 一个更合理的最小 Agent 架构

更安全的 Web Agent 应当把关注点拆开，概念上可以是：

[Policy Layer] → 定义允许做什么
[Planner] → 决定下一步
[Browser Interface] → 执行动作
[Observation Filter] → 过滤/结构化网页输入

关键点：Agent 不应该直接在“原始网页内容”上推理，而应该在过滤后的、结构化的观测上推理。

✍️ 一个改变一切的简单代码模式

下面是一个 Python 风格的简化结构示例：

1
2
3
4
5
6
7
8
9


class WebAgent:
    def decide(self, state):
        allowed_actions = self.policy(state)
        return self.planner(state, allowed_actions)

    def act(self, action):
        if not self.policy.allows(action):
            raise Exception("Action not permitted")
        return self.browser.execute(action)

这个设计的意义在于：模型从来都不拥有“绝对控制权”。业务规则与安全策略在模型之外，而不是靠 prompt 去“哄”模型遵守。

✍️ 一个更安全的 Web AI Agent 架构（概念图）

这个架构表达了一件事：AI 模型不是“负责人”。Planner 提建议，但是否允许、如何约束、能否执行由策略与验证层决定；网页内容被当作不可信输入，先过滤再推理。

                ┌────────────────────┐
                │   Business Policy  │
                │ (What is allowed?) │
                └─────────▲──────────┘
                          │
┌─────────────┐   ┌────────┴────────┐   ┌─────────────┐
│  Web Page   │──▶│ Observation      │──▶│   Planner   │
│ (Untrusted) │   │ Filter & Parser  │   │   (LLM)     │
└─────────────┘   └────────▲─────────┘   └──────▲──────┘
                             │                    │
                    Allowed Actions Only          │
                             │                    │
                       ┌─────┴─────┐        ┌────┴────────┐
                       │ Validator │        │ Browser/API  │
                       │ & Guard   │───────▶│ Executor     │
                       └───────────┘        └──────────────┘

✍️ 为什么这也是“领导力与产品”问题

Web AI Agent 的安全失败很少是因为“智能不足”，更多是因为团队在速度与结构之间选择了速度。

一旦 AI 系统能行动，它就应该像基础设施一样被治理，而不是当成一个“功能点”快速堆上去。这要求工程、安全、产品与风险一起参与，而不是把责任都丢给模型或 prompt。

✍️ 未来工作：研究与产业接下来必须攻克的方向

Web AI Agent 的未来依赖的不只是更强模型。关键方向包括：

更强的“不可信输入隔离”与过滤
对允许动作的形式化验证（formal verification）
可审计的 Agent 行为与日志
标准化的 Agent 架构模式

研究需要走向系统级保证，而不是只盯着性能指标。产业落地则取决于：Agent 在最坏情况下是否仍然可控与可信，而不只是“平均表现不错”。

References

WHY ARE WEB AI AGENTS MORE VULNERABLE THAN STANDALONE LLMS? A SECURITY ANALYSIS — https://arxiv.org/pdf/2502.20383