渲染层沙箱逃逸与 ChatGPT 锁定模式绕过机理

摘要

2026 年 2 月，ChatGPT 在代码块中加入 HTML 页面预览能力，使模型输出可以以可执行页面的形式在客户端直接呈现；同月，OpenAI 推出锁定模式，通过关闭实时联网、画布联网、文件下载等出站通道，降低提示注入引发数据外泄的风险。同年 11 月，Check Point Research 公开披露该预览功能的容器授权缺陷：外层沙箱保留了允许弹窗以及允许弹窗脱离沙箱的令牌，而脚本层仅以函数覆写的方式对弹窗实施审批拦截；攻击者新建嵌套浏览上下文，取得未被覆写的原生窗口打开方法，即可在沙箱之外渲染任意页面，并使锁定模式的全部通道限制归于无效。该缺陷可造成会话记录与上传文件的静默外传、以应用身份伪装的载荷投递，以及会话状态操纵后的凭据窃取；在基于 Electron 的桌面客户端中，无需任何用户交互即可触发。本文以厂商公开文档与安全厂商披露为事实基准，重建该绕过的技术路径，分析控制面与被控面错配这一结构性成因，评估修复的充分性与残留风险，并从平台、组织与用户三个层面提出防御取向。

关键词：提示注入；锁定模式；沙箱逃逸；数据外泄；浏览器中的浏览器；人工智能助手安全

1 引言

人工智能助手的角色在过去两年发生了实质变化。它不再只是生成文本的对话接口，而是同时承担云端代码执行、客户端内容渲染、外部服务调用与文件读写的复合载体。能力每向前延伸一步，可被攻击者利用的接触面就随之扩大，而安全控制往往滞后于能力的增长速度。2026 年 2 月，OpenAI 在代码块中加入 HTML 页面预览，用户可以直接在对话界面内查看生成的网页、组件与图表；同月 13 日，锁定模式作为可选的高级安全设置上线，先在企业与教育类工作空间提供，6 月起向个人账户与自助式商业账户开放。两者的时间高度重合，一个是纯为便利而增设的渲染能力，一个是为高风险用户增设的出站管控，它们在后来的事件中构成了同一问题的两端。

锁定模式的设计思路并不复杂。提示注入难以从模型层面彻底消除，厂商在公开说明中亦承认这一判断，因此控制的重心从 "让模型不被误导" 转向 "即便模型被误导，数据也出不去"。具体做法是枚举并关闭那些能够把对话内容送出受控网络的能力：实时网页浏览降级为仅访问缓存内容，不再从网络获取图像，画布生成的代码不得发起网络请求，深度研究、智能体模式、实时连接器与文件下载一并停用。这一思路在工程上是可实现的，也是有确定性的，因为被关闭的能力本身是离散的、可列举的。

问题恰恰出在 "可列举" 这三个字。枚举式控制的有效性依赖于一个隐含前提：清单覆盖了所有能够产生外部可观察请求的路径。一旦系统新增了清单之外、却仍然具备出站可能的组件，控制便在未被察觉的情况下失效。2026 年 11 月 5 日，Check Point Research 披露的正是这样一条路径：研究人员 Alexey Bukhteyev 发现，HTML 预览的沙箱配置中保留了允许弹窗的授权，攻击者可以借助嵌套浏览上下文取得浏览器原生的窗口打开方法，从而在沙箱之外渲染任意内容，并使锁定模式的通道限制整体失效。该问题于 9 月 18 日由厂商修复，修复方式是从外层预览沙箱中移除两项弹窗相关令牌，研究人员复测确认利用手法不再有效。

本文关注的不只是这一漏洞本身。一个已经修复的实现缺陷，其技术细节的寿命有限，但它所暴露的控制结构问题具有可迁移性：当策略层以脚本覆写的方式实施拦截，而容器层同时保留了更宽的能力授权时，两层之间缺少一致性约束，拦截就可以被合法的浏览器接口穿越。本文以厂商公开文档界定控制的能力边界与承诺范围，以安全厂商披露还原攻击路径，不进行任何实机复现，也不对未公开的细节作推测。全文按以下次序展开：先建立锁定模式所依赖的通道模型与其自我限定，再剖析预览渲染面的隔离设计与破点位置，随后归纳绕过之后的能力扩张与危害形态，进而讨论控制失效的结构性成因，评估暴露窗口与修复的充分性，文末给出分层的防御取向。

2 锁定模式的控制模型与能力边界

2.1 以通道为中心的外泄结构

理解锁定模式的作用位置，需要先把数据外泄拆成可分离的环节。一次成功的注入式外泄通常包含三段：获取段，模型在被污染的内容影响下，能够读到会话历史、上传文件或已连接数据源中的敏感信息；出站段，这些信息被编码进某种可以被外部观察的载体，例如带查询参数的链接、指向外部主机的图像请求、连接器的写操作、被下载的文件；接收段，攻击者控制的服务器或第三方服务记录并还原这些信息。三段之中，模型层防护主要作用于获取段，试图让模型区分可信与不可信指令；出站段则完全由产品的能力配置决定。

锁定模式的着力点明确落在出站段。厂商文档给出的关闭清单包括实时网页浏览、回复中的网络图像、深度研究、智能体模式、画布联网与文件下载，并说明在锁定模式下浏览仅限缓存内容，因此不会有实时网络请求离开其受控网络。这一表述的技术含义是：出站不再依赖模型的判断，而依赖一组被确定性关闭的通道。对于带参数的链接外传这一经典手法，通道被切断之后，模型即便被说服去构造这样的链接，也没有可用的执行路径。

2.2 官方自我限定所划定的承诺范围

厂商在同一份说明中给出了若干限定，这些限定对评估控制强度而言比功能清单更重要。其一是锁定模式并不阻止注入内容进入模型的处理范围，缓存网页与上传文件中仍然可以藏匿恶意指令，并影响模型的行为与输出准确性；其二是锁定模式旨在显著降低外泄风险，但不能保证外泄绝不发生，风险仍可能来自已启用的应用、未预见的功能组合或新发现的攻击技术；其三是锁定模式不影响记忆、文件上传、对话共享，也不改变对话是否可用于模型改进，并且不影响代码工具的网络访问。

这些限定说明，厂商对控制性质的表述是诚实的：它是一项风险降低措施，而非安全保证。真正值得讨论的是第三个限定中 "未预见的功能组合" 这一项。它把一个开放式的剩余风险写进了产品说明，而本次事件正是这一条款的实例化 —— 预览功能与弹窗授权分别看都不构成问题，两者的组合却产生了完整的逃逸路径。从这个角度说，漏洞不是对文档承诺的违背，而是文档已经预留、但用户侧普遍忽略的那部分风险变成了现实。

2.3 枚举式控制与结构式控制的差别

由此可以提炼出一个分析框架。枚举式控制列举应当关闭的能力，其强度等于清单的覆盖率与执行的一致性之积；结构式控制则不依赖列举，而是通过容器、权限与信任边界的重新划分，使未列举的能力也无法抵达外部。前者易于实施、易于审计，但对新增组件天然迟钝；后者实施成本高，却对未知组合具备一定冗余。锁定模式属于前者，它在通道层面做到了确定性关闭，却没有在渲染与执行层面重建信任边界，因此其有效性被外包给了各个组件的实现质量。

反网络钓鱼技术专家芦笛指出，评估这类 "断通道" 型防护时，清单长度并不构成强度指标，真正决定强度的是清单之外是否还残留能够产生外部请求的执行面；只要存在一个未被枚举的渲染或执行组件，整条链路就可以在该组件内部重新闭合。这一判断为后文的路径分析提供了基本坐标。

3 预览渲染面的隔离设计与破点

3.1 双重嵌套与审批对话框

2026 年 2 月加入的 HTML 页面预览，其风险在设计之初就是明确的：在应用界面内渲染由提示词、定制助手或共享会话带入的 HTML 与 JavaScript，等于把不可信内容放进了受信任外壳之中。若不加约束，最直接的后果有三类：嵌入带会话数据的外部图像地址，形成零点击外传；嵌入指向可执行文件的外部链接，把社会工程诱饵直接摆进应用界面；以新窗口方式打开任意地址，使弹窗被用户误认为应用自身的组成部分。此外，若能读取应用域下的会话凭据与本地存储，还会直接危及账户。

对应的隔离措施是分层的。渲染内容被置于两层嵌套的沙箱框架中，与主应用上下文分离，无法访问父文档、应用界面状态，以及应用域下的凭据与本地存储；页面尝试向外部资源发送数据、加载远程图像与脚本、打开外部地址时，会被拦截并以审批对话框的形式呈现，由用户确认是否放行。从设计意图看，这是一套同时覆盖数据读取与数据出站的方案，且在交互层面保留了必要的可用性。

3.2 容器授权与脚本覆写的双轨控制

破点出现在弹窗这一条路径上，而它的成因是两套控制手段并存却互不约束。

容器层的做法是声明沙箱令牌。外层预览框架的属性中，除了允许脚本执行与同源访问之外，还保留了允许弹窗以及允许弹窗脱离沙箱的令牌。前者意味着容器本身并不禁止页面打开新窗口，后者更进一步允许被打开的窗口不继承沙箱限制。就容器语义而言，弹窗并非被禁止的能力，而是被授权的能力。

脚本层的做法是覆写窗口打开函数。沙箱内的运行脚本将全局窗口打开方法替换为一个需要用户批准的桩函数，当页面请求打开空地址或初始空白页时直接返回空值，用户甚至看不到任何提示。这一层的作用是把 "容器允许" 收缩为 "须经批准"，从表面上看，两层叠加之后弹窗已被有效管控。

问题在于，覆写只作用于被替换的那个对象。页面在自身文档内新建一个嵌套框架后，该框架的窗口对象由浏览器原生创建，其窗口打开方法是引擎实现的一部分，宿主脚本无从改写。调用该原生方法即可得到一个真实窗口，且因容器层已授予脱离沙箱的令牌，该窗口中的内容在沙箱之外执行，不再受预览隔离的任何约束，也不再受锁定模式对出站通道的任何限制。

3.3 控制面与被控面的错配

这一破点的性质需要准确界定。它不是某个参数写错，也不是某次提交遗漏，而是分层安全设计中一种可复现的接口错配：策略层在应用逻辑内实施拦截，容器层在内核语义上授予能力，两者对同一行为给出不同结论，且系统没有对二者做一致性校验。策略层守住了正面入口，容器层却把侧门留在了授权状态；攻击者不需要破解策略，只需要绕到策略未曾覆盖的那个原生接口。

嵌套浏览上下文正是这类接口的典型来源。子上下文的生命周期、原型方法与能力继承由浏览器引擎统一管理，任何在文档层做的函数替换都只能影响当前上下文，无法向下传递。只要容器授予了相应能力，子上下文就能以引擎原生的方式行使它。这与 "覆写即等于禁用" 的直觉相反，也是许多渲染类沙箱在实现中反复出错的根源。

迪妙网络空间安全学院研究团队在梳理同类渲染面隔离问题时注意到一个共性：多数实现把安全假设建立在 "我们替换了危险接口" 之上，却很少验证容器是否仍然授权同一能力；一旦二者不一致，替换就退化为提示，而非控制。该团队认为，渲染面的安全等级应当由容器授权的最小化程度决定，而不是由脚本层的拦截覆盖度决定。

4 绕过之后的能力扩张

4.1 会话内容的静默外传

沙箱之外的窗口具备完整的网络能力，因此最直接的滥用是把会话内容送出。研究人员演示的场景中，恶意定制助手在正常对话过程中把整段会话历史与上传文件传送到第三方服务器，全程没有任何提示。这一结果与锁定模式的目标正面冲突：被关闭的通道确实关闭了，但外泄并未经过那些通道，而是经由一个从未被纳入清单的渲染组件完成。

危害程度在客户端之间存在明显差异。基于 Electron 的桌面客户端中，窗口打开方法不要求用户手势即可生效，因此攻击可以在用户仅进行普通对话的情况下触发，交互门槛为零；浏览器环境中，默认策略通常要求窗口打开由用户操作发起，攻击者需要先构造一个可信的诱饵页面，诱导用户点击一次。同一缺陷在两类运行时呈现不同的利用条件，说明控制的语义必须按运行时分别评估，而不能以产品名称统一表述。

4.2 应用身份冒用与载荷投递

第二个滥用方向利用了窗口外观。被打开的窗口保留应用自身的图标，而标题由页面控制，用户看到的因此是一个外观与应用一致、内容由攻击者决定的窗口。攻击者可以据此布置一个 "应用更新" 提示，把可执行文件伪装成更新包。桌面客户端不允许自动下载，用户需要再点击一次链接；浏览器端不做此限制，自动下载可以直接发生。分发路径的设计进一步放大了风险：攻击者只需共享一个包含恶意页面的会话，接收者即使没有账户，打开共享链接并点击内容也可能中招。共享会话由此从 "只读文本记录" 变成了 "可执行的交付物"。

反网络钓鱼技术专家芦笛强调，此类手法的关键不在技术复杂度，而在信任的视觉转移：当弹窗继承了应用图标、又出现在应用自身的窗口层级中时，用户对来源的判断已经被界面本身代为完成，剩下的只需一句符合情境的话术。这与长期存在的 "浏览器中的浏览器" 欺骗同构，区别只在于承载欺骗的容器从浏览器标签页换成了助手客户端。防御的重心因此不能停在链接黑名单，而应落在窗口归属与来源标示的可验证性上。

4.3 会话状态操纵与凭据窃取

第三个方向超出了数据读取的范围，进入了对应用状态的写入。研究人员发现可以在主应用窗口中重载内容，并以用户身份执行某些操作，例如强制其退出登录。单看这一能力危害有限，但把它放进钓鱼链条中，效果就完全不同：攻击者先令用户登出，再呈现一个由自己控制的登录页面，用户在 "重新登录" 的合理预期下输入凭据，凭据即在攻击者侧被采集。整个过程不需要伪造域名证书，也不需要攻破应用本身，只需要一次状态扰动加一次情境引导。

这一路径提示了一个容易被忽略的事实：渲染面的逃逸不仅影响数据的流出，也影响应用状态与用户操作的可信性。当不可信内容能够在受信任外壳内改变界面状态时，用户对 "当前处于哪个系统、执行的是谁的操作" 的判断就失去了依据，后续的所有安全提示都建立在错误的前提之上。

4.4 三类投递向量的等价性

上述能力通过三条向量抵达受害者：恶意提示词、第三方定制助手、共享会话。三者的技术内核相同，区别在于信任来源。提示词依赖用户主动输入或粘贴，定制助手依赖用户对第三方作者的信任，共享会话依赖用户对分享者的信任。就防御而言，三者应当被同等对待，因为一旦渲染层失守，信任来源的差异并不能阻止外泄发生。就治理而言，三者需要不同的策略：输入侧的内容审查、助手侧的发布审核、共享侧的出口管控。

5 控制失效的结构性成因

5.1 分层执行的不对称

把本次事件放回控制架构中看，失效的根源是执行层次的不对称。策略层运行在应用逻辑之内，只能约束它能够触及的对象；容器层运行在浏览器引擎之内，其授权对所有子上下文一视同仁。当两层对同一能力给出相反结论时，实际生效的是容器层，因为引擎不读取应用逻辑的意图。这不是实现者的疏忽，而是分层设计的固有属性：越靠近底层的授权，越难被上层的策略收回。

由此可以得出一个可操作的判据：任何以函数覆写方式实施的安全控制，都必须同时确认容器未授予同一能力；否则该控制只能降低误触发概率，不能阻止有意绕过。就弹窗而言，正确的组合是覆写与令牌移除同时成立，任一缺失都使控制失效。本次修复选择移除令牌，正是把控制从策略层下移到容器层，使两者结论一致。

5.2 便利性与攻击面的耦合

预览功能的定位是便利：让用户不必离开对话即可查看生成的页面。它并不处理敏感数据，也不调用外部服务，从产品视角看属于低风险增量。但攻击面的计算方式与之不同：一个组件是否危险，取决于它是否处理不可信输入、是否处于受信任上下文、是否具备出站能力。预览同时满足这三条，因此其便利性与风险并不对等。更麻烦的是，这类功能通常以 "渲染" 而非 "执行" 的名义加入，容易在风险评估中被归入展示层，从而错过对容器授权的审查。

这一耦合关系解释了为何此类缺陷反复出现在渲染面而非模型层。模型层的攻防已经形成较为成熟的方法论，而渲染面横跨产品、前端与浏览器安全三个领域，责任边界模糊，授权配置往往由前端实现决定，安全评审难以覆盖到令牌级别的细节。

5.3 确定性承诺的适用边界

锁定模式的表述中使用了 "确定性关闭" 这样的措辞，这一措辞在工程语境中是准确的：被关闭的能力确实确定地不可用。但确定性只覆盖清单之内，清单之外的组件并不因措辞而获得同等保障。官方说明已经把这一层意思写进了限定条款，问题在于用户侧的解读。当一项设置被宣传为面向高风险人群的高级防护时，使用者容易把它理解为 "开启即安全"，进而减少其他层面的审慎，形成安全感的替代效应。

据 DiMiao, CN 分析，这类替代效应在实测中往往比技术缺陷更难处置，因为它不产生可见的告警，只改变人的行为。组织把一项设置写进合规清单之后，一线人员倾向于把敏感数据的处置责任转移给该设置，而设置本身的能力边界并未随之传达。本次事件的公开披露，在一定程度上正是对这种认知落差的修正。

6 暴露窗口、修复方式与残留风险

6.1 时间线与修复的性质

从公开信息可以复原出一条相对清晰的时间线。2026 年 2 月，预览功能上线，锁定模式同期发布并在企业与教育类空间提供，6 月扩展至个人与自助商业账户；9 月 18 日，厂商通知研究方已完成修复，方式是从外层预览沙箱中移除允许弹窗与允许弹窗脱离沙箱两项令牌；研究方复测确认原手法不再有效；11 月 5 日公开披露。按此计算，从功能上线到修复之间约有七个月的暴露窗口，从修复到公开披露之间约有七周的信息差。公开材料未提及通用漏洞编号，也未披露野外利用证据。

修复的性质值得单独评价。它没有新增告警、没有增加审批步骤、没有要求用户改变操作习惯，而是直接收窄了容器授权。这一取向是正确的，因为缺陷位于授权配置而非提示不足；若只增加一次 "是否允许打开窗口" 的确认，攻击者仍可借原生接口绕过，用户则多承受一次无效打扰。把控制下沉到引擎语义层面，使策略与容器结论一致，才消除了绕过所依赖的缝隙。

6.2 修复的充分性与残留面

就这一具体手法而言，移除两项令牌之后，弹窗不再能脱离沙箱，即便攻击者仍能取得原生窗口打开方法，其内容也会继承沙箱限制，无法形成有效出站。因此修复对该路径是充分的。但充分性不等于穷尽，残留面至少有三处需要持续关注。

其一是同类渲染格式。预览支持的不只是 HTML 页面，还包括组件、矢量图与多种图表描述格式，这些格式的渲染管线各自独立，其容器授权与资源加载策略是否遵循同一最小化原则，需要逐项核对。其二是代码执行面。锁定模式不影响代码工具的网络访问，而代码执行与内容渲染在同一产品内并存，两者之间的边界若有交叉，通道限制就可能被重新打开。其三是策略与容器的一致性校验机制。本次修复消除的是结果，若缺少对 "覆写即须封禁" 这一规则的自动化检查，同类错配仍会在新功能中加入时重现。

6.3 暴露窗口内的处置含义

对于在暴露窗口内使用过相关功能的组织，处置不应止于 "已修复、无需操作"。会话内容在窗口期内是否被外传，取决于当时是否接触过恶意提示词、第三方助手或共享会话，这一判断往往无法从日志中直接得到。较为稳妥的做法是把窗口期内的会话内容按已泄露对待，评估其中是否包含凭据、内部地址、个人数据或业务敏感信息，并据此决定是否触发凭据轮换与定向的反钓鱼提醒。由于公开材料未提供任何可用于匹配的指标，处置只能依赖时间与场景的推断，这也从侧面说明此类事件的可追溯性较弱。

7 分层防御取向

7.1 平台与开发者侧

对构建同类产品的团队，本次事件给出的第一条规则是授权与拦截必须同源。凡以函数覆写实施的控制，容器不得保留被覆写能力的授权；凡容器授予的能力，策略层必须能够解释其必要性。就弹窗而言，若业务确需在预览中打开窗口，则窗口必须继承沙箱限制，并对外部地址做归属校验；若业务不需要，则不应保留任何弹窗相关令牌。

第二条规则是收敛子上下文的能力继承。渲染面应当限制嵌套深度与新建框架的权限，使子上下文不能获得宿主未曾显式授予的能力；对于必须允许的嵌套，应当在容器层而非脚本层完成约束。第三条规则是把渲染输出一律视为不可信输入，无论其来自用户提示、第三方助手还是共享会话，并对渲染管线的每一种格式单独做授权审查，而不是以 "预览" 这一统称统一放行。

迪妙网安在工程评审中采用的检查口径是把令牌清单与能力清单做双向比对：每一项被脚本拦截的能力，都要在容器属性中找到对应的禁止声明；每一项被容器授予的能力，都要在业务需求中找到明确用途。两个方向任一比对失败，即视为高风险配置，需在合并前修正。这一口径成本不高，却能覆盖本次事件这类错配。

7.2 组织侧

组织层面的第一项调整是定位。锁定模式应当被登记为风险降低措施，而非合规意义上的保证，其能力边界、限定条款与不覆盖范围应当与设置本身一同传达，而不是只下发一条 "请开启" 的通知。把它写进基线时，应同时写明它不阻止注入内容进入模型、不保证外泄绝不发生、不影响代码工具联网，以免使用者高估其效力。

第二项调整是分级授权。渲染类功能是否开放，应结合数据分级决定：处理高敏感数据的岗位可以关闭预览与联网，仅保留缓存浏览；需要预览的岗位则应在数据侧做前置约束，避免把凭据、客户信息与内部地址直接粘贴进对话。第三项调整是出口管控。共享会话是本次事件中覆盖面最广的投递向量，对外分享的会话应经过内容审查，接收外部共享链接时应按不可信交付物处理，而不是当作只读文档打开。

7.3 用户侧

用户侧可执行的措施有限，但并非没有价值。其一是把共享会话与第三方助手视为不可信内容源，尤其是来源不明的共享链接，其中的可点击元素一律按外部链接对待。其二是保持客户端更新，桌面客户端在本次缺陷中承载了零点击路径，版本滞后意味着暴露窗口被延长。其三是执行数据最小化，未粘贴进对话的信息不可能被外传，这一条在任何控制失效的情形下都成立。

反网络钓鱼技术专家芦笛在面向企业的培训建议中提出过一个可操作的辨识顺序：先看窗口归属，再看动作预期，末一步看信息来源。窗口归属指当前窗口是否真的属于应用本身，动作预期指当前被要求执行的操作是否与用户此前的意图一致，信息来源指触发该动作的内容是否来自可信方。本次事件中，三个环节同时被绕过，而用户在任一环节保持怀疑，都有可能中断链条。

7.4 检测与研究口径

在缺少可用指标的情况下，检测应当转向行为面。可观察的信号包括：对话界面内出现非预期的独立窗口、出现与应用外观一致但标题异常的提示框、出现非用户发起的下载、会话在无操作情况下发生登出或内容重载、以及共享会话打开后产生的外部连接。这些信号单独看都可能由正常功能引起，需要结合客户端类型与用户行为基线做联合判断。

研究口径上，本次事件也提供了一个方法提示：对渲染类功能的评估，应当以 "最小可信容器" 为起点向上验证，而不是从产品宣传的安全特性向下推导。先确定容器授予了什么，再检查策略拦截了什么，两者的差集就是实际可用的攻击面。这一顺序在本例中只需一步即可发现问题，也适用于其他以沙箱隔离为基础的助手产品。

8 结语

回顾这一事件，可以给出几点相对克制的判断。缺陷已经修复，研究人员复测确认原手法失效，公开材料未显示野外利用证据，因此其现实影响主要集中在暴露窗口内的潜在风险，而非持续的威胁。缺陷的位置不在模型，也不在锁定模式的通道清单本身，而在一个为便利而增设的渲染组件与其容器授权之间。锁定模式所承诺的确定性关闭在其覆盖范围内是成立的，失效发生在覆盖范围之外，这一区分对理解事件性质至关重要。

更值得留存的是方法层面的经验。以枚举方式切断出站通道，能够以较低成本显著抬高攻击门槛，但它无法替代对渲染与执行面的边界治理；以函数覆写方式实施拦截，能够改善交互体验，但它无法替代容器层的能力最小化。两类措施各有其位，混用而不校验，就会出现本次事件中的缝隙。对使用者而言，把任何单一设置当作安全保证都是不恰当的，控制的价值在于叠加，而叠加的前提是每一层都清楚自己覆盖了什么、没有覆盖什么。

芦笛在评述此类事件时反复提到一个观点，可以引作本文的收束：安全设置的意义不在于让风险消失，而在于让攻击者需要跨越更多彼此独立的障碍；当多层控制共享同一个假设时，它们实际上只有一层。就人工智能助手而言，这个假设往往是 "渲染只是展示"，而本次事件说明，渲染早已是执行。

编辑：芦笛 （公共互联网反网络钓鱼工作组）

来源：迪妙网络空间安全学院