当行业把目光都放在「模型会不会失控」时，另一类失控正在企业内网悄悄发生：员工把公司数据 paste 进公共聊天框、让 CLI 智能体跑了一条危险命令、或者借 MCP 把内部系统接给了不该接的服务。F5 在 9 月公布的 Workforce AI Security，瞄准的正是这条「员工侧 AI」的攻击面——而且它刻意不走「给每个智能体都套一个代理」的路线，而是用无代理（agentless）的方式，在意图层做护栏。
员工侧 AI，比模型侧更先「裸奔」
过去的安全产品多围绕「南北向流量」「应用交付」展开，假设流量会经过网关、能被代理拦一道。但员工侧的 AI 工具不守这个规矩：浏览器插件、本地 CLI、IDE 里的编程智能体、以及各种 MCP 连接，往往绕开传统网关，直接在端侧或凭据有效期内活动。等到它真的外发了敏感数据、或改了不该改的配置，传统 DLP 与 SASE 常常后知后觉。F5 这套产品的切入口，就是把这些「散落在各处的员工侧智能体」纳入统一的可观测与管控范围。
增量认知：这类产品的关键判断是——智能体安全的重心正从「模型本身是否安全」转向「智能体的每一次操作意图是否被看见、被约束」。当智能体嵌入日常办公，真正的漏洞不在模型参数，而在它调用的工具、读写的字段、发起的动作。
无代理（agentless）是什么意思
「agentless」是这套方案最该被准确理解的地方。它不是指没有智能体参与，而是指安全产品本身不把自己塞进智能体与工具之间的通信链路里做中间人代理。换言之，它不去接管每一次调用的流量，而是旁路地识别「这次操作背后的意图是什么」——要读哪类数据、要改哪个系统、是否符合既定策略——再据此给出护栏。好处是少了一层性能损耗与单点故障，也避免了「为了安全反而把智能体卡死」的尴尬；代价则是观测深度依赖对各类智能体行为的理解，盲区比居中代理更难完全消除。
覆盖四类「面」，而非一个模型
方案覆盖的是员工使用 AI 的几类典型入口：浏览器里的智能体、命令行（CLI）智能体、编程智能体，以及 MCP 这类让智能体连接外部工具与数据的协议。把它们归到同一张意图护栏下，逻辑在于：无论入口长什么样，风险都来自「意图是否越界」。这比「给每个工具单独配一条规则」更贴近真实使用方式——员工不会按安全产品的分类去用 AI，他们会在一个下午里同时用浏览器、终端和 IDE。
关于「自动调策略」的口径边界
F5 在表述中提到了策略可随使用自动调优的方向，并引用了「约 66% 的组织已允许 AI 自动调整策略配置」一类的行业口径。这里需要划清两条线：其一，这类百分比来自厂商引用的第三方调研，反映的是「组织态度/已授权范围」，不等同于「已经安全」；其二，「自动调策略」是能力方向，具体能自动到什么程度、谁拥有最终审批权、出错如何回滚，以官方正式文档为准。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。把这类数字当趋势信号看，比当验收标准更稳妥。
辩证看：agentless 不是银弹
无代理路线的优势明显：部署轻、对智能体性能影响小、不易成为新瓶颈。但它也有结构性盲区——不居中就意味着对加密流量、端侧本地操作、以及模型「脑子里」的推理过程，可见性天然弱于代理式方案。因此它更像是传统 SASE/DLP 在 AI 时代的补充层，而不是替代层。对已经建了零信任或 DLP 体系的企业，明智做法是把它接进既有策略中枢，而不是另起炉灶。
对做智能体产品的团队，这波动作的启示是：安全正在从「外围网关」下沉到「意图与行为」层面。如果你的产品会让智能体碰企业数据或系统，那么「能否被观测、能否按策略约束」应该成为产品设计的原生能力，而不是上线后的补丁。未来企业采购智能体时，看的可能不只是它能干多少活，还有它「被管得住」的程度。