AI智能体的越狱游戏:当你的AI助手开始绕过

上个月我在调试一个自动编码Agent时，它突然在终端里执行了一条我没让它跑的命令。不是误理解了指令，而是它把一个看起来无害的参数通过shell的变量展开变成了 rm -rf / 的等价操作。安全过滤器认为那是安全的，但bash shell不这么认为。

那一刻我突然意识到，我们给AI助手装的那些"安全锁"，可能根本没有锁住任何东西。

这件事发生在一个更大的背景之下。2026年6月30日，安全研究员Omer Ben Simon和Adversa AI团队公开了一个名为GuardFall的系统性漏洞。他们对11个主流开源AI编码Agent做了测试——包括Aider、Cline、Goose、OpenHands、SWE-agent等，这些项目加起来在GitHub上有约54.8万颗星。测试结果：10个至少被一种绕过技术攻破，只有Continue扛住了全部测试。

问题的根源不在代码层面，而架构设计层面。

大多数Agent的安全过滤器是这样工作的：把AI准备执行的命令当作文本字符串，用正则表达式或黑名单扫描一遍，看看有没有rm -rf、格式化磁盘这类危险关键词。如果没有，就放行。

但bash shell执行命令之前，会做一系列转换：去掉引号、展开变量、执行命令替换、组装管道。过滤器看到的是转换前的文本，shell执行的是转换后的结果。两者根本不是同一条命令。

第一类叫引号剥离。你写 r''m，过滤器看到的是带空引号的字符串，匹配不到rm。但bash执行时会去掉空引号，把它拼回rm。一个看起来完全无害的字符串就这样变成了删除命令。

第二类是变量展开。 rm$IFS-rf$IFS/ 这条命令里，IFS是bash的内部字段分隔符变量，值为空格。过滤器看到的是没有空格的连续字符串，但bash执行时会展开成 rm -rf / 。

第三类是命令替换。用$(echo rm) -rf /这种形式，外层看起来像一个正常的命令调用，但子shell会计算出rm这个二进制名，最终效果跟直接写rm一样。

第四类更隐蔽——编码管道。把破坏性命令base64编码后通过管道传输解码执行，命令的任何一段都找不到可识别的危险模式。

第五类是利用替代工具和参数。比如find /x -delete实现删除效果，dd of=/dev/sda直接写磁盘，都不触发针对rm或format的黑名单。

这些绕过手法听起来像是20年前web应用注入攻击的翻版。事实上它们确实是这样——一个老问题被每个Agent团队独立重新发明了一遍，然后各自用同样的方式错误地解决。

GuardFall的披露者没有申请CVE编号，理由是这个问题的性质不是某个项目的bug，而是一种危险的设计惯例。就像十年前大量网站用字符串过滤代替参数化查询来防SQL注入一样，今天Agent团队用文本匹配代替shell感知的命令评估来防注入。

同一个信任边界失效还出现在其他场景。2026年2月，Cline Agent就被曝出过"困惑代理"攻击——Agent读取了它没有验证的内容并据此行动。Google的Antigravity IDE也存在类似的漏洞链：研究者通过find_by_name工具的Pattern参数注入命令行参数，最终绕过了Secure Mode实现了远程代码执行。这个漏洞甚至能存活于项目关闭、应用重启、甚至卸载重装之后。

USENIX Security 2026上，来自Anthropic和Google DeepMind的研究团队发表了一篇论文，论证当前针对越狱和提示注入的防御评估方法论本身有缺陷。他们用梯度下降、强化学习、随机搜索和人工指导探索四种优化方法，对12个最新防御方案进行自适应攻击，结果90%以上的攻击成功率——而这些防御方案最初报告的攻击成功率接近零。

如果你在用AI编码Agent做日常开发，那些让你点击"确认执行"的提示框，本质上是用户体验的便利，不是安全边界。真正有效的是操作系统的沙盒隔离——容器、受限用户账户或虚拟机。把Agent的命令执行限制在一个即使被攻破也不会影响主机的环境里。

如果你在做Agent的安全设计，文本匹配和黑名单只能挡住最天真的攻击。需要的是理解shell语义的命令评估器，或者干脆让Agent不直接碰shell，而是通过一个已知安全的工具调用来间接执行。

我在修完那次Agent绕过事件后，给自己的开发环境加了一层docker容器隔离。Agent的所有命令都在容器里跑，容器只有只读的文件系统挂载和一个受限的网络命名空间。不是因为我有多担心被攻击，而是因为那种"以为锁住了其实没有"的感觉不值得赌。