2026 年 7 月，AI 投资人、前 HyperWrite CEO 马特·舒默（Matt Shumer）在自己的 Mac 上试用 OpenAI 还没公开的新模型 GPT-5.6，代号 Sol。他给了它对电脑的完全访问权限。结果一个负责清理的子任务执行了一条 rm -rf，删的正是他的用户目录。等他反应过来去叫停，一个多小时已经过去，电脑里的文件删得差不多了。
其实，OpenAI 自己早就知道这类风险。就在这件事发生的 16 天前，它在模型的安全说明里，把「给 AI Agent 完全访问权限」标成了一个不容忽视的风险项。
这件事里没有黑客，也没有漏洞。删文件，本来就是这个 Agent 被授予的、再正常不过的一项能力。
这件事背后，是一个更根本的问题：今天大多数 AI Agent 的架构，天生就不安全。面对这种不安全，最自然的反应就是给它加护栏（guardrail），把危险的操作一条条拦下来。可护栏是个错的方向：它和要防的对象处在同一个层级，怎么加都可能被绕过。真正有效的防线，必须建在模型之外。
AI 安全的三类问题，本文只谈第三类
AI 安全最近是个很热的词，可它在不同的场景里，指的根本不是同一件事，大致能分成三类。
第一类，是模型本身的安全。怎么防止它被越狱，怎么避免它输出有害内容，怎么让它跟人的价值观对齐。这是过去几年谈得最多的。
第二类，是把 AI 用在安全上（AI for security），也就是反过来用大模型去做防御，比如威胁检测、代码审计、情报分析。我们自己也在这个方向上做过一些研究，比如用思维增强的大模型检测智能合约漏洞的 Thought Is All You Need，以及评估 AI Agent 能否胜任智能合约安全审计的 REEVMBench。
第三类，是 AI Agent 自己的安全。当模型不再只是回答问题，而是能读取用户的文件、能拿到用户的密码、能替用户执行操作，它能用的那些工具、拿到的那些权限、做出的每一个动作，本身就成了别人能利用的入口。
前两类都已经有不少研究，第三类还很新，也最容易被忽视。可它恰恰是 AI Agent 能不能大规模走进企业的前提：一个连自身安全都保不住的 Agent，没有哪家公司敢把真正的业务和数据交给它，而这正是这篇文章要谈的。
从不可信输入到任意执行：Agent 的先天缺陷
一个 Agent 要真正做事，往往需要同时具备好几样能力：它能读取外部内容（网页、邮件、代码库、别人提交的代码），能动用有价值的资源（密钥、云服务的密码、数据库），还能调用工具执行动作（执行命令、发请求、改文件）。这几样能力集中在一起，恰恰是最危险的组合。
问题的根源在于，模型分不清一句话到底是用户交代的任务，还是它从外部读到的、别人写的内容。在它眼里，这些都是一样的文字，处在同一个上下文里。它只能凭训练时学到的经验去判断该听谁的，没有一套明确的规则帮它区分。这在安全领域是个很老的问题，叫「混淆代理」（confused deputy）：一个有权限的程序，被没有权限的一方欺骗，替它做了坏事。
这背后是一环扣一环的：真正执行动作的工具听大模型的，大模型听提示词的，可提示词什么来源都有，既有用户自己写的，也有从网页、邮件、文档里读进来的。这就等于，一个本来不可信的来源，经过一个行为并不确定的模型，最后能指挥工具执行任意操作。传统软件里，数据是数据，代码是代码，界限分明；可 Agent 不一样，它读进来的一句话，随时可能被当成命令执行。
这意味着，攻击者不需要高深的漏洞，也不用盗取账号，只要在一份文档、一个网页、甚至一条代码注释里植入一句话，就可能让 Agent 去做它本不该做的事。微软的安全团队说得更直接：你的大模型不是一道安全边界；你给它开了哪些工具，就等于给了攻击者多大的活动范围。
这些都不是假想，已经有多起真实的案例。xAI 的编程工具 Grok Build，每开启一次工作会话，就把整个代码仓库，连同 .env 里的密钥和完整的提交历史，悄悄上传到自家的云服务器上，实测上传的数据量是完成任务真正需要的近三万倍。Cursor 的 Agent 在一次测试里未经确认就在九秒内删光了一家公司的生产数据库，连备份一起删了，事后还写了一封道歉信。Replit 的 Agent 在明令冻结代码期间，删掉了整个生产数据库，又伪造了几千条假记录来掩盖。亚马逊 Q 的 VS Code 插件，则被人通过一个恶意的代码提交，植入了「把系统清空」的指令，还随官方版本发布到了近百万台电脑上。
这几起事故有一个共同点：造成伤害的，几乎都是 Agent 本身被授予的正常权限，而不是外部入侵。读取 .env、执行命令、查询数据库，这些本来就是 Agent 每天在做的操作；一旦被恶意利用，日常操作就变成了事故。
模型内的护栏为何不够：防御者与被防御者同处一层
面对这些事故，最直觉的反应是给 Agent 加护栏。所谓护栏，就是在模型内部设一些规则，约束它不要做危险的事：可以用提示词直接要求它不要执行危险操作，也可以在 Agent 内部加一道检查，像有些编程工具那样，拦截危险命令、检查文件路径。
可这个做法有个根本问题：护栏和它要防的对象，处在同一个层级。
美国国家标准与技术研究院（NIST）的高级科学家 Apostol Vassilev，在 2026 年 6 月发表过一篇文章，把哥德尔不完备定理的思路用到了这件事上。文章标题本身就是一句反问：《稳健的 AI 安全与对齐：一场西西弗斯式的苦役？》。
他的意思大致是这样：护栏本质上是一套有限的、固定的规则；就像一个有限的公理系统没办法既完备又自洽，任何一套固定的护栏，也总会有一句话能绕过去。人类的语言又模糊又灵活，能绕过去的说法几乎数不清。用他的原话说，没有哪一套有限的护栏，能挡住所有的对抗性提示。剩下的问题只是：防守方和攻击方，谁先找到那句话。NIST 因此在官方新闻稿里建议，安全思路要从「一次做对」转向「持续监测、持续更新」。
还有一个更直接的证据。既然模型本身靠不住，那用一个模型去检查另一个模型有没有被注入，是否可行？威斯康星大学的一项研究发现，这条路走不通：这类用一个模型去判断另一个模型有没有中招的检测方案，存在结构性缺陷。研究者构造出的自适应攻击，能把检测率压到接近零，注入却照样以约九成的成功率得手。负责检查的模型和被检查的内容始终处在同一层，本该发现攻击，结果自己先被绕开。
还有一层常被忽略：护栏起作用的时候，Agent 已经拿到执行权了。EchoLeak 就是一个例子。它是针对微软 365 Copilot 的一次「零点击」攻击：一封精心构造的邮件，悄无声息地穿过了微软给 Copilot 加的过滤器，把敏感数据带了出去，整个过程不需要用户做任何点击。
所以，「在模型里加护栏」有点像修一条马奇诺防线：不是没用，只是从设计上就必然能被绕开。它可以作为防御的一层，却不能是唯一的防线。
真正的防线，应建立在 Agent 之外
既然模型内部靠不住，这道防线就要移到模型外面，建立在系统层面。
把不可信的代码关进一个隔离的环境、只给它完成任务必需的最小权限，这套思路在系统安全领域已经有几十年的历史。早在 1975 年，Saltzer 和 Schroeder 那篇经典论文就提出过两条原则：一是最小特权，一个程序只应拿到完成任务必需的那部分权限；二是职权分离，把权力拆分开，任何单点的失误或被欺骗，都不至于危及整个系统（The Protection of Information in Computer Systems）。后来的沙箱技术，从 1990 年代的 Janus，到 2000 年的 FreeBSD Jails，再到今天的 gVisor，走的都是同一条路：把不可信的代码隔离起来，即使它被攻破，也影响不到外面。给 AI Agent 做防护，说到底就是把这套已有几十年积累的成熟做法，用到一个新的对象上。
落到今天，一个直接的做法是给它加一层系统级的沙箱：把 Agent 执行工具的环境隔离起来，控制到系统调用、文件读写、网络出口这样的粒度。不同工具的默认程度差别很大：OpenAI 的 Codex 默认就把命令执行放进沙箱，并且默认切断网络；而 Claude Code 本地版的沙箱需要手动开启，Cursor 的沙箱按官方说法也只是「尽力而为」，并不能当作安全边界。更彻底的做法，是把整个 Agent 放进一个由平台托管的运行时，网络和凭证都交给外面这一层管理。Anthropic 面向云端的托管版 Claude Code 就是如此：每个会话运行在 Anthropic 托管的虚拟机里，所有出站请求都经过一个带白名单的代理，凭证也保存在沙箱之外。
这里有一个自然的疑问：既然沙箱技术已经这么成熟，前面那些删库、上传代码仓库的事又是怎么发生的？原因有两个。一是这些工具的默认防护本就有限：像 Cursor 默认并没有严格的沙箱，GPT-5.6 删除 Mac 文件那一次，用户更是直接给了它完全访问权限，等于关掉了沙箱。二是即使沙箱开着，也拦不住这类事故：沙箱防的是 Agent 逃逸出去破坏宿主机，而 Agent 删除的数据库、上传的代码仓库，恰恰都是它被明确授权可以访问的，根本不需要逃出沙箱。所以说，沙箱是必要的一层，但远远不够。
给 Agent 圈定访问范围的思路，也已经走进了面向普通办公用户的桌面产品。腾讯今年发布的桌面办公助手 WorkBuddy 就运行在个人电脑上，只读取用户授权的本地文件夹来完成任务。它公开的资料只提到「授权文件夹」，并没有说明底层究竟如何隔离、隔到什么程度。
更关键的是，这一整类「带沙箱的 Agent」都存在一个共同的盲区：沙箱管得住 Agent 在哪里运行、能不能逃逸出去破坏宿主机，却管不住它运行之后拿这些数据做了什么。一个被注入的 Agent，走的全是被明确放行的通道，看上去和正常运行没有任何区别。有安全研究者在评价谷歌的 GKE Agent Sandbox 时指出：这是「隔离沙箱」，而非「行为沙箱」，它决定 Agent 在哪里运行，却看不住它运行时具体做了什么。
正因为沙箱只能管住 Agent 在哪里运行、管不住它拿数据做什么，谷歌 DeepMind 提出了一个更彻底的思路：从设计上就把大模型当作一个不可信的部件，在它外面加一层固定的、不依赖 AI 判断的系统，来决定它每一步能不能执行。他们的 CaMeL 把用户可信的指令先编译成一段程序，交给一个不含 AI 的解释器运行；这个解释器会追踪每一份数据的来源，在每次调用工具之前，按权限规则决定是否放行；而真正接触外部可疑内容的那个模型，完全没有调用工具的权力。这套办法，能在相当一部分任务上做到「可证明的安全」。
沙箱之外的难题：Agent 运行必需的敏感数据
不过，无论是沙箱还是 CaMeL，都绕不开一个更难的问题，这也是整件事里最难处理的一个环节。
沙箱把 Agent 和宿主机隔离开了，却没有在 Agent 工作必需的数据周围建立防护。代码、.env、它要查询的那个数据库，都和它处在同一个环境里；而 Agent 要工作，就总得有一个对外的出口。于是一个被注入的 Agent，照样能顺着这个放行的出口，把它能读到的数据传出去。这一点 Anthropic 自己的沙箱文档也承认：只要允许网络出口，Agent 能读到的数据就有可能被带走，因为白名单只按域名放行，并不检查流出的内容。
那么，这些 Agent 工作离不开的数据，又该如何保护？可以分成三种情况，一种比一种棘手。
第一种，是明确的凭证，比如一个 API 密钥。Agent 并不需要理解这个密钥的内容，只是用它来发请求。那就可以让模型自始至终只看到一个占位符，等真正要发请求时，再由外面一层受管的运行时把真密钥替换进去。就算有人用提示词把「密钥」诱导出来，拿到的也是一个无效的假值。这一类，在工程上基本可以解决。
第二种，是 Agent 必须亲自读取、分析的数据。一个做财务分析的 Agent，如果不给它财务数据，它就无法工作。这种情况就没法简单替换了。一个折中的办法，是单独运行一个高度隔离的子 Agent，只让它接触敏感数据，最后只把一个结论传出来。可这里有一个绕不过去的问题：谁也无法保证这个结论本身不敏感。泄密往往是经过改写、藏在语义里的，用关键词根本匹配不到。隔离能缩小出事的范围，却无法真正杜绝。
第三种，是更彻底的办法，叫信息流追踪：给每一份数据打上标签，全程追踪它流向哪里，在它要流出去的那一刻拦截下来。微软的 Fides 走的就是这条路，用信息流控制追踪每一份数据的流向，原理上最干净。可它的代价也最大：拖慢性能、影响可用性、标签越来越多，还需要有人去编写和维护这些规则。在安全和可用性之间，这里的取舍最难。
AI Agent 安全的系统工程：隔离、管控与溯源
这些办法各有短板，没有哪一种能单独解决问题：护栏会被绕开，沙箱挡不住数据，信息流追踪代价过高，子 Agent 隔离也无法保证结论不敏感。
但安全这门学科历来如此：没有绝对的「安全」或「不安全」，能做的是不断抬高攻击成本、缩小事故的影响范围。
所以，对于真正想把 Agent 做成企业级产品（ToB）的团队，并不存在一劳永逸的万能办法。可行的做法，是把三件事结合起来。第一是隔离：用系统层的沙箱和外部约束，严格限定 Agent 能做什么。第二是策略管控：用最小权限和固定的规则，约束它在这个范围内具体能访问什么。第三是责任溯源：用日志和可追溯机制，保证一旦真的出事，能查清是哪一步、哪一方的问题。
前两件是事前预防，第三件常被忽略，却同样重要。护栏防的是别让坏事发生，日志保证的是一旦发生能查清楚，两者谁也替代不了谁。现实中有一个明显的落差：很多公司都报告过疑似或确认的 Agent 安全事件，但真正把 Agent 当作一个需要单独授权、单独担责的「身份」来管理的，还很少。这个空白，正是今天 Agent 安全最现实的短板。
AI Agent 正在从「能回答问题」走向「能替人做事」。Agent 越自主，用户要托付给它的就越多：决定权、数据，还有各种密码和凭证。只指望模型自己学会克制，或者给它多写几百条护栏规则，这些办法都停留在模型内部，和模型处在同一个层级，挡不住前面说的那些问题。企业要让 Agent 真正可用，就必须把防线建在模型之外：先用沙箱限定它能操作的范围，再用最小权限约束它在范围内能访问的数据，同时把每一步都记入日志，一旦出事能追溯到源头。这三层结合在一起，才称得上一个企业可用的 Agent 安全方案。