企业正争相让AI智能体投入工作，却常常跳过每位新员工都要经历的一步：入职流程会明确规定他们可以接触哪些数据、应用和工具。这一缺口让智能体成为一种新型内部威胁。Okta的产品与技术总裁，以及一家在隔离环境中运行智能体的初创公司的联合创始人兼CEO，在解决办法上看法一致：不要再指望靠模型内部的指令约束智能体，而要从模型外部强制执行规则，手段包括隔离的执行环境、与个人身份绑定的权限、意图核查、以隔离终将失效为前提构建的基础设施，以及设在多个层级的紧急关停开关。
未经入职流程就被“录用”的智能体
新员工的入职流程会划定其访问边界，即可以使用哪些数据、应用和工具。智能体却常常完全跳过这一流程。在Okta看来，企业把智能体当作员工对待，甚至视其为人类岗位的替代者，却没有建立与之相配的治理机制。一些部门如今会在同一笔预算里，权衡是购买AI智能体订阅还是招聘新员工。
由于智能体拥有自己的身份和账户连接，风险是双向的：企业既要防止失控的智能体损害自身系统，也要保护智能体自己使用的工具免遭外部攻击。无头浏览器由软件驱动、不显示窗口，一旦没有及时打补丁，攻击者就可能接管智能体的运行环境及其关联账户。
许多企业还急于获取生产力收益，在基本的安全控制到位之前就在AI上大举投入。它们被前沿模型的能力所吸引，往往没有事先理清基本问题：智能体可以访问哪些数据，能使用哪些工具包和应用，边界又在哪里。Okta的产品与技术总裁把当前市场形容为“混乱之地”。
系统提示词不是安全控制手段
这家初创公司的联合创始人在1月底开始打造现在的平台，当时他正经营一家AI原生的营销代理公司。他曾用OpenClaw把前沿AI智能体接入公司各处的系统，起初没有设置任何安全约束。智能体完成了一名全职员工的工作量，创造了巨大价值，但这次实验也暴露出严重的安全漏洞。于是，他着手打造一个既保留实用性、又不牺牲安全性的平台。
他的核心理念是“不要信任AI智能体”。这并不是否定智能体的用处，也不是呼吁停止部署，而是要放弃“指令或提示词能够保证安全行为”这一假设。系统提示词是智能体在执行任何任务前收到的常设指令，仅在其中要求它守规矩是不够的。安全必须来自可验证、并且位于模型训练和上下文之外的强制执行机制。
在实际做法上，他的平台把每个智能体放进一个“盒子”，也就是隔离的沙箱，并有意只开放对特定数据源和外部工具的有限访问。它还避开了一个陷阱：如果每个细小步骤都要人来批准，由此带来的摩擦会抵消自主运行的经济价值。因此，审批只留给工作成果离开公司的那些时刻。
| 无需审批即可进行 | 需等待人工审批 |
|---|---|
| 搜索邮件 | 发送对外邮件 |
| 收集背景资料 | 发布文件 |
| 制作电子表格 | 导出电子表格 |
| 工作流中的中间步骤 | 修改生产数据库 |
身份是最后一道防线
Okta把身份视为最终的安全边界。当智能体代表某位员工行事时，它应当原样继承此人的权限范围，例如其身份令牌和访问授权，且绝不能越权。Okta还会审计和追踪智能体提出的访问声明，以便发现异常，并确认智能体是否行为失当。
控制是分层叠加的。IT、安全和AI部门的负责人为整个公司划定大的边界，员工个人还可以按照只授予任务所需访问权限的最小权限原则，进一步收紧自己所用工具的权限。其基础是确定性的细粒度访问控制，即按工具、按操作设定、每次都给出相同结果的规则。访问每个工具包或执行每项操作意味着什么、涉及哪些数据驻留风险，都要事先定义。随后，运行时检测引擎会在智能体工作过程中做出授权决定，无需人每次介入。这家初创公司还与Okta一起采用了XAA，这是一项用于智能体连接和访问控制的新兴标准。
Okta的这位高管把这种架构比作洋葱：Okta的身份层为整个组织提供纵深防御，而初创公司的平台则紧贴智能体的容器包裹一层隔离。
先申报计划，再逐一核对动作
在确定性规则之上，还有第二层负责核查意图，第一步是让智能体把目标明确写出来。
- 智能体在行动前写出分步计划，例如：查看电子表格、阅读特定邮件、从Jira提取问题单、与GitHub交叉核对，再提交拉取请求。
- 用户审阅并批准该计划。
- 裁判模型是专门评估另一个模型行为的独立模型，它监视智能体的每一个动作，并与已批准的计划进行比对。
- 符合计划的动作自动放行，偏离计划的动作则被拦截。
问题由此从含糊而主观的“这个动作安全吗”，变成了“这个动作与用户批准的内容一致吗”。对于邮件和共享文档这类影响重大的输出，这项核查最为关键。
▲ 计划审批与裁判模型核对动作
按沙箱终会被突破的前提设计基础设施
最小权限不能只停留在用户权限层面，而必须以智能体不可信、沙箱逃逸必然发生为前提，落实到基础设施之中。在真实系统里，容器逃逸和虚拟机（VM）完全逃逸都会发生；最近披露的一个零日漏洞，也就是披露时尚无补丁的缺陷，就曾导致VM完全逃逸。安全团队应当追问，逃逸后的智能体下一步能触及哪里：其他Pod、宿主节点、虚拟私有云（VPC），还是更大范围的云账户。
一个被认为无法从外部利用的缺陷，对于已经身处内部的智能体群来说可能轻而易举。CVE是公开的已知漏洞目录中的条目，智能体群可以把多个低优先级的CVE串联起来，像穿过瑞士奶酪的孔洞一样在系统之间移动。
Okta的这位高管敦促企业重新审视风险登记册，那里往往积压着5到10年被忽视的安全债务。他认为，未打补丁的CVE就是定时炸弹。他描绘了这样一种威胁情景：一个人用一整架Mac mini运行开放权重模型，也就是权重公开发布的AI模型，自主地探测企业网络中的弱点。攻击工具包每六个月就会进化一轮，他认为必须在自动化攻击到来之前清偿这些债务。
先进模型加快了威胁生成和渗透测试的速度，但只有顶尖企业和资金充裕的产品公司才负担得起自动化补丁、全面审计和防御型AI。难以持续打补丁和更新配置的本地部署基础设施，正日益成为沉重的负担。美国中西部的地区医院缺乏技术资源和防御工具，已在持续遭受自动化勒索软件的攻击。
因此，值得重新审视那些关键的控制节点：
- 把内部系统置于VPN之后，这样无论智能体在做什么，IT部门都能立即切断网络访问。
- 对极其敏感的数据流，可以考虑采用数据二极管，即只允许数据单向传输的装置。
- 执行N-1补丁管理，确保系统最多只比最新版本落后一个版本。Okta的这位高管称这是最重要的一项实践，并指出尽管AI工具如今几乎可以即时研究漏洞并构造攻击程序，却几乎没有企业坚持这样的补丁节奏。
只有一个紧急关停开关远远不够
两位高管都认为，紧急关停开关是没有商量余地的必备项。仅有一个关机按钮是不够的，开关需要在不同粒度上发挥作用，尤其是在智能体突破VM、开始探测企业基础设施的时候。
| 层级 | 开关的作用 |
|---|---|
| 身份 | 撤销特定员工的访问权限 |
| 工具 | 实时修改策略，切断某个工具 |
| 网络 | 紧急关停整个VPC |
在本地笔记本电脑的沙箱中运行智能体，可能会带来虚假的安全感，因为真正的企业部署需要纵深防御。这家初创公司的联合创始人警告说，由于智能体未经隔离、散落在员工的笔记本电脑上，大多数企业离建立有效的紧急关停开关还差得很远。
▲ 三个层级的紧急关停开关
一禁了之会把员工推向影子AI
出于善意的首席信息安全官（CISO）常常因为担忧而全面禁止AI智能体。这可能适得其反，催生影子AI，也就是员工未经批准使用的工具。无法接入获批工具的员工，会寻找风险更高的办法来完成正当工作。
在一家大公司，一名想要商业智能仪表盘的员工每周从数据湖中把数万条敏感客户记录导出到电子表格，再上传到网页版Claude。整个过程完全没有经过安全监督。在另一家企业，一次未经授权向Claude上传数据的行为，损害了公司对《萨班斯-奥克斯利法案》（SOX）的合规。即便政策禁止此类传输，不受监控的浏览器上传仍会带来严重的监管风险。
更安全的做法是提供受管控的通道，而不是筑起一堵墙：通过Okta这样的身份提供商提供访问，保留完整的审计日志，并把数据调取限制在任务所需的范围内。
每个智能体都需要一位人类负责人
客户需求正在从辅助单个员工的AI助手，转向由团队运行一组相互协作的智能体。这家初创公司的联合创始人表示，他目前在一个团队中同时运行32个智能体；比起听上去更吓人的“蜂群”，他更喜欢“智能体团队”这个说法。
他的规则是，每个智能体都必须指定一位对其行为负责的人类负责人。人始终处于中心位置，负责设定目标和方向，智能体团队则主要用于在组织内部传递信息。他还认为，下一条扩展定律正在从训练算力和测试时计算（模型作答过程中使用的算力）转向智能体团队的规模，团队规模将从小群体扩大到数十乃至数百个。
Okta也看到了同样的转变。需求已迅速从为单个用户行事的智能体，转向与其他智能体打交道的智能体；企业如今关心的是，自动化系统之间相互交易的智能体商务如何才能安全运转。随着个人智能体大量涌入工作场所，企业希望有工具来管理和保护它们。
智能体投入生产前该做的事
保障智能体安全，关键似乎不在于某一款产品，而在于把隔离、身份、意图核查、基础设施安全维护和分层关停结合起来。安全和IT团队可以从以下几点入手：
- 部署智能体之前，梳理角色权限、数据范围和工具权限。
- 在沙箱中运行智能体，并在模型外部而不是提示词中执行策略。
- 只对离开公司的动作保留人工审批，例如发送邮件或发布文件。
- 让每个智能体只继承其所服务员工的权限，并记录每一次访问。
- 要求智能体申报计划，并用裁判模型逐一核对其动作。
- 假定沙箱会被突破：在Pod、节点、VPC和云账户各层落实最小权限，清理陈旧的CVE，并保持N-1补丁节奏。
- 在身份、工具和网络三个层级设置紧急关停开关。
- 用受管控、有记录的访问取代全面禁令，并为每个智能体指定一位具名的人类负责人。
向大企业销售智能体的开发者面临时间上的难题。安全审查、法务审核和采购流程过去最长需要12个月；尽管企业正努力把这一周期压缩到三到六个月，安全评估仍然不能也不应被跳过。建议是面向客户四到六个月后会遇到的问题来开发，并从第一天起就满足身份提供商集成等企业级要求。智能体能力提升得如此之快，两个月前搭建的架构如今只需一半时间就能重建，因此小步渐进的做法很快就会过时。