Cursor 被曝沙箱逃逸，AI 智能体为何需要内核级隔离

AI 编程助手 Cursor 被研究人员发现存在沙箱逃逸路径，再次将「AI 智能体的安全边界应该设在何处」这一问题推到台前。该研究以博文形式发布在 Medium 上，作者 Koukyosyumei 演示了在 Cursor 的执行环境中，智能体生成的代码如何突破既有的进程级沙箱限制，并据此主张：随着 AI 智能体获得写文件、执行命令、与系统交互等能力，传统应用层沙箱已不足以约束其行为，必须引入内核级别的隔离机制。

漏洞演示的核心思路

研究人员指出，Cursor 智能体在运行用户代码时主要依赖应用层沙箱进行权限控制，但这类隔离在面对需要执行 shell 命令、读写敏感路径或调用系统调用的智能体时存在明显短板：

攻击者可以通过智能体间接执行的脚本触发沙箱外的系统调用；
进程级隔离无法阻止权限提升类的操作链；
一旦智能体被诱导执行恶意代码，影响范围可能波及宿主机。

文章以此为例说明，「把 AI 智能体当作普通应用来沙箱化」的思路，在安全假设上存在根本性偏差。

为什么需要内核级边界

研究人员的核心论点是：AI 智能体本身具有「自然语言→任意代码」的转化能力，其输出是不可预测的程序行为，传统的应用层沙箱在设计上默认运行的是已知、良性的程序逻辑，这与智能体的实际风险模型不匹配。

更可靠的方案是在内核层设置硬性边界，例如：

基于 eBPF、Landlock、gVisor 等内核机制限制系统调用；
将智能体执行环境放入独立的微型虚拟机或容器中，与宿主机文件系统、网络严格隔离；
对智能体可访问的资源（文件路径、网络目标、进程能力）做最小权限白名单。

行业启示与未解的问题

这一案例折射出 AI 编程工具普遍面临的安全挑战。Claude Code、Cursor、Continue、Aider 等主流 AI 编程助手都在快速迭代智能体能力，允许其自主读写代码、执行测试命令，但底层沙箱设计多数仍停留在早期 IDE 插件的安全模型上，并未跟上智能体权限扩张的速度。

不过，该博文目前仅为单一研究人员的个人发布，缺乏 Cursor 官方的确认与 CVE 编号背书，技术细节的复现条件与影响范围仍有待社区进一步验证。对于普通用户而言，短期内的可行做法仍是：在不可信上下文中谨慎使用 AI 编程智能体，并尽量将自动执行操作限制在临时容器或受限项目目录内。