北京
过去这些年，把流量引导到云代理上做检查，这套方法一直够用。但情况变了。先是工作负载大规模迁移到了浏览器里，随后人工智能开始渗透进日常工作流——原本靠解密流量来发现问题的那套检测模型，突然就跟不上了节奏。
现在企业的日常工作流散落在各个角落：软件即服务应用、浏览器、还有不断膨胀的生成式AI工具、未经审批的浏览器扩展、自主运行的AI代理。员工们习惯性地把内部知识产权代码贴进公共大语言模型里做优化，自动化代理则以机器速度查询内部文档、跨系统搬运数据。这里的问题不是安全访问服务边缘（SASE）失败了，而是数据交互的层面已经转移到了表示层——一个以网络为中心的架构从来就没设计过去观察的地方。
传统SASE的运作逻辑是把流量回传到云代理上，在那儿完成解密、检查和策略执行。但现代互联网协议，尤其是TLS 1.3、HTTP/3和证书锁定，设计初衷就是明确阻止这类中间人拦截行为。云代理试图对启用了证书锁定的TLS 1.3会话强制解密时，客户端应用通常会直接断开连接。网络团队为了保证关键业务不中断，只能编写绕过例外规则。这就形成了一个结构性问题：企业最终维护着庞大的豁免清单，为了维持工具正常运转，一个应用接一个应用地悄悄缩小安全边界。
除了安全上的缺口，这套模型还给员工带来了沉重的性能损失。把会话强行导到远处的云检查节点，等于给应用延迟和视频会议的卡顿加了一道“绕路税”。当安全基础设施让关键工具变慢、不稳定时，用户自然会寻找影子替代方案来保持工作效率，结果反而扩大了IT团队本想保护的那个攻击面。
AI和自主代理工作流的出现，让这个架构缺陷变得无法忽视。传统网络代理想看的是一个有效的、加密的HTTPS连接到某个大模型服务商。它看不到载荷里的意图，比如一个自主AI代理正在通过模型上下文协议工具调用，把专有代码或内部文档往外拉。数据到达网络检查点的那一刻，交互早都发生完了，风险的“意图时刻”已经过去了。这让安全团队陷入一个非此即彼的困境：要么彻底封禁AI，把用户推向影子IT；要么完全不设限，接受数据完全看不见的状态。
架构层面的转变方向很清楚：要管控AI和现代SaaS应用，执行必须发生在交互的原点，也就是设备本身——浏览器和端点。当确实需要网络层面的安全或路由时，流量必须被动态引导到最近可用的边缘基础设施上。不再是把所有东西拖回中心化的云代理，而是让安全判断尽可能靠近用户操作的位置发生。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
