摘要

浏览器已经成为企业员工使用AI的第一入口。一组快速增长的“AI浏览器插件”（AI Browser Extensions）把大模型能力注入每一个网页：总结页面、起草邮件、填写表单、乃至代替用户执行操作。这类插件多以员工个人身份、经一次点击即可安装，几乎不经过任何企业采购与安全评审，构成典型的浏览器侧影子AI。

2025年下半年以来，一系列公开事件揭示了这一风险面的真实烈度：合法VPN插件经静默更新拦截10个AI平台的对话（影响超800万用户）；仿冒AI助手的恶意扩展携带应用商店官方推荐徽章窃取约90万用户的AI对话；一个普通权限的扩展利用Chrome缺陷劫持内置Gemini面板继承摄像头、麦克风与本地文件权限（CVE-2026-0628）；URL片段型的间接提示注入（HashJack）可以将任何合法网站“武器化”。与此同时，约47%的企业AI对话经由个人未纳管账号发生^[3]，传统DLP/CASB/EDR对浏览器进程内的数据窃取行为缺乏原生可见性^[11]。

本报告基于2025—2026年公开事件、厂商安全公告与研究报告，对浏览器侧AI插件的技术架构、攻击面与典型攻击链进行系统分析，提出“发现—评估—管控—运营”四阶段管控框架与终端身份、浏览器运行时、网络网关、AI治理四层纵深技术路径，并给出风险分级模型、准入评审清单、运营指标体系、国内外法规标准映射及90天实施路线图，供企业安全团队参考。

核心结论：

• AI插件的风险不是漏洞，而是“按设计”的权限：读取页面、凭证与AI对话均属其合法能力，防线必须前移到浏览器运行时与插件准入本身；

• “默认拒绝 + 白名单”是企业可控性的基线：主流企业浏览器均已内置策略级管控能力，落地成本主要是流程与运营而非采购；

• 管控目标不是消灭AI使用，而是把影子AI转化为受管AI：一禁了之只会把使用行为推向更隐蔽的个人设备与未纳管账号；

• 代理化（Agentic）是下一波风险跃迁：插件从“只读助手”演进为“代理执行”，管控框架需要预留行为级管控与提示注入对抗能力。

1研究背景与问题定义

1.1浏览器：AI使用的第一入口与企业数据的“最后一厘米”

浏览器承载了企业越来越多的核心工作：邮件、协作、内部业务系统与云端应用都收敛在同一个浏览器会话中。调查数据显示，99%的企业用户安装有至少一个浏览器扩展，52%的用户安装超过10个^[4]；Akamai的研究则表明，约47.1%的企业AI对话发生在个人、未纳管的账号上^[3]。当员工把“问AI”变成和“搜索”一样的肌肉记忆时，浏览器就成为企业敏感数据流向外部大模型的“最后一厘米”。

这一入口上的管控长期处于空白：SaaS应用有采购评审与CASB盯防，而一个浏览器插件的安装流程不足30秒——员工在应用商店点击“添加”，接受一份很少有人逐条阅读的权限弹窗，插件即获得在其后续访问的每一个页面上持续运行的能力。没有工单、没有变更记录、不会出现在任何资产台账里。CSA在2026年4月的研究笔记中，将AI浏览器插件定义为“影子AI的隐藏攻击面”^[11]。

1.2影子AI在浏览器侧的三种形态

本报告所称“浏览器侧AI插件管控”，覆盖以下三种形态，其中形态一为本报告重点：

• AI功能扩展插件：以浏览器扩展形态存在、调用外部大模型能力的插件，如各类AI侧边栏、写作助手、网页总结与翻译工具、AI代理（Agent）类插件；

• AI网页服务访问：员工经由浏览器直接访问的公开AI对话服务（未纳管账号场景），与插件共享同一出口与部分管控手段；

• AI原生浏览器与内置助手：集成AI助手乃至代理模式的浏览器产品（如内置AI侧边面板、AI代理浏览等），其安全事件亦纳入本章分析以完整刻画威胁演化。

1.3研究范围、方法与术语约定

本报告为厂商中立的公开研究：数据均来自2025—2026年公开披露的安全事件、安全厂商研究报告、浏览器厂商官方文档与法规原文，正文中以上标编号标注来源（见附录B）；无法溯源的数据不予引用，定性评估模型均明确标注“示意”。涉及具体产品与事件时，仅陈述公开事实，不构成对任何厂商的评价或推荐。主要术语约定如下：

表1主要术语约定

2生态规模与风险全景

2.1生态规模：一年增长85%的“无评审软件层”

第三方研究机构Incogni于2026年1月发布的分析显示：在Chrome应用商店中，拥有不少于1,000名用户的AI类扩展已达442个，较上一年同口径的238个增长85%，累计下载量约1.155亿次^[1]。Google官方在2025年5月的文章中亦确认，应用商店已安装扩展中约10%使用了AI^[2]。生态膨胀的另一面是良莠不齐：约52%的AI插件收集至少一种用户数据，29%收集个人身份信息（PII），42%申请了可向任意页面注入脚本的scripting权限^[1]；Akamai 2026年8月的研究进一步发现，所分析的AI插件中约16.3%含已知CVE漏洞，近75%申请高或危权限^[3]。

图1浏览器AI插件生态规模（数据来源见图内标注）

2.2四大风险域

综合公开事件与研究，本报告将浏览器侧AI插件的风险归纳为四个域：数据外泄（R1）、供应链（R2）、对抗操纵（R3）与行为越权（R4）。四类风险的成因、典型手法与影响对象如图2所示，分别对应第4章的典型事件剖析。

图2浏览器侧AI插件四大风险域全景

2.3关键数据洞察

下表汇总本报告引用的关键量化数据及其出处，供读者复核：

表2关键数据汇总与来源

3技术架构与攻击面分析

3.1扩展架构：权限即攻击面

理解管控手段的前提，是理解AI插件的权限模型。以Chromium系扩展架构（Manifest V3）为例（其他主流浏览器的扩展模型与之高度相似）：内容脚本运行在网页内，可读写页面DOM；后台Service Worker负责网络拦截、定时任务与状态存储；弹窗/侧边栏是AI助手与用户交互的界面。上述组件的能力边界由“权限”决定，而权限在安装时一次性授予——用户点击“允许”之后，扩展对页面内容、标签页URL、Cookie乃至剪贴板的访问即是其合法能力。

图3浏览器扩展技术架构：权限即攻击面

这正是第5章所述“传统防御看不见”的结构性原因：数据在浏览器进程内、进入网络栈之前就已被插件读取，随后以一次普通的加密HTTPS出站请求离开终端——无文件落地、无进程异常、目标域名信誉正常。安全团队赖以告警的三类信号在浏览器内全部缺席。

3.2高危权限清单

对照Chrome扩展官方权限文档与Incogni对AI插件的统计^[1]，下表列出AI插件最常见的高危权限及其风险含义。权限清单也是第6章风险分级模型的核心输入：

表3AI插件常见高危权限与风险含义

3.3Manifest V3：缓解了什么，没有解决什么

Chromium自2025年7月（Chrome 139）起全面停止对Manifest V2扩展的支持^[4]。MV3将后台长驻页面改为事件驱动的Service Worker、收紧了可远程托管代码的能力，客观上压缩了“睡眠代理”式驻留与远程投毒的空间。但必须清醒看到MV3的边界：其一，内容脚本对DOM的读写、host_permissions对任意站点的访问仍然合法存在——AI插件赖以工作的能力未变；其二，商店审核与自动扫描未能拦截多起大规模仿冒AI助手的上架^[6]；其三，静默更新机制仍在，合法扩展的“更新投毒”（如2024年12月波及35个扩展、约260万用户的供应链攻击^[25]）依然有效。换言之，MV3降低了某些攻击成本，但没有改变“权限即攻击面”的基本结构，企业侧管控不可缺位。

3.4AI插件区别于传统插件的四个特征

• 对话明文渲染：主流AI对话服务的提示词与回复均以明文渲染于页面DOM，任何具备页面读取权限的扩展都可直接爬取，无需破解任何加密；

• 天然外呼属性：AI插件必然与外部模型API通信，其流量特征（固定域名/API路径/周期性）既可用于检测，也意味着数据出境的常态化；

• 上下文吞噬：为“理解页面”而生的设计使AI助手把整页内容（含不可见文本、URL片段）纳入模型上下文，为间接提示注入创造了载体（见4.5节）；

• 从只读到代理：新一代AI插件开始代替用户执行点击、填表、提交等操作，风险从“数据可见”升级为“行为可控”，评估与管控颗粒度必须随之演进。

4典型事件深度剖析

4.1通用攻击链模型

对2025—2026年多起公开事件的分析显示，恶意或风险AI插件的数据外泄行为可以归纳为六步攻击链：伪装分发→权限获取→内容截取→本地暂存→批量外传→变现利用。该模型综合了Urban VPN与AITOPIA仿冒两起事件的实测行为，如图4所示：

图4AI插件的典型数据外泄攻击链

4.2事件一：合法VPN插件的静默变恶（Urban VPN，2025.07起）

安全厂商Koi Security披露，多款“免费VPN”浏览器插件自2025年7月的某次更新起，向AI对话页面注入自定义JavaScript，重写fetch()与XMLHttpRequest等网络API，在内容加密与渲染之前截获用户与ChatGPT、Claude、Gemini、Microsoft Copilot、Perplexity、DeepSeek、Grok、Meta AI等至少10个平台的对话内容、会话元数据，压缩后回传至运营方控制的分析端点；VPN功能关闭后数据采集依然继续。同一发行商旗下7款姊妹扩展包含近乎相同的代码，Chrome与Edge双商店合计影响超过800万用户，其中主力扩展曾长期携带商店“精选（Featured）”徽章^[5]。该事件说明：合法扩展的“更新投毒”可以让安装时的一切审批失效，安装时点的静态评审必须辅以运行期持续监控。

4.3事件二：携带官方徽章的仿冒AI助手（AITOPIA仿冒，2025.12披露）

OX Security于2025年12月29日报告两个仿冒正规AI侧边栏扩展AITOPIA的恶意插件，合计安装量约90万：其中60万安装量的变体竟持有Chrome商店“精选”徽章。插件在提供正常AI侧边栏功能的同时，利用“读取全部网站内容”权限在用户访问ChatGPT/DeepSeek时直接从DOM爬取完整对话，连同所有标签页URL、会话令牌每30分钟Base64编码批量回传攻击者C2；为提高驻留性，卸载其中一个扩展时会弹出页面诱导安装另一个。研究者特别指出：攻击者滥用AI建站平台托管其隐私政策与基础设施，增加溯源难度；截至披露次日，两个扩展仍在商店可下载^[6]。

4.4事件三：扩展劫持浏览器内置AI面板（CVE-2026-0628，2026.01）

Palo Alto Networks Unit 42研究人员发现并负责任披露了Chrome的WebView标签策略执行缺陷（CVE-2026-0628，CWE-862，CVSSv2基准评分10.0）：一个仅持普通权限的恶意扩展可拦截发往内置Gemini侧边面板的流量并注入脚本，使注入代码在gemini.google.com这一高特权上下文中执行，从而继承面板被授予的系统级能力——在用户无感知的情况下开启摄像头与麦克风、截取任意网站画面、读取本地文件，并向面板内注入伪造的AI回复实施钓鱼。Google已于2026年1月通过Chrome 143.0.7499.192/193修复^[7]。该事件的意义在于揭示了一个新趋势：当浏览器厂商把高权限AI能力内置进浏览器，扩展与内置AI组件之间的信任边界成为新的攻击面^[7]。

4.5事件四：把合法网站武器化的URL片段注入（HashJack，2025.11）

Cato CTRL于2025年11月25日披露的HashJack是首个公开的、可“武器化任意合法网站”的间接提示注入技术：攻击者把恶意指令追加在合法URL的“#”片段之后（片段不会离开浏览器、不进入任何服务器或网络设备日志），当AI浏览器/助手加载该页面并将其纳入模型上下文时，隐藏指令随之生效。研究给出六类攻击场景：回调钓鱼、数据外泄（代理模式）、虚假信息、恶意软件指导、医疗伤害与凭证窃取。三家受影响厂商的处理差异同样值得管理者注意：Microsoft于2025年10月修复，Perplexity于2025年11月按critical处置修复，而Google将同类行为分类为“Won't Fix（预期行为）”^[8]——这意味着企业不能指望上游“原生安全”，必须建设自有缓解层。

4.6事件五：AI浏览器的群体性泄露（BioShocking，2026.06披露）

安全厂商LayerX披露的BioShocking技术可诱导6款AI浏览器/助手产品（含ChatGPT Atlas、Perplexity Comet、Fellou、Genspark、Sigma及某Claude浏览器扩展）泄露已保存密码、会话Cookie与私有令牌：攻击页面以“游戏谜题”重构AI的判断逻辑，弱化其安全约束后诱导其按指令去其他页面复制“关卡代码”，实际触达的是用户登录态。研究者于2025年10月—2026年1月间通报各厂商后才公开，各厂商修复进度不一^[9]。此外，Brave团队2025年10月的研究亦演示了利用截图中不可见指令诱导AI浏览器泄露账户数据等场景^[10]。代理化浏览器的攻击面系统性放大已成行业共识，OpenAI亦公开承认提示注入是“几乎不可能被完全攻克”的长期挑战^[18]，英国国家网络安全中心（NCSC）建议安全团队转向“降低风险与影响”而非追求彻底阻止^[19]。

4.7事件对照与共性归纳

表4典型事件对照（全部为公开披露事件）

共性归纳：其一，商业与个人数据混合流动使AI对话成为高价值目标——源代码、经营策略、PII、会话令牌同框出现^[6]；其二，商店信任信号（下载量、评分、官方徽章）均可被仿冒或失效，不能作为企业准人依据；其三，静态审批在“更新投毒”面前失效，持续监控与快速下架能力不可或缺；其四，攻击重心正从“扩展读数据”向“AI代理执行动作”迁移，管控体系必须前瞻布局。

5传统防御体系的结构性盲区

5.1盲区的技术成因

企业现有三类主力工具在面对浏览器内AI插件威胁时同时失明，其成因各不相同（图5）：EDR观测进程与文件，而扩展行为发生在浏览器进程内，不产生可疑进程树；CASB/DLP观测“出网了什么”，而数据出网时已是一次目标域名信誉正常的加密请求，且结构化规则难以匹配对话式的非结构化文本；更根本的是，数据被读取的时点在进入网络栈之前——所有边界侧观测点都布置在事发之后。Gartner在2025年11月的研究笔记中明确指出：传统DLP无法有效管理生成式AI的数据外泄风险（加密流量、意图盲区、影子AI）^[12]。

图5传统防御栈对浏览器内数据窃取的观测盲区

5.2治理缺口的量化证据

• 可见性缺口：Bitdefender 2026年度评估（1,200名IT与安全专业人员）显示，仅51.8%的组织对授权与未授权AI使用具备完全可见性^[13]；Pentera 2026年对300名美国CISO的调查中，没有任何一位报告完全可见，66%承认可见性有限^[14]；

• 治理缺口：80%的组织遇到过AI代理的风险行为，但仅37%相应调整了安全策略^[16]；70%的企业存在影子AI^[15]；

• 工具缺口：多数组织缺乏针对浏览器AI插件的采购、权限评审与数据处理要求等专门治理政策^[11]。

值得注意的行业动向是：观测点正在向浏览器内迁移。Microsoft在RSAC 2026上发布了运行于Edge for Business浏览器层的内联DLP能力^[23]；企业浏览器（Enterprise Browser）类产品亦将扩展管控与内联数据保护作为核心能力。这从供给侧印证了本报告的判断——浏览器运行时正在成为新的安全控制面。但能力建设不能等待单一路线成熟，第7章给出的四层架构允许企业以现有工具组合先行达标。

6管控框架总体设计

6.1设计原则

• 默认拒绝、白名单放行：未经验证的扩展默认不可安装，将“员工个人采购”变为“企业集中准入”；

• 最小权限与权限偿付：每一项高危权限都必须对应明确的功能必要性，无必要即封禁；

• 纵深冗余：终端、浏览器、网关、治理四层独立生效，任一层失效不致全线失守；

• 可审计可回源：所有策略、放行、拦截与AI交互日志可回溯至人与资产，满足合规取证；

• 业务连续优先：以“分级管控”替代“一刀切封锁”，把安全要求嵌入工作流而非对抗工作流。

6.2四阶段闭环

管控框架由发现、评估、管控、运营四个阶段构成闭环（图6）：先以终端清单、流量测绘与商店画像摸清“到底在用哪些AI插件”；再以统一的风险模型对每个插件定级；继而在技术上落实差异化管控；最后以持续监控、审计回源与季度复审维持有效性。三条支撑线（策略制度、工具平台、组织职责）贯穿始终。

图6浏览器侧AI插件管控框架总体架构

6.3风险分级模型

建议以“数据触达广度 × 业务场景敏感度”为主轴，辅以行为信号与代理能力两个维度，将AI插件划分为三级（图7）。分级结果直接驱动差异化处置（表5）：

图7AI插件风险分级矩阵（定性示意模型）

表5风险分级与差异化处置策略

7管控技术实现路径

7.1四层纵深架构

技术实现上，建议构建终端与身份、浏览器运行时、网络与网关、AI治理与响应四层纵深（图8）。各层能力均为业界通行能力抽象，可由企业现有终端管理、企业浏览器策略、安全网关与SIEM组合实现，不依赖任何特定厂商产品：

图8四层纵深管控技术架构

7.2L1 终端与身份层：企业策略是可控性的基线

主流企业浏览器均提供策略级的扩展管控能力，并可通过GPO、MDM（如Intune）、macOS配置描述文件或浏览器云管理统一下发^[17]。以Chrome企业策略为例（其他浏览器存在同构策略）：

• ExtensionInstallBlocklist 置为 ["*"]：默认拒绝一切扩展安装，仅白名单内可装^[17]；

• ExtensionInstallAllowlist：明确允许的扩展ID清单，与准入评审流程联动^[17]；

• ExtensionInstallForcelist：强制安装安全类扩展（如企业密码管理器、SSO助手），用户不可移除^[17]；

• ExtensionSettings：以单一JSON对象实现细粒度管控，关键字段见表6^[17]；

• DeveloperToolsAvailability=2：禁用开发者工具，封堵加载未打包扩展的旁路^[17]。

表6ExtensionSettings关键字段与管控用法（依据Chrome企业官方文档{{17}}）

值得注意的是同类策略在不同浏览器中的扩展ID互不通用（同一扩展在Chrome与Edge商店ID不同）^[17]，多浏览器环境需要分别维护名单。此外，策略推送后已安装的受限扩展通常在浏览器下次启动时移除，大批量处置前应安排沟通，避免业务中断^[17]。

7.3L2 浏览器运行层

在扩展准入之上，运行时管控解决“允许装的插件不越界”：其一，运行时域封禁（runtime_blocked_hosts）使通用插件永远无法触碰敏感系统^[17]；其二，权限级拦截阻止携带高危权限的扩展运行；其三，具备浏览器内DLP能力的管理型浏览器可对粘贴、上传、表单提交实施内容识别与阻断^[23]——这是把观测点推进到事发时点的关键一步，但通常要求企业统一部署受管浏览器。

7.4L3 网络与网关层

• AI服务指纹：维护主流大模型API域名/路径指纹库与已知恶意C2仿冒域情报（如4.3节事件中的C2域名），对未申报AI服务访问实施测绘、告警与选择性阻断；

• 网关AI-DLP：对经代理的AI交互内容实施敏感检测（需处理TLS卸载的合规前提），覆盖提示词外发与生成内容回传两个方向；

• 局限认知：HashJack类URL片段注入不产生任何网络侧信号^[8]，网关层只能缓解其下游后果（钓鱼、异常外联），不能替代浏览器层与准入管控。

7.5L4 AI治理与响应层

• 企业AI网关：为受批准的AI使用提供统一出口、模型代理与审计回源，把“合规的AI使用”做得比“影子AI”更便捷；

• SIEM联动：将扩展告警（新装高危插件、权限变更、仿冒IOC命中、异常AI外联）回源关联用户与资产，纳入统一检测响应流程^[11]；

• 应急响应预案：确认恶意扩展后的标准动作为——策略全网强制卸载→重置受影响账号会话与凭证→评估数据外泄范围→按监管要求评估报告义务。

7.6提示注入的企业侧缓解

上游厂商普遍将提示注入视为长期挑战：OpenAI以红队、训练与多层栅栏持续加固其代理模式，但同时承认无法“完全攻克”^[18]；NCSC建议转向降低风险与影响^[19]；行业亦在探索架构与策略层的约束^[18]。在此背景下，企业侧可行的缓解组合包括：优先允许“只读型”AI助手进入敏感场景、对代理型能力限定可触达的站点与操作白名单、对高影响操作（发送邮件、支付、外发数据）要求人工确认、以及对AI输出中的链接与指令保持“零信任”处理。

8生命周期管理与持续运营

8.1准入评审

所有拟准入的AI插件应经过结构化评审，评审要点与通过标准如下（可结合CSA建议的供应商数据问题清单使用^[11]）：

表7AI插件准入评审清单

8.2运行时监控与告警场景

表8典型检测场景与响应动作

8.3度量指标（KPI）

表9运营度量指标体系（目标值为建议起点，应按组织成熟度校准）

9合规与标准映射

9.1总览

浏览器AI插件管控并非法外空间的“额外动作”，而是多项现行义务的交集。图10给出管控措施与主要法规/标准的映射总览；需要强调，该映射为通用研究归纳，具体适用性应结合行业、数据类型由法务与合规部门复核：

图10管控措施与主要法规/标准映射

9.2国内法规要点

表10国内法规映射（要点摘录以官方公布文本为准{{21}}{{22}}{{20}}）

9.3国际标准与跨境场景

表11国际标准映射

对于受批准使用的AI插件与AI服务，建议采购/安全团队以四个问题完成数据尽调闭环^[11]：①对话内容在何处处理与存储？②保留多久？③是否用于模型训练、退出机制是什么？④能否签署数据处理协议？无法给出清晰回答的产品不应进入白名单。

10实施路线图与行动建议

10.1三阶段路线图

建议以90天完成前两个阶段，避免“一刀切”封锁引发业务反弹（图9）：先摸清家底并清除已知恶意与高危项（第0—30天）；继而建立分级标准、白名单与运行时管控并试点推广（第30—90天）；随后进入常态化运营（第90天起）。

图9三阶段实施路线图

10.2分角色行动清单

• CISO/安全负责人：将浏览器AI插件纳入风险台账与年度审计；批准分级标准与例外流程；向管理层报告治理缺口与KPI；

• IT/终端管理：落地企业浏览器策略（默认拒绝+白名单+强制安装）；与MDM/GPO集成；维护双商店扩展ID清单；

• 安全运营：建立第8章检测场景规则；AI外联测绘；SIEM回源关联与演练；

• 法务合规：完成表10/表11映射自查；审批DPA模板；明确事件报告口径；

• 采购/业务：新采购含浏览器插件的AI产品时强制引用准入评审；为业务部门提供受管替代方案；

• 全体员工：经申报通道纳管在用AI工具；了解“30秒安装、90万用户受害”的现实案例，建立权限意识。

10.3常见落地陷阱

• 只封不引：仅屏蔽不提供受管替代，把使用推向个人设备与手机热点，可见性反而恶化；

• 名单静态化：白名单一次成型不再复审，错过更新投毒与厂商变更风险；

• 忽略BYOD与非受管浏览器：策略只覆盖受管设备，漏掉最活跃的影子AI人群；

• 把商店徽章当审核：下载量、评分与官方推荐信号在多起事件中失效^[6]，不能替代企业自有评审；

• 低估代理化演进：只按“读不读数据”评估，忽视会“替人操作”的新一代插件。

11趋势展望

11.1从插件到AI浏览器：代理化重塑攻击面

2025年10月以来，主流AI厂商相继推出内置代理模式的浏览器产品；同期安全研究连续演示了截图隐写指令、URL片段注入、游戏化诱导等对代理浏览器的攻击^[9][10]。Wiz研究员提出的“自主性×访问权限”乘积模型指出：代理浏览器同时具备中等自主性与高系统权限，处于风险矩阵的高危区域^[18]。可以预期：企业浏览器策略中的“扩展”对象将扩展为“扩展+内置AI能力”，对AI行为的策略化约束（可访问站点、可执行操作、人工确认阈值）将成为企业浏览器的基础功能。

11.2控制面向浏览器内迁移

Microsoft在RSAC 2026发布的浏览器层内联DLP^[23]、企业浏览器品类的持续升温，以及Cato等厂商对“客户端侧攻击需要客户端侧缓解”的呼吁^[8]，共同指向同一个方向：安全控制面正在从网络边界迁向浏览器运行时。对企业而言，这一趋势降低了“看不见”的焦虑，但也意味着受管浏览器的统一部署将成为数据安全体系的前置工程。

11.3治理与标准的演进

CSA等机构已开始把AI浏览器插件作为独立风险层级提出治理建议^[11]；提示注入“永远无法完全缓解”的共识^[19]正在把行业注意力从“消除”转向“降权与限界”。预计未来2—3年：AI插件的权限与数据流披露将走向标准化；企业AI网关与浏览器策略的联动将成为主流架构；针对代理行为的审计与回源要求将被逐步写入行业监管细则。

12结论

浏览器侧AI插件是影子AI渗透企业最便捷的通道：一年85%的生态扩张、千万级用户的数据窃取事件、以及“按设计”的权限结构，使其成为当前性价比最高的攻击面之一。而它同时又是AI生产力的最短路径——这正是管控难题的本质：不能简单禁止，也放任不起。

本报告给出的答案是结构性的：以“发现—评估—管控—运营”闭环建立组织能力，以四层纵深弥合传统防御的观测盲区，以风险分级平衡安全与业务，以生命周期运营对抗“更新投毒”式的动态威胁。技术上，企业浏览器策略已提供默认拒绝与白名单的全部必要开关；短板不在工具，而在把插件当作受管IT资产对待的治理决心。

对企业的最小行动建议：今天就可以完成三件事——清点终端上的AI插件并与恶意IOC比对；把企业浏览器的扩展策略从“不设限”改为“默认拒绝+白名单”；发布一页纸的员工AI插件使用规范。这三步不需要新采购，却可以直接封堵本报告中绝大多数已披露的攻击路径。

附录A术语表

附录B引用与来源

正文中上标编号对应下列来源。标注“转引”者为可公开访问的报道或汇总页面，原始研究以所附链接为准；法规条款均以官方公布文本为准。

—— 报告完 ——