传统的网络访问控制关心的问题相对简单：这是谁（USER）、用的什么设备（DEVICE）、访问的目的地是哪里（DESTINATION）、用的什么应用（APP）。这套逻辑运行了很多年，能够回答企业网络里绝大多数的可见性需求。
AI应用加入以后多了一层
当企业内部开始大量使用AI Agent完成任务，一次看似简单的操作背后，可能是一条更长的链路：AI Agent接收到任务 → 调用某个模型进行推理 → 通过工具接口（比如MCP协议）连接到具体工具 → 工具进一步访问某个SaaS服务 → 最终读取或写入某份数据。这条链路上的每一环，都可能是网络安全需要关注的对象，但传统的"用户访问了某个网站"这种粒度的记录，完全无法体现这条链路的真实结构。
网络安全需要理解的新问题
面对AI工作流，网络层面需要能够回答：这次访问是谁发起的？是哪一个具体的Agent实例？它正在调用哪个工具？涉及的数据是否允许在这些系统之间流动？多家主流网络安全厂商在近期的产品更新中，都提到了识别AI应用流量、区分不同AI工作负载类型的能力，用来在网络层面获得这类问题的答案，而不再只是笼统地把它当作"一次普通的网络访问"处理。
不是"传统SASE已经失效"
需要澄清的是，这不意味着过去几年建立起来的SASE架构变得没有价值——网络连接优化、基础的访问控制、威胁防护能力仍然是必要的底座。真正发生变化的是"可见性"和"策略"这两个维度：企业需要在原有能力基础上，新增对AI应用流量的识别能力，并针对AI工作流设计相应的数据流动策略，比如限制某个Agent能够访问的工具范围、防止敏感数据被意外传递给外部AI服务。这是在现有架构上的扩展，而不是推倒重来。
对企业的实际意义
如果企业内部已经有员工在使用AI编程助手、AI客服工具或自动化Agent处理业务，那么"网络里有多少流量属于AI应用、这些流量涉及哪些工具和数据"这个问题，值得被纳入日常安全评估的范围，而不是等到出现明显问题才去关注。这也是AI Runtime Firewall和普通防火墙到底差在哪？一文讨论的相关话题——网络层的可见性和应用运行时层的控制，正在成为互补的两个环节。