文章总结： 本文分析了AIAgent沙箱anolisa内置沙箱的安全机制，指出其基于bubblewrap封装并采用seccomp黑名单限制系统调用，但沙箱激活依赖特定hook且仅适用于copilot-shell调用runshellcommand工具，缺乏系统级兜底机制和第三方Agent安全保障，更多是应用级沙箱框架。 综合评分： 68 文章分类： 沙箱安全,AI安全,代码审计,应用安全,安全开发

AI Agent沙箱之ANOLISA内置沙箱

原创

瓜田里的猹 瓜田里的猹

不吃猹的瓜

2026年4月9日 23:00 北京

今年以来AI Agent在业内掀起了一股浪潮，由于LLM的不可预测性及Agent的完全授权特性，使得我们需要通过沙箱确保Agent运行时处于一个”可控”的状态，作为一个古法安全研究员，笔者对于各类沙箱程序都有着浓厚的研究兴趣，因此打算记录一下对于当前较为知名的各大Agent沙箱进行分析学习的过程，笔者会将整个过程整理为一个系列，希望能对大家有所帮助，当然行文之中有不对之处，也希望各位读者批评指出。

我们首次研究的对象是某厂的ANOLISA内置沙箱，因为正好它近期开源了。从官网上来看，ANOLISA是一款Agent-first 系统，其内置的沙箱也是系统级别的：

开发一款系统级别的Agent沙箱，这是一个较新的业务场景，笔者对于这样一款产品心中充满了好奇与疑问(首先明确的是，以下思考的业务场景是该Agent-first 系统面向的是tob业务，为企业提供一个Agent运行环境，适配企业所需的各类业务Agent)：

(1)系统如何保证第三方Agent处于沙箱保护中？笔者的考量是这样几种方案：Agent通过某种机制通知系统，系统得知后主动进行沙箱化；系统内置常见的Agent名单，并且提供用户配置接口，系统基于一个list对目标进行沙箱化；提供sdk接口，Agent开发人员基于sdk接口获得沙箱能力；基于渠道控制，认为特定渠道(如Agent商店)获取的才是Agent。

(2)沙箱如何实现适配兼容各类Agent，确保能在相关的业务场景稳定运行？(比如一个通用的Agent和一个适用于CI/CD场景的Agent其权限控制策略必然不一样)对于这个问题，笔者的考量是系统将权限细粒度拆分供Agent选择，Agent默认按最小权限集运行，同时提供各类业务场景权限配置模板供用户自主配置，对于因权限不足无法完成业务的情况LLM决策需补充授予的最小权限，并通知用户自主选择是否授予相关权限，同时告知潜在风险。

接下来我们便带着两个疑问去研究这套系统源码，该项目主要模块如下：

其中agent-sec-core部分是保证”安全”的核心模块，该模块中最核心的便是linux-sandbox，linux-sandbox是基于bubblewrap封装的沙箱模块，被”保护”的进程作为命令行参数传递给bubblewrap，同时linux-sandbox根据配置信息生成其他参数传递给bubblewrap，最终bubblewrap拉起被”保护”的进程。有了这些大体的了解后，我们还需要继续细读源码以探究这么2个细节从而回答我们开始的两个疑问：

细节一：linux-sandbox何时以何种方式被唤起

细节二：linux-sandbox以何种方式做了哪些权限控制？是否有做各种业务场景的兼容适配？

细节一

对于细节一，笔者猜测开发者的构想应该是有两种唤起场景(为什么用”猜测”这样一个词呢，后续会提到):

场景一：和claude code类似，通过hooks机制在copilot-shell(这是系统内置的AI Agent)调用run_shell_command工具前执行\src\copilot-shell\hooks\sandbox-guard.py，当被执行的tools为非block场景时，便会通过linux-sandbox拉起tools:

场景二：通过skills(\src\agent-sec-core\skill\references\agent-sec-sandbox.md)加载，该skills的description如下：

skills会通过linux-sandbox拉起目标程序：

从设计上来说，研发人员似乎想通过description让LLM首先采纳该skills，但该skills文件并不在默认发送的目录里，真正默认发送的\src\agent-sec-core\skill\SKILL.md其中并没有任何对于agent-sec-sandbox.md的引用，所以这个skills并不会生效。

从上述两个场景我们可以知道，唯一能让沙箱起作用的场景只有copilot-shell调用run_shell_command工具时才会生效。

细节二

对于细节二，linux-sandbox主要通过seccomp限制系统调用，借助bubblewrap实现命名空间隔离，但seccomp采用的是黑名单模式，只有特定几个网络相关系统调用被限制：

对于兼容业务场景的考虑，当前似乎只有考虑到某些配置了网络代理的情况，在沙箱中有一个名为allow_network_for_proxy的配置参数，若是设置了该参数，在配置了网络代理的场景下，沙箱会构建这样一条网络通路：沙箱内程序<->local bridge<->host bridge<->网络代理<->互联网。

其中local bridge为沙箱内的转发程序，沙箱通过替换内部网络代理配置，使得内部程序将流量发送给local bridge，local bridge通过unix socket将流量转发给沙箱外部的转发程序 host bridge，最后host bridge将流量转发给真正的代理服务器。

在掌握这些细节后，笔者的感受是这套系统更像是一个为copilot-shell打造的应用级别的agent沙箱，安全保障的生效较为依赖于LLM是否采纳相关skills，缺乏系统级别的兜底机制，也无法保障第三方Agent的”安全”，这可能是由于开源部分更多的是一个框架性质的项目，需要广大社区人员共同参与构建，往里面填充内容。当然项目依旧是一个优秀的框架，笔者在学习时收获甚多，在阅读的过程中，脑子中很多模糊的想法概念也慢慢有了一些初步的轮廓，非常感谢相关组织的开源举动。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：不吃猹的瓜 瓜田里的猹 瓜田里的猹《AI Agent沙箱之ANOLISA内置沙箱》