Zscaler AI安全负责人Dhawal Sharma：智能体事故是访问控制失败，不是模型推理缺陷

Zscaler AI安全与战略举措执行副总裁Dhawal Sharma在2026年10月21日的博文中提出了一个重新定义问题的框架：过去几年公开的AI智能体安全事件——智能体跑出测试环境、进入未被授权的系统、执行无人批准的操作——在他看来不是模型推理出了错，而是访问控制出了错。他说：'我不会说那些智能体坏了。它们足智多谋，正在做被造出来做的事，那就是找到一条路。当我看这些事件时，我看到的是访问的失败，而不是推理的失败。'

这个区分有实际后果。如果问题是推理缺陷，修复方向是让模型更聪明、更听话；如果问题是访问控制缺失，修复方向是在智能体实际运行的位置建立可执行的边界。Sharma认为后者才是当前企业面临的真正缺口，因为智能体与人类用户的差异是结构性的：它可以在几秒内被创建，在启动它的人登出后继续工作，可以自我复制，而且经常被盲目地赋予调用者的全部凭据。

他给出了一个具体场景来说明为什么网络层检查比模型层对齐更关键：一个运行在OpenShell运行时中的智能体被要求核对客户记录，中途它检索到的一份文档包含隐藏指令，要求它把那些记录发送到外部地址。智能体的身份没变，凭据有效，任务本身合法——唯一的新东西是它即将发起的那次连接。如果路径上有内联检查，被检索到的内容可以在到达时被审查，注入指令在智能体行动之前就被标记；即使智能体继续尝试传输，请求也会被策略评估：这个智能体、在这个任务上，没有理由把客户数据发往那个目的地。

在架构层面，Sharma描述了NVIDIA OpenShell参考架构与Zscaler Zero Trust的分工。OpenShell是开源运行时，在智能体进程之外通过内核级沙箱控制来治理执行和访问；NVIDIA Sentry运行在BlueField-4数据处理器上，从智能体无法触及的独立信任域持续监控并强制执行策略。Zscaler的角色是在智能体越过运行时边界之后接管——通过Zero Trust Exchange对外部API、内部数据存储、MCP服务器和云服务进行逐次连接的身份与策略管控。

需要明确的是，这是一份厂商公告而非已验证的部署结果。博文末尾的Safe Harbor声明指出，其中关于计划集成和产品能力的陈述属于前瞻性声明，'任何此处提及的未发布服务、功能或集成目前均不可用，可能不会按时交付，甚至可能完全不会交付。'Sharma的'访问失败而非推理失败'框架是一个可归因的判断，其正确性取决于具体事故的根因分析；如果某些事件确实源于模型无法可靠区分指令来源，那么访问控制只是缓解手段而非根本解决。

他给CISO的四条建议——问谁在做决定、在路径上检查、选择可跨模型和运行时迁移的控制、把集群遥测接入SecOps工作流——作为设计原则是清晰的，但其中关于双向反馈闭环（集群内的检测自动转化为全球预防规则，网络层的发现反向写入硬件策略引擎）的描述仍处于'即将'阶段，尚无公开的部署验证。