浏览器代理：它们有哪些安全风险？

简要说明： 由AI驱动的浏览器代理的安全风险在结构上不同于传统软件风险：代理继承经过身份验证的会话，能够同时跨多个应用程序操作，并根据自然语言指令生成操作，而现有的任何控制层都无法解释这些操作。对其进行管理现在已成为构建网络弹性的一部分，因为您需要在部署前而非事件发生后，对身份和数据都有可见性。

浏览器代理已从试点项目迅速过渡到生产工作流，速度比大多数安全团队能够响应的速度更快。

每一次部署都会产生一种独特的暴露类别，而传统的安全控制无法看见、记录或加以治理——无论这是一种 Copilot 集成、一个 Claude 扩展，还是在金融领域运行的 ChatGPT 工作流。

认证层将代理视为可信用户，数据层无法看到它们访问了什么，而控制层是为确定性应用而构建的，并非用于在自然语言上运行的自主式应用。

本指南涵盖如何评估这种暴露、按风险等级对代理进行分类，并应用能够在不停止工作的情况下管理风险的控制措施。

什么是浏览器代理？

浏览器代理是一种 AI 系统，可在用户授权的情况下于网页浏览器内自主执行操作。它会浏览各类 Web 应用，填写表单，点击按钮，下载文件，并在经过身份验证的会话中跨越多个步骤执行工作流，而无需逐步的人工指导。

该代理会接收自然语言指令，使用大语言模型对其进行理解，并生成完成任务所需的操作序列——无论浏览器能够访问哪些应用。

如今浏览器代理如何工作

三个主要实现示例，展示了暴露的实际范围。

1. Anthropic 的 Claude 可以浏览网页、在不同标签页中执行操作，并与本地系统进行交互。Anthropic 自己的 research documentation 明确指出：“浏览器的使用以两种方式放大提示注入（prompt injection）的风险。首先，攻击面十分庞大：每一个网页、嵌入式文档、广告以及动态加载的脚本，都代表着一个可能被用于传递恶意指令的潜在向量。”

2. OpenAI 的 ChatGPT agent 包括四个组件：Operator（自主网页浏览）、Deep Research（多步骤的互联网调研）、Code Interpreter（Python 执行），以及与 Google Drive、GitHub 和 OneDrive 的集成。OpenAI 的 official documentation 明确表示：“这会引入新的风险，尤其是因为 ChatGPT agent 可以直接与您的数据协作。”

3. Microsoft Copilot Actions 在 Power Platform 基础设施上运行，使用 Power Automate 流程和经过认证的连接器。实际上，自动化操作可能会在用户的凭据下执行，这取决于配置方式，以及针对特定操作类型所实现的审批流程。

为什么现有安全控制看不到浏览器 agent 的活动

安全堆栈原本是为在结构化数据上运行的确定性应用程序而构建的。浏览器 agent 会以自然语言为输入，并产生概率性输出（probabilistic outputs），其工作在比现有所有控制运行位置更高的语义层（semantic layer）上。

现有工具运行在 agent 做出决策的层之下。

CASB、DLP、网络监控和 EDR 都在输出层运行。它们在做出决策之后，看到的是流量、模式以及进程活动。大多数现有工具很难观察代理在进行怎样的推理，或在浏览器标签页内执行了哪条指令。

当代理被指示汇总客户的财务数据并将其发送到外部时，它会通过一系列操作来完成任务，而这套操作在这四类工具看来都完全属于正常行为。

浏览器代理可以同时读取所有已认证会话

浏览器会强制执行同源策略（Same-Origin Policy，SOP），防止一个域上的脚本读取另一个域上的数据。以用户级进程或扩展方式运行的浏览器代理，可以有效穿越 SOP 通常会在脚本级别隔离的多个已认证会话。

它们以用户级进程运行，能够一次性访问浏览器中所有处于激活状态的已认证会话。这意味着人力资源系统、财务应用和 CRM 不再彼此隔离。

嵌入在网页、电子邮件或日历邀请中的恶意指令，可能会指示该代理在一个自动化流程中，从所有这些来源提取并组合数据。

代理流量会携带有效凭据，因此身份控制会将其放行

浏览器代理会通过现有的 SSO 会话进行身份验证，并从身份提供方继承有效的令牌。它们发出的每个请求都会通过授权通道，并携带合法凭据到达组织服务。

OAuth 和 SAML 会在会话存续期间将已认证的实体视为值得信任的对象；但当该实体是会随着每个提示而行为变化的自主代理时，这一模型就会失效。

浏览器代理的安全风险 5 种类型

以下风险并非假设性。每一类都有记录在案的真实世界事件，或已发表的研究原型，证明其正被积极利用。

1. 来自恶意网页内容的提示注入

OWASP LLM Top 10 将提示注入列为 LLM 应用的首要威胁：嵌入在代理处理内容中的恶意指令可能会彻底劫持其行为。

企业级浏览器代理尤其容易受到影响，因为它们通常会同时满足三种会最大化风险的条件：能够访问私有数据、会接触不受信任的内容，以及具备与外部进行通信的能力。

研究人员已证明，恶意的日历邀请、文档或嵌入的网页内容可能会触发非预期的代理操作，包括无需点击即可窃取本地或云端数据的行为。

对八种提示注入（prompt injection）防御方案的学术评估发现，它们都可以被绕过；published research 报告称，即使面对经过加固的防御，攻击成功率仍然很高。.

2. 向外部 AI 端点外传敏感数据

在许多组织中，员工会在使用获批准的企业工具的同时，还会使用免费档或个人账号的 AI 工具；而其中部分用法可能包含敏感数据或受监管数据。

由于大量的 GenAI 访问都通过浏览器进行，数据可能会通过安全堆栈将其视为正常网页流量的通道到达外部 AI 端点。

传统的 shadow AI controls 侧重于经批准的应用列表，并在结构上对这一模式缺乏感知。

3. 自动执行的操作导致业务中断和数据丢失

浏览器代理可能会继承破坏性权限（例如删除或不可逆的变更操作），并在任务被误解、范围界定不当或受到恶意内容影响时，以机器速度执行这些操作。

此外，在多智能体设置中，跨工具和跨会话的继承模式可能会在下游工具中促成未授权操作，而用户却无法获得清晰的可见性。

这些事件有一个共同的根本原因：代理被授予相当于用户的权限，却没有将这些权限限制在特定的预期任务上。

4. 凭据窃取、会话劫持和横向移动

康奈尔大学研究 表明，提示注入（prompt injection）已演变为与传统恶意软件活动相对应的五阶段攻击：初始访问、权限提升、在代理内存中的持久化、在已连接服务之间的横向移动，以及执行。

这些多跳攻击利用了这样一个事实：代理会同时在多个服务之间保持经过认证的会话。攻击者一旦成功注入指令，就能获得一条覆盖用户访问范围全貌的凭据链。

5. 未受治理的 AI 采用带来的“悄无声息”的合规偏移

现有框架并非为自主系统设计。在满足 HIPAA 的审计控制要求（45 CFR §164.312(b)）情况下，若浏览器代理在多个系统之间运行且缺乏统一的日志记录，就会立即产生违规。

在 GDPR Article 22 下，若代理在无人监督的情况下就数据访问作出自主决策，可能会违反自动化决策相关的保护措施。更广泛地说，影子 AI 可能会增加数据泄露与审计的影响，因为它往往会绕过标准的日志记录、保留（retention）以及访问治理控制。

如何评估您环境中的浏览器代理安全风险

在应用控制措施之前，组织需要在三个维度上建立基线：代理部署在哪里、它们能够访问哪些数据，以及权限继承（permission inheritance）呈现出怎样的情况。

步骤 1：盘点浏览器 AI 与扩展的使用情况

配置 DLP tools 以识别 AI 流量模式、拉取与主要 AI 服务连接的代理（proxy）日志，并查看 OAuth 授权日志。Microsoft Defender Vulnerability Management 可在 Edge、Chrome 和 Firefox 上原生提供浏览器扩展的盘点（inventory），且无需额外费用。

根据 LayerX Security 的 2025 Browser Security Annual Report，相当一部分企业浏览器扩展携带高或关键权限；其中，GenAI 扩展所请求的权限范围比标准扩展更广。

步骤 2：绘制数据暴露情况，并梳理代理（agent）可以访问哪些内容

对于每一个发现到的代理（agent），都要记录它能够访问哪些经过身份验证的会话。Netwrix 1Secure Platform 的 Data Security Posture Management（DSPM）能力会持续定位并分类敏感数据，同时将其与拥有访问权限的身份进行关联。当 First National Bank Minnesota 需要重建其 Active Directory 以加强安全性时，先发现并分类敏感的客户数据，使他们能够在原本预计为六个月的项目周期内，仅用三周就完成了。

不确定您的代理实际上能访问什么？ Netwrix 1Secure 映射敏感数据，并将其与具有访问权限的身份相关联。 请求演示 在代理发现漏洞之前。

步骤 3：分析身份与权限继承

在许多企业中，用户、服务账户以及与 OAuth 连接的应用之间已经存在权限蔓延（privilege sprawl）。浏览器代理（agent）会继承这种蔓延，并能够以机器速度加以利用。任何代理部署开始之前，请先记录所需权限状态与实际权限状态之间的差距。

步骤 4：评估供应商的安全态势以及内置控制措施

审查每家代理（agent）供应商的已文档化安全架构：代理可以访问哪些数据、数据在哪里处理、提示与响应如何存储，以及有哪些企业控制措施可用。

步骤 5：定义“允许”“限制”和“禁止”的使用策略

可接受使用（Acceptable use）政策必须明确涵盖：哪些 AI 工具被批准使用、每种工具允许使用哪些数据分级、用户责任、禁止行为以及执行机制。随着新的代理（agent）能力不断发布，政策要求会快速变化。有些组织会在单个季度内多次更新其 AI 可接受使用政策，每次修订都针对由代理更新引入的新边界情况。

如何在不阻止生产力的情况下降低浏览器代理（browser agent）的安全风险

对大多数组织而言，阻止所有浏览器 AI 并不是一种现实的安全态势。以下控制项按照其实施成本相对带来的影响大小排序。

风险分级和最小权限（least privilege）整改是前提条件。其余控制项会在它们所确立的访问卫生（access hygiene）基础上展开。

按风险等级对代理进行分类：已批准（approved）、受限（restricted）或已阻止（blocked）

从四个维度评估每个浏览器代理的使用场景：数据敏感性、对运维的影响、监管暴露（regulatory exposure）以及决策自主性（decision autonomy）。并补充与浏览器相关的因素：凭据访问范围、会话边界（session boundaries）、外部服务集成（external service integrations），以及是否能够监控并撤销代理的操作。

• 低风险（批准）： 仅使用公开数据，不使用企业凭据，标准监控足够。
• 中等风险（限制）： 非敏感的企业数据，需要基于 角色的访问控制，优先采用只读策略，并加强监控和 DLP 覆盖范围，且每季度进行重新认证。
• 高风险（阻止或使用补偿性控制进行治理）： 受监管的数据、认证凭据、生产系统或具备自主决策能力的场景。部署之前必须进行完整的安全评估、持续监控，并开展专门的治理审查。

在代理放大现有暴露之前，强制执行最小权限

如果用户今天携带了过多的权限，浏览器代理将继承其中的每一项，并以机器速度来执行这些权限。在采用代理之前先修复过度分配的访问权限，是目前可用的回报最高的准备行动。

Netwrix Privilege Secure 通过零常驻特权来强制实施按需（just-in-time）的访问控制，这意味着在受管账户下运行的代理不会持有等待被利用的持续高权限访问。每一次特权操作都会在审计追踪中关联到特定身份，从而提供合规框架所要求的取证可视性。

例如，当渗透测试人员反复利用过度配置的管理员账户时，Eastern Carver County Schools 实施了按需（just-in-time）的访问模型，从而消除了常驻权限。对于 IT 资源有限的学区而言，能够在数天而不是数月内实施这种控制级别，对于保护 9,300 名学生的数据至关重要。

使用受管理的浏览器配置文件和扩展允许列表

Microsoft Edge for Business 为工作和个人浏览创建独立的安全上下文，并将三个安全级别映射到用户风险画像。Chrome Enterprise 提供 策略冲突检测 ，当 BYOD 设备上的关键策略显示不合规时，它会自动阻止访问企业应用。

采用默认拒绝（default-deny）策略的扩展允许列表，是在边际成本最低的情况下可获得影响力最大的控制措施。在 Microsoft Edge 中，ExtensionSettings 策略可以默认阻止所有扩展程序，并为每个通过风险评估流程的工具提供明确批准的例外。

应用数据分类和具备 AI 感知能力的 DLP，以遏制敏感数据暴露

传统 DLP 难以跟上 GenAI 的交互模式。Data classification 告知控制措施哪些数据至关重要，是先决条件。

按敏感度级别配置差异化保护：受限数据无论用户角色如何，都不能粘贴到任何外部 AI 工具中；而公开数据则可在不受限制的情况下流转。

Netwrix 1Secure Platform 集成了敏感数据发现与分类，并结合 Identity Threat Detection 与 Netwrix Endpoint Protector's DLP 能力，在混合环境中持续维护敏感度标签，使数据在经由代理工作流流转时能够始终应用保护措施。

Microsoft Edge Protected Clipboard 在剪贴板层面加入基于策略的保护机制，以防止从敏感应用中进行复制/粘贴的数据外传。

检测浏览器与身份活动中的 AI 驱动异常

浏览器代理呈现出与人类用户不同的模式：快速的 API 调用、大量数据访问、非工作时段的活动，以及在短时间窗口内进行跨应用的数据聚合。

Defender for Cloud Apps 通过分析登录事件中的浏览器活动模式来识别威胁。基于身份的异常检测之所以是当今最具技术可行性的机制，是因为代理会与合法用户共享相同的协议、凭据和通信渠道。

用于区分代理活动的行为（速度、广度和时机）是能够identity threat detection基于受治理的身份基线而浮现的信号。

Netwrix 如何帮助你治理浏览器代理的安全风险

浏览器代理位于身份与数据的交汇处。它们使用组织身份进行认证，访问组织数据，并通过现有每一项控制都将其视为合法的通信渠道运行。如果只保护其中一个维度而忽略另一个维度，就会留下代理能够以机器速度加以利用的漏洞。

对于管理以 Microsoft 为主的混合环境的中型组织来说，首要问题并不是该阻止哪种代理（agent）。而是：你是否能够准确地了解你的身份（identities）可以访问什么，以及这些访问权限是否仍然适当。没有这一基线（baseline），对浏览器代理（browser agents）的治理就只能凭猜测。

Netwrix 1Secure 直接解决这一基线（baseline）：Data Security Posture Management（DSPM）会持续定位并对敏感数据进行分类，同时将其与能够访问这些数据的身份（identities）进行关联分析。不过，仅有可视性并不能降低代理（agents）所继承的攻击面（attack surface）。

Netwrix Privilege Secure 通过零常驻权限（zero standing privileges）和按需/及时（just-in-time）的权限提升来消除常驻访问（standing access）。在托管账户（managed accounts）下运行的代理（agents）不会在会话之间持有持续的高权限（persistent elevated permissions）。

Identity Threat Detection & Response 会呈现用于区分由代理（agent）驱动的活动与正常用户模式的行为异常，从而提供现有任何浏览器或网络控制都无法提供的检测层（detection layer）。

请求演示 ，在 agents 放大影响之前，查看 Netwrix 如何在你的环境中映射身份（identity）的暴露与敏感数据的访问。