SASE曾被视为解决方案。
当边界崩溃、工作分散到 SaaS 应用、个人设备和家庭网络时，业界需要一种能够跟随这种变化的架构。
SASE 就是承诺了做到这一点。将网络与安全汇聚到云端，通过集中检查点路由流量，并无论用户身处何处都应用策略。
一段时间内，它运作得还算不错，随后 AI 的出现加速了那些已在形成的结构性局限。
到 2025 年，超过 20,000 家企业购买了 SASE 解决方案。
大多数组织仅部分部署了他们拥有的功能。许可证闲置未用，绕过列表悄然增长，仪表板上策略看似完整，而实际中的漏洞却在扩大。这并不是执行失败或厂商质量问题。这表明 SASE 所设计要解决的问题在架构之下已经发生了变化，闲置功能普遍存在。
在这种复杂性中理解传统 SASE 的适用场景及其不足，对每位评估当前技术栈的从业者都很重要。
绕行成本
传统 SASE 的核心执行模型很直接。
流量被回传到云代理，在那里被拆解和检查，然后转发到目的地。强制执行完全依赖于将会话通过位于远端的集中检查点进行路由。
在设计该架构时，这是合理的。问题不在于它错了，在于它是为一个已不再存在的世界而设计的。
每个通过远端 PoP 路由的会话都要支付你可以称之为“绕行税”的代价。CRM 会话延迟，视频通话卡顿，工单系统停滞。在带宽受限的地区，SaaS 工作流变得不稳定或几近不可用。
用户会立即感受到这一点，并以最可预测的方式做出反应。他们寻找变通方法，转用个人设备，使用未获批准的工具。每一个变通都会悄悄增加攻击面和影子使用，直到出现问题安全团队才很少会意识到。
可靠性问题使情况更复杂。当一个 PoP 性能下降、证书链中断或解密策略更改传播错误时，影响范围很广。通过底特律 PoP 连接的多伦多用户可能会发现其位置被误判、合规状况被错误评估，甚至会因为从未发生的跨境情况而被标记会话。故障切换期间的流量转移可能同时影响成千上万的用户。
在这种模式下，故障是系统性的，而非局部的。
这是从业者以前见过的模式。制造摩擦的安全架构并不能消除它们试图治理的行为，只会将其推入安全可见性更低的通道。这一循环在每一次重大技术浪潮中都会重复：云、移动、SaaS，现在是 AI。默认阻断的安全策略会滋生影子使用，而影子使用总比受治理的使用更难以保障。
可见性缺陷
即便 SASE 按设计正常运行，网络层检测能够看到的内容也存在结构性限制。
网络代理可以告诉你一个文件被上传了。它无法判断什么被复制进 AI 提示、粘贴到网页表单，或在提交前被搬移到不同的 SaaS 租户之间。只有在可解密时它才能看到目的地和有效载荷。它无法捕捉用户在应用内实际做了什么。
这一差距很重要，因为今天敏感数据离开组织的最常见方式并不像网络事件那样显现。自由职业者从 CRM 复制客户数据并粘贴到 LLM。分析师下载了一个财务模型并将其上传到个人云存储。开发者通过 AI 助手推送专有代码以加速冲刺。所有这些操作都不会产生异常的流量模式或触发防火墙警报。它们发生在表示层，应用内部，用户交互的时刻，在工作被创建和使用的过程中。
更何况，这类事件越来越多地通过自治代理发生，这些代理能够调用工具并在企业内采取行动，通常以用户身份操作，在表面上从不显得异常或未获授权。
现代加密技术只会加剧这一差距，而非弥补。TLS 1.3 减少了可用的元数据。证书绑定使得越来越多的应用无法被解密。后量子密码学实现已在主流浏览器中部署，而它们在结构上与“截断检查”（break-and-inspect）架构不兼容。
组织面临一个本不该存在的选择：阻断你无法解密的流量，或接受这个盲点并允许它存在。大多数人选择了盲点，绕行列表也随之增加。
为了保持兼容性而被加入旁路列表的每个应用程序，都是位于安全边界之外的应用程序。
一个需要豁免才能运作的架构并不是在执行策略，而是在回避它。
AI并未摧毁SASE，但暴露了一个缺口
AI并未造成传统 SASE 与之不匹配的架构问题，但它让这种不匹配变得无法忽视。
现代 AI 工作流程在本质上是非线性的。员工将敏感的内部数据粘贴到提示中。AI 代理调用外部工具、访问内部文档，并以机器速度将生成的输出下游传递。这些输出流向报告、代码仓库和对客户的沟通。一个组织的代理队伍很快将以相当于人工 100 倍的规模，使用员工的角色和访问权限进行运作。
所有这些交互都发生在表示层、应用程序上下文内，在建立任何新的网络连接之前。等到流量到达网络时，意图的时刻已经过去。网络代理可以看到会话，但无法看到会话内部正在发生的事情。
传统 SASE 厂商只能按其架构允许的唯一选项回应。要么阻止 AI，要么允许 AI。阻止 AI 的组织会把使用推向个人、无管理的工具，助长影子 AI 并扩大其试图减少的攻击面。允许 AI 而不顾上下文的组织则要承担数据泄露、合规风险，以及对员工发送和接收内容毫无问责。两种做法都既不理想也不可接受。
IBM 2025 年《数据泄露成本报告》发现，63% 的组织缺乏 AI 治理政策。受调查的组织中有 20% 因影子 AI 导致发生泄露，与未涉及影子 AI 的事件相比，额外增加了 20 万到 67 万美元的成本。二元化的执行模型不仅在架构上存在局限，还在主动产生安全团队试图防止的后果。
领先分析师预计，AI 安全能力（包括提示审查和应用控制）将在未来两年成为 SASE 平台决策的关键因素。大多数现有厂商仅止步于基本可见性或二元阻断控制。其架构通常根本不支持更高级的功能。
问题是结构性的
从实践环境中，技术人员会认出一种常见模式。SASE 许可证大量采购后部署停滞，功能启用却从未完全调优，例外列表不断积累。SWG、CASB 和 ZTNA 之间的多重服务链和重叠策略导致故障排查复杂度随时间累积，毫不奇怪，部署周期从数周延长到数月。
组织最终运行的是碎片化的 SASE 堆栈，多套控制台和策略引擎并行运行。仪表板上看起来强制执行已完成，但实际仍存在可见性与防护漏洞。
这并不是组织纪律的失败，而是依赖强制性回传和在提供有意义的覆盖之前需要大量配置的架构所导致的可预见后果。当部署路径如此漫长且复杂时，部分部署就会成为常态，而非例外。
“闲置软件”问题是结构性的，而非操作性的，但它确实对运营产生影响：随着部署停滞、可视性受限，闲置软件成为攻击面的一部分，同时不断消耗有限的安全预算。
当执行移至最后一公里，会发生什么变化
如果风险存在于表示层，即存在于用户或代理在应用内采取的动作中，在数据被创建、复制、上传或发送的那一刻，那么强制执行也必须驻留在那里。不应在意图产生后才落在远端 PoP，而应在工作发生的点位，在数据离开端点之前实施。
这就是将下一代 SASE 与现有 SASE 区分开的架构转变。将强制执行移到最后一公里会同时改变三种结果。
安全性增强是因为可见性差距被填补。复制粘贴动作、提示内容、租户上下文和输出目的地都变得可见。强制执行基于用户实际所做的事情，而不是从数据包元数据推断。Zero Trust 在应用层按用户/代理、按会话、按动作被应用，并且由于现代协议被原生支持，组织不需要使用旁路列表来保持关键应用的运行——每个会话都受到治理。
用户体验得到改善，因为大多数会话直接连接，正如我们所讨论的，当用户体验改善时，安全性不会因此被削弱。不存在必须绕行经过远程代理的情况，也没有因强制 TLS 检查而降低应用性能、或因将流量路由通过检测点而产生的延迟。应用按其设计方式运行。用户不再寻找变通办法，因为他们不再需要。
当安全不再制造摩擦时，受批准工具的采用率会提高，IT 管理例外情况的时间也会减少。
运维变得更简化，因为策略只需定义一次并能始终如一地执行。一个策略引擎。一个审计轨迹。无需在不同控制台之间进行服务串联。无需在 SWG、CASB 和 ZTNA 之间存在产生不一致结果的重叠规则集。原本需要数月的部署被压缩为数天。
Island的解决方式
Island 的方法基于一个简单的架构洞见：执行应在本地进行，尽可能靠近实际操作点，无论该操作发生在浏览器、桌面应用程序还是具有代理能力的 AI 工作流中。
正如我在《企业浏览器的崛起》中所述，企业浏览器代表了一种“内置安全”（Secure-by-Design）的范式转变，不再依赖于以端点或网络为中心的外加式产品。
Island 让组织能够选择“允许”而不是“阻止”，在受控边界内允许个人邮箱、个人 AI 使用和承包商访问，而不是全面封锁并希望影子使用不会出现，但执行方案的范围远不止浏览器。
Island Desktop 在端点上执行本地优先的强制策略，在任何数据离开机器之前就管控代理行为、MCP 和工具调用，以及设备级别的数据和文件移动。
这不仅仅是一个将会话导向云网络以供检查的流量引导机制，尽管在策略要求时也会那样做。端点本身就是执行点。对于桌面应用和非 Web 流量，Island Desktop 在本地应用策略，并且仅在更深入的分析或路由确实能带来价值时，才选择性地将流量引导到 Island 的全球网络。
回传成为备选，而非默认。
Island Desktop 还支持零信任网络访问 (ZTNA)，允许用户直接连接到私有应用和资源，包括私有 MCP 服务器。对于部署依赖内部工具注册表和私有 MCP 基础设施的自主型 AI 架构的组织来说，这是一个重要能力。代理可以通过受管道道达内部资源，而无需将这些资源暴露给公共互联网或依赖传统 VPN 隧道。
对于基于浏览器的工作，策略在 Chromium 内部的 DOM 层在内容渲染之前且在数据离开会话之前本地应用。不进行流量重路由、不进行 TLS 拦截，也不进行破坏式检测。Island 还提供一个浏览器 MCP 服务器，允许 AI 代理通过 Island 访问网页，但代理通过该 MCP 服务器进行的所有操作都受策略约束。
策略阻止的敏感数据并不是简单地被涂黑成一个无法使用的空白，而是被替换为上下文占位符，例如
Island 将其称为“完美数据包”。对于每个会话，都会根据策略选择最有效且最安全的路径。在大多数情况下，执行在本地进行——要么通过 Island Desktop 在终端上执行，要么通过 DOM 级控制在浏览器中执行——数据包直接发送。只有在需要更深入分析或路由确实能带来实际价值时，才会调用云端检测。
完整的 SASE 能力集通过单一平台运行。Zero Trust 网络访问、secure web gateway、DLP、CASB、AI governance、remote browser isolation 和 digital experience monitoring 均在同一策略引擎和单一审计轨迹下统一管理。不存在服务链，不需要在不同执行点重新评估策略，也不需要将流量路由到单独的服务进行检查。
关于 AI governance，Island 在交互发生的节点对 AI 进行治理，无论该交互是在浏览器、桌面应用程序，还是在端点上的代理式工作流中发生。
内容感知检测实时检查提示和上传内容。数据边界定义了组织批准使用的 AI 工具、租户和工作流。工具调用、MCP 访问以及代理与代理之间的通信均被治理并记录，执行在本地应用，而无需往返到云端检查点。
其结果是符合策略的 AI 访问，无需拦截页面、无需影子 AI、也无需在生产力与防护之间做出取舍——而恰恰在这些地方，安全措施最容易造成摩擦。
部署模型与架构同等重要。
Island 提供分阶段方法，起始于对现有 Chrome 或 Edge 浏览器的扩展，不需要更改网络、不需要部署代理、也不需要迁移浏览器，但策略执行会立即开始生效。
组织随后可以迁移到用于 DOM 级别执行的完整企业浏览器，添加用于端点级别和具代理式 AI 治理的 Island Desktop，并拓展到需要集中检测的全球多云网络，每个阶段从第一天起就能提供独立价值。
这很重要，因为如上所述，最可预测的 SASE 失败模式并不是安全漏洞，而是部署从未完成。能够从部署第一天就增量交付价值的架构，根本不同于那种需要数月配置才能开始获得有意义覆盖的架构。
我希望更多安全厂商能采取这种模块化的方法，以避免产品闲置浪费，并真正让安全投入转化为降低组织风险的能力。
从业者应该提出的问题
毫无疑问，SASE 作为一个概念具有价值。SASE 所代表的融合模型——无论用户位于何处，都将网络与安全结合——仍然是正确的战略方向。然而，组织确实需要问一问：鉴于当今的工作方式，他们当前架构所依赖的执行模型是否真的能够兑现这一承诺。
如果你的绕过列表在不断增长，如果你的用户在寻找变通办法，如果你的 AI 治理策略仅仅是在域级别上允许或阻止，如果在购买数月甚至数年后你的部署仍未完成，这些都不是可以通过更多配置来解决的运营问题。这些是表明执行模型需要改变的架构信号。
能够顺利应对这一局面的从业者，是那些会直面令人不舒服问题的人——他们会去追问当前技术栈实际上提供了什么，而不仅仅相信仪表盘显示的内容。二者之间的差距正是实际风险所在，但要发现这些风险，我们必须诚实面对短板，而不是掩饰它们。
原文链接：
https://www.resilientcyber.io/p/the-architecture-problem-sase-cant
声明：本文来自安全喵喵站，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
