从「它有权做什么」到「这一步该不该做」
智能体治理在过去一年有了相对固定的一套动作：给智能体发身份、配权限、记录行为、出事能追溯。这套动作回答的是「它有权做什么」。
但当智能体开始直接调用工具、改写配置、删除数据之后，这套答案开始露出缺口。权限配好之后仍然会出事，是因为「有权做」和「在当前任务与业务环境下该做」是两件事。攻击者的做法通常也不是越权，而是让一个有权限的智能体，在一个不该用权的场景里用权。要拦住这类情况，控制点必须从「事后可查」挪到「执行前可判」。
2026 年 9 月中旬的一批产品与架构发布，恰好集中在这个位置。
Netskope：九类意图，按智能体类型分策
Netskope 在 9 月 15 日公布 Skylight Agent Action Control，同时把其 AI 安全产品线统一更名为 Netskope Skylight AI Security。
这套能力的做法是在动作执行之前评估它。它把智能体尝试执行的动作归入九类基于意图的类别：访问控制变更、配置变更、凭据与密钥操作、数据销毁、基础设施开通、潜在数据外泄、潜在外部通信、远程代码执行、源码变更。分类之后给出风险等级，再由安全团队定义该动作是阻断、放行还是告警。
两处设计细节值得留意。其一，策略档案可以绑定到特定类型的智能体，让编码智能体和对话型智能体适用不同规则——这承认了不同形态的智能体风险结构并不相同。其二，强制点落在其平台已经在检查的流量上，具体是经下一代安全 Web 网关处理的 API 流量，以及经 Agentic Broker 处理的 MCP 流量，不需要另建管理台或端点代理。这套架构也直接决定了部署评估的关键问题：流量路径、API 路由与智能体到工具的连通方式。
厂商给出的示例是：编码智能体尝试删除生产仓库，被判定为关键风险的数据销毁动作，在请求抵达仓库之前即被拦截。这是说明性场景，不是独立报告的客户事件，读者不应当把它当成已发生的案例。
国内路径：把智能体当员工管
国内厂商的表述更接近组织管理学。在近期的行业活动上，有安全厂商把这套工作概括为数字员工的治理与防护旅程：像管理员工一样治理智能体，把准入评估、身份确权、权限管理、内容防护、行为监测与溯源处置贯穿其工作过程。
其中两个环节对当下的企业最有参考价值。
一是上线前的智能体风险评估。做法是用自动化红队测试，在多轮交互中模拟攻击与诱导，观察智能体是否偏离预定任务、风险在什么条件下被触发，同时检查其挂载的技能等组件，识别危险执行、异常外联与敏感数据外泄的可能，形成可定位、可解释、可复现的证据，供上线或整改决策使用。这里的要求不是「有没有问题」的结论，而是「证据能不能复现」。
二是统一的智能体标识。把创建者、所属部门、任务类型、工具清单与安全属性关联起来，让每个智能体实例都能对应到具体责任人，授权、行为分析与审计追溯因此有据可查。这一步解决的是责任归属，而责任归属是分类分级能够落地的前提。
在此基础上再做分类分级：结合业务角色、实际能力、自主程度、数据敏感度与影响范围，确定与风险相匹配的管控要求。修改生产配置、接触敏感数据、输出高影响建议，各自适用不同强度的约束。这套思路的核心判断可以概括为一句话：权限回答了它有权做什么，业务安全还要回答在当前任务与业务环境中，这一步该不该做。
开源侧的第三种做法：把决策和执行拆开
同一时间，工程社区给出了一个形态不同的方案：不让模型自己的指令成为安全原语。
具体做法是把授权边界放在智能体的推理之外。智能体只负责提出动作，系统先捕获不可变的意图，再由独立策略层给出允许、升级、阻断三档裁决，只有被批准的动作才交给受信任的执行器去跑。配套的另一条思路是用能力安全模型构造运行环境，把每个组件放进隔离的能力胶囊，只授予它需要的文件、网络、进程与工具权限，运行时的授权凭签名授予，而不是相信智能体的自我陈述。
这套方案的定位是参考实现而不是已部署的标准，也没有公开的具体事故报告作为验证。但它与产品化方案形成了互补：Netskope 这类产品在网络层做意图分类与拦截，参考架构在应用层做决策与执行的分离。两者共享同一个前提判断——不要相信模型的话，要相信确定性的基础设施。
三种做法的共同盲区
把三条线放在一起，能看到几个共同的薄弱处。
其一，覆盖取决于可见性。在线控制管不到不经它流转的流量，无论是 MCP 直连、内网调用还是员工本地跑的智能体。落地评估中，流量路径与工具连通方式是决定效力的变量，而不是附加题。
其二，分类的准确率本身就是风险。九类意图也好，政策裁决也好，都需要在误报与漏报之间取舍。评估时必须包含受控的失败用例：非预期的配置变更、过度使用权限、批量删除、密钥轮换、外发数据传输与远程代码请求。同时要确认误报如何处理、是否有应急覆盖开关、被拦截的尝试怎么记录、谁来负责策略调优。
其三，能力识别与行为判定之间存在缝隙。一个动作在类别上属于配置变更，但它在当前业务流程里是否合理，取决于系统无法完整掌握的业务上下文。这也是当前方案普遍需要保留人工确认环节的原因。
结语
这批动作合起来说明一件事：Agent 治理的重心正在从身份与权限的静态配置，转向动作执行前的动态判定。这个转向的技术含义是，治理能力要长在流量路径和工具调用链上，而不是长在管理台里。对企业来说，随之而来的是一张更具体的清单：先弄清智能体能发起哪些动作、用哪些凭据、高影响变更的审批边界在哪、每个请求走哪条路——答不出这四个问题，任何控制都无从配置。