写这篇东西的起因很简单我在团队里负责给几个实验性质的AI Agent做安全收口结果被“沙箱”这两个字折磨了大半个月。网上搜了一圈讲理念的很多讲怎么落地到代码和配置上的很少。所以我把自己的踩坑记录整理出来作为一个阶段性的总结希望能帮到正在做类似事情的人。先说清楚这篇文章解决的问题当你的Agent需要调用工具、执行脚本、访问网络时怎么给它一个既不影响宿主环境、又不至于什么都干不了的运行边界。适合正在折腾Agent开发、对安全问题有点敏感、但不想从零研究内核机制的后端和算法同学参考。1. 核心思路Agent需要的是一整套“行为围栏”1.1 沙箱的边界到底划在哪里很多人的第一反应是沙箱 开个Docker容器把Agent丢进去跑。这个直觉方向是对的但距离“能落地”还差得很远。我核心的认知转变是Agent沙箱不是一个隔离技术问题而是一个“权限设计”问题。容器只是承载权限策略的载体真正决定安全边界的是你在容器内外配置的那一整套限制——文件系统范围、网络访问范围、可执行系统调用范围、资源上限、上下文生命周期。打个比方把Agent想象成一个新入职的实习生。你给他一把独立的办公桌容器隔离这解决了“他不能随便翻别人抽屉”的问题但你还得决定他能进哪些会议室网络策略、能碰哪些系统API权限、能领多少预算配额、工作多久必须下班超时销毁。这些规则合在一起才是一个完整沙箱。所以动手之前先别急着写docker run先把你手头Agent的能力清单盘出来它能执行什么语言脚本它会不会调用宿主机的shell它要访问哪些外部API它需要写盘吗写到哪里这些问题的答案直接决定沙箱的复杂程度。1.2 三个必须隔离的维度我最终把隔离维度收敛成三条后续所有设计和排障都围绕它们展开。计算与存储隔离Agent的运行环境要独立临时文件、缓存、依赖都不能污染宿主环境。这层用容器或轻量虚拟机实现重点在文件系统的只读根目录和临时目录的挂载策略。网络隔离不能让Agent任意访问内网也不能让它把内网数据带出去。这层靠命名空间和iptables策略控制是绝大多数人在初期会忽略的。权限隔离Agent能调用哪些API、能以什么级别的凭证调用需要做一层“身份剥离”。沙箱内的Agent本身不应拥有任何真实密钥所有密钥由外层沙箱管理进程按需注入用完即焚。这三个维度缺一不可。只做了第一维度的沙箱本质上只解决了一半问题后面我会详细讲为什么。2. 技术方案选型容器为主、系统调用为辅2.1 为什么不是虚拟机如果只看安全性虚拟机当然是更硬的边界。但我们的实验Agent需要频繁迭代依赖每次起一个虚拟机再做快照存储和启动耗时都扛不住。容器的启动速度以毫秒计虚拟机以秒计对Agent这种“每次任务都可能要新环境”的使用方式来说差距是数量级的。所以我的选择是默认容器 必要的系统调用过滤 宿主侧资源管控。容器解决文件系统和进程的可见性seccomp解决系统调用的可用性cgroups解决资源占用的上限。具体到工具链我没有自己造轮子而是基于常见的容器运行时做了一层薄封装。重点配置了以下几项配置项策略原因根文件系统只读防止Agent在容器内做持久化伪装或篡改依赖临时目录tmpfs挂载上限512MB允许写临时文件但不落盘进程隔离容器独立PID namespace避免Agent看到宿主进程减少信息泄露面网络默认关闭按需开放白名单内网资产不能让Agent直接探测系统调用默认黑名单模式屏蔽mount、ptrace、reboot等高风险调用2.2 关键参数与资源配额的思考资源配额这块很多人随手设置就完事但实测下来猫腻很多。先看CPU。容器默认的CPU限制是配额制比如cpus1表示最多占用1个核心但如果宿主很闲容器可以飙到多核心。对沙箱来说我倾向于把CPU限制做成两层先设置cpus上限避免单个Agent拖垮宿主再设置cpu配额避免Agent死循环时把整台宿主的调度器卡出明显抖动。内存这块更要小心我见过Agent写了一段险些内存溢出的代码直接申请了几个G的匿名页把宿主内存吃光OOM Killer介入后连带其他业务容器一起遭殃。所以memory的硬限制必须设并且要配合memory-swap做二次约束只限制内存不限制交换分区等于白设。文件描述符数量和可创建的进程数也要管默认的1024个fd对普通脚本够用但Agent一旦批量操作文件或并发起子进程很容易触底。建议直接把nofile和nproc用ulimit提到一个合理值同时用cgroups的pids限制去兜底进程总数因为ulimit是per-process的并不限制进程总数。2.3 镜像与依赖的防呆设计镜像构建是另一个容易踩坑的地方。常见的做法是直接把一个满配的Python镜像丢给Agent用但满配镜像意味着攻击面大——里面装了sed、awk、curl、python、pip、gcc等等对Agent来说这些都可能成为被利用的工具。我的策略是镜像只保留业务必需的运行时和库所有与任务无关的包一律不装。同时把包管理器默认索引指向内网私有源避免Agent在沙箱里偷偷安装依赖。这个防呆细节看着不起眼但能挡掉大量“Agent为了完成任务自行装包”的失控行为。3. 实操过程从0搭一个可用的Agent沙箱3.1 基础环境与启动流程一个典型的Agent任务启动流程我拆成下面几步每一步都有明确目的。# 1. 拉起容器不暴露任何端口禁止出网 docker run -d --name agent_run_$TASK_ID \ --network none \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size256m \ -m 1g --memory-swap 1g \ --cpus 1 \ --pids-limit 256 \ agent-base-image:latest \ python /runner.py第一行--network none是整条命令里最重要的一次决定。初始状态不让Agent碰任何网络需要访问外部资源时由外层调度进程通过标准输入或临时文件注入结果而不是让Agent自己发请求。这么做的好处是Agent永远没有主动外联的能力它只能拿到调度器“喂”给它的数据。--read-only配合--tmpfs的意思是根文件系统只读只有/tmp有写权限但不可执行程序。这样脚本执行产生的中间文件有地方去但Agent没法在/tmp里写一个可执行文件再运行堵死了很多绕过手段。3.2 工具调用与密钥管理的处理Agent通常通过工具调用和外界交互。我的做法是把所有工具调用从Agent进程内部挪到外部Agent只输出一个结构化意图由宿主侧的工具执行器去实际执行。这样密钥永远不会出现在Agent的进程环境变量里工具执行结果也只通过受限通道回传。具体来说我在宿主侧维护了一个工具白名单映射类似这样TOOL_WHITELIST { search: {exec: internal_search, timeout: 10, network: allow_listed}, calc: {exec: python -c, timeout: 5, network: none}, fetch: {exec: http_client, timeout: 15, network: allow_listed}, }每次Agent请求调用工具外层进程根据白名单校验参数格式、注入对应级别的临时凭证、设置单次超时然后执行。这比让Agent直接拿一个高权限的API Key要安全得多。3.3 网络白名单的具体落地网络这块我最终采取了“双重钳制”。容器侧先用--network none把所有流量挡掉然后在宿主的调度进程里为需要网络的任务单独起一个代理容器这个代理容器只开放特定目标地址和端口。代理容器的iptables策略样例简化版长这样iptables -A OUTPUT -d 10.1.2.3 -p tcp --dport 443 -j ACCEPT iptables -A OUTPUT -j REJECT细心的读者会发现只限制目标的IP和端口还不够DNS解析会泄露你访问了哪个域名。所以在真实配置里我会把DNS出口也限制到指定的内网解析器并且只允许查询白名单域名避免Agent借DNS做数据外带。3.4 日志采集与任务回放沙箱必须可观测。我在每个容器退出后保留三样东西标准输出日志、容器内产生的临时文件快照、以及Agent对外部工具的全部调用记录。有了这三样任何一次任务异常都能回放。回放是个好东西。某次Agent执行的任务结果诡异我把当时的工具调用序列重新跑了一遍发现是工具参数里被注入了异常字符导致解析错位问题三分钟定位。没有回放能力这种偶现问题会消耗一下午。4. 常见问题与排查笔记4.1 为什么Agent“越狱”比你想象的容易一个残酷的结论只做容器隔离、不做系统调用过滤的沙箱在多数场景下约等于没有因为容器共享宿主内核Agent只要能触发特权系统调用就有机会影响宿主的全局状态。实际测试中我用一段很短的代码就触发了内核计数器抖动。排查后加上了seccomp过滤核心是禁止容器内进程发起mount、ptrace、reboot、kexec_load等系统调用。为了省事很多方案直接采用seccomp default但注意default策略会直接影响运行时性能建议做成白名单模式只放行业务确实需要的调用。这里要提一个非常容易踩的偏门即使你加了seccomp容器内的用户命名空间映射如果配置不当某些提权路径依然存在。稳妥的做法是关掉容器内的user namespace映射特权不让Agent创建需要CAP_SYS_ADMIN权限的子命名空间。4.2 沙箱内文件持久化的需求怎么处理实验初期Agent经常需要读一些公共数据集。如果把数据放根文件系统镜像体积会膨胀到不可接受如果放tmpfs每次启动都要重新灌入。我的折中方案数据只读挂载。宿主侧维护一份共享只读目录容器启动时以绑定挂载方式只读挂入。Agent可读不可写数据也不会随容器销毁丢失。注意这个目录的宿主人目录权限要收缩否则容器内的Agent可以通过路径遍历读到宿主其他文件。4.3 幽灵进程与资源清理沙箱运行一段时间后最常出现的问题是“容器退了但容器内的子进程还在宿主上挂着”。原因通常是Agent用后台方式启动了长驻进程容器主进程退出后这些子进程被收养成了孤儿进程但没有被销毁。我的做法是在创建容器时就指定init进程让init作为1号进程接管所有子进程的回收。同时写一个定时巡检脚本把超过预定生命周期仍未退出的容器强制stop并删除。巡检脚本本身逻辑很轻50行以内就能搞定但它能挡住绝大多数资源泄漏。4.4 超时与前端卡死的边界情况Agent调外部工具时最容易出问题是“工具没有超时返回”。之前我遇到过Agent写了个脚本循环请求一个慢接口工具执行器没有设单次超时结果Agent一直等又因为多轮循环把整个任务窗口拖爆。排查后我在工具执行器里统一加了硬超时超时直接杀掉工具进程并返回固定错误码给Agent让Agent自行决定要不要重试。实测下来Agent对“工具超时”的处理要比“工具无响应”理智得多至少不会无限等下去。5. 一些真实的经验与反思如果你照着上面的方案在做有几点经验我建议直接记进自己的方法论里。沙箱的验收标准要包含“恶意Agent路径测试”。我每个月都会拿几段故意写坏的代码丢进沙箱跑一轮验证文件系统、网络、进程资源三重隔离是否都还在。这类测试看起来不起眼却是保证沙箱不过期失效的最好手段。不要把安全寄托在“Agent很守规矩”上。Agent的目标是完成任务它会想尽办法调用一切可用工具。你要做的不是教育Agent而是让环境中根本不存在危险能力。日志比配置更重要。一次任务后复盘时日志的完整度直接决定排障效率。宁可多留日志也不要吝啬磁盘。最后再分享一个我踩了两次才学乖的小技巧每次改动沙箱配置一定要在发布前跑一遍回归用例并且把回归用例的结果留存对比。沙箱配置改动看起来是纯增量调整实际上很容易因为一处小改动比如多放开一个目录的写权限埋下一个巨大的隐患而这个隐患往往等一两周后某个异常任务出现时才暴露。把回归做成常态化你就能在它变成事故之前把它当成一次正常配置变更来处理。写完这篇我还想继续去补一个更细节的方向沙箱内Agent的模型请求路径本身需不需要单独分层管理。这个我还在实验跑出结论了再回来更新。 
长河君 · 2026/10/14 11:50:31 · 阅读 1.2k AI Agent安全沙箱落地指南：容器隔离、网络白名单与权限管控
写这篇东西的起因很简单我在团队里负责给几个实验性质的AI Agent做安全收口结果被“沙箱”这两个字折磨了大半个月。网上搜了一圈讲理念的很多讲怎么落地到代码和配置上的很少。所以我把自己的踩坑记录整理出来作为一个阶段性的总结希望能帮到正在做类似事情的人。先说清楚这篇文章解决的问题当你的Agent需要调用工具、执行脚本、访问网络时怎么给它一个既不影响宿主环境、又不至于什么都干不了的运行边界。适合正在折腾Agent开发、对安全问题有点敏感、但不想从零研究内核机制的后端和算法同学参考。1. 核心思路Agent需要的是一整套“行为围栏”1.1 沙箱的边界到底划在哪里很多人的第一反应是沙箱 开个Docker容器把Agent丢进去跑。这个直觉方向是对的但距离“能落地”还差得很远。我核心的认知转变是Agent沙箱不是一个隔离技术问题而是一个“权限设计”问题。容器只是承载权限策略的载体真正决定安全边界的是你在容器内外配置的那一整套限制——文件系统范围、网络访问范围、可执行系统调用范围、资源上限、上下文生命周期。打个比方把Agent想象成一个新入职的实习生。你给他一把独立的办公桌容器隔离这解决了“他不能随便翻别人抽屉”的问题但你还得决定他能进哪些会议室网络策略、能碰哪些系统API权限、能领多少预算配额、工作多久必须下班超时销毁。这些规则合在一起才是一个完整沙箱。所以动手之前先别急着写docker run先把你手头Agent的能力清单盘出来它能执行什么语言脚本它会不会调用宿主机的shell它要访问哪些外部API它需要写盘吗写到哪里这些问题的答案直接决定沙箱的复杂程度。1.2 三个必须隔离的维度我最终把隔离维度收敛成三条后续所有设计和排障都围绕它们展开。计算与存储隔离Agent的运行环境要独立临时文件、缓存、依赖都不能污染宿主环境。这层用容器或轻量虚拟机实现重点在文件系统的只读根目录和临时目录的挂载策略。网络隔离不能让Agent任意访问内网也不能让它把内网数据带出去。这层靠命名空间和iptables策略控制是绝大多数人在初期会忽略的。权限隔离Agent能调用哪些API、能以什么级别的凭证调用需要做一层“身份剥离”。沙箱内的Agent本身不应拥有任何真实密钥所有密钥由外层沙箱管理进程按需注入用完即焚。这三个维度缺一不可。只做了第一维度的沙箱本质上只解决了一半问题后面我会详细讲为什么。2. 技术方案选型容器为主、系统调用为辅2.1 为什么不是虚拟机如果只看安全性虚拟机当然是更硬的边界。但我们的实验Agent需要频繁迭代依赖每次起一个虚拟机再做快照存储和启动耗时都扛不住。容器的启动速度以毫秒计虚拟机以秒计对Agent这种“每次任务都可能要新环境”的使用方式来说差距是数量级的。所以我的选择是默认容器 必要的系统调用过滤 宿主侧资源管控。容器解决文件系统和进程的可见性seccomp解决系统调用的可用性cgroups解决资源占用的上限。具体到工具链我没有自己造轮子而是基于常见的容器运行时做了一层薄封装。重点配置了以下几项配置项策略原因根文件系统只读防止Agent在容器内做持久化伪装或篡改依赖临时目录tmpfs挂载上限512MB允许写临时文件但不落盘进程隔离容器独立PID namespace避免Agent看到宿主进程减少信息泄露面网络默认关闭按需开放白名单内网资产不能让Agent直接探测系统调用默认黑名单模式屏蔽mount、ptrace、reboot等高风险调用2.2 关键参数与资源配额的思考资源配额这块很多人随手设置就完事但实测下来猫腻很多。先看CPU。容器默认的CPU限制是配额制比如cpus1表示最多占用1个核心但如果宿主很闲容器可以飙到多核心。对沙箱来说我倾向于把CPU限制做成两层先设置cpus上限避免单个Agent拖垮宿主再设置cpu配额避免Agent死循环时把整台宿主的调度器卡出明显抖动。内存这块更要小心我见过Agent写了一段险些内存溢出的代码直接申请了几个G的匿名页把宿主内存吃光OOM Killer介入后连带其他业务容器一起遭殃。所以memory的硬限制必须设并且要配合memory-swap做二次约束只限制内存不限制交换分区等于白设。文件描述符数量和可创建的进程数也要管默认的1024个fd对普通脚本够用但Agent一旦批量操作文件或并发起子进程很容易触底。建议直接把nofile和nproc用ulimit提到一个合理值同时用cgroups的pids限制去兜底进程总数因为ulimit是per-process的并不限制进程总数。2.3 镜像与依赖的防呆设计镜像构建是另一个容易踩坑的地方。常见的做法是直接把一个满配的Python镜像丢给Agent用但满配镜像意味着攻击面大——里面装了sed、awk、curl、python、pip、gcc等等对Agent来说这些都可能成为被利用的工具。我的策略是镜像只保留业务必需的运行时和库所有与任务无关的包一律不装。同时把包管理器默认索引指向内网私有源避免Agent在沙箱里偷偷安装依赖。这个防呆细节看着不起眼但能挡掉大量“Agent为了完成任务自行装包”的失控行为。3. 实操过程从0搭一个可用的Agent沙箱3.1 基础环境与启动流程一个典型的Agent任务启动流程我拆成下面几步每一步都有明确目的。# 1. 拉起容器不暴露任何端口禁止出网 docker run -d --name agent_run_$TASK_ID \ --network none \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size256m \ -m 1g --memory-swap 1g \ --cpus 1 \ --pids-limit 256 \ agent-base-image:latest \ python /runner.py第一行--network none是整条命令里最重要的一次决定。初始状态不让Agent碰任何网络需要访问外部资源时由外层调度进程通过标准输入或临时文件注入结果而不是让Agent自己发请求。这么做的好处是Agent永远没有主动外联的能力它只能拿到调度器“喂”给它的数据。--read-only配合--tmpfs的意思是根文件系统只读只有/tmp有写权限但不可执行程序。这样脚本执行产生的中间文件有地方去但Agent没法在/tmp里写一个可执行文件再运行堵死了很多绕过手段。3.2 工具调用与密钥管理的处理Agent通常通过工具调用和外界交互。我的做法是把所有工具调用从Agent进程内部挪到外部Agent只输出一个结构化意图由宿主侧的工具执行器去实际执行。这样密钥永远不会出现在Agent的进程环境变量里工具执行结果也只通过受限通道回传。具体来说我在宿主侧维护了一个工具白名单映射类似这样TOOL_WHITELIST { search: {exec: internal_search, timeout: 10, network: allow_listed}, calc: {exec: python -c, timeout: 5, network: none}, fetch: {exec: http_client, timeout: 15, network: allow_listed}, }每次Agent请求调用工具外层进程根据白名单校验参数格式、注入对应级别的临时凭证、设置单次超时然后执行。这比让Agent直接拿一个高权限的API Key要安全得多。3.3 网络白名单的具体落地网络这块我最终采取了“双重钳制”。容器侧先用--network none把所有流量挡掉然后在宿主的调度进程里为需要网络的任务单独起一个代理容器这个代理容器只开放特定目标地址和端口。代理容器的iptables策略样例简化版长这样iptables -A OUTPUT -d 10.1.2.3 -p tcp --dport 443 -j ACCEPT iptables -A OUTPUT -j REJECT细心的读者会发现只限制目标的IP和端口还不够DNS解析会泄露你访问了哪个域名。所以在真实配置里我会把DNS出口也限制到指定的内网解析器并且只允许查询白名单域名避免Agent借DNS做数据外带。3.4 日志采集与任务回放沙箱必须可观测。我在每个容器退出后保留三样东西标准输出日志、容器内产生的临时文件快照、以及Agent对外部工具的全部调用记录。有了这三样任何一次任务异常都能回放。回放是个好东西。某次Agent执行的任务结果诡异我把当时的工具调用序列重新跑了一遍发现是工具参数里被注入了异常字符导致解析错位问题三分钟定位。没有回放能力这种偶现问题会消耗一下午。4. 常见问题与排查笔记4.1 为什么Agent“越狱”比你想象的容易一个残酷的结论只做容器隔离、不做系统调用过滤的沙箱在多数场景下约等于没有因为容器共享宿主内核Agent只要能触发特权系统调用就有机会影响宿主的全局状态。实际测试中我用一段很短的代码就触发了内核计数器抖动。排查后加上了seccomp过滤核心是禁止容器内进程发起mount、ptrace、reboot、kexec_load等系统调用。为了省事很多方案直接采用seccomp default但注意default策略会直接影响运行时性能建议做成白名单模式只放行业务确实需要的调用。这里要提一个非常容易踩的偏门即使你加了seccomp容器内的用户命名空间映射如果配置不当某些提权路径依然存在。稳妥的做法是关掉容器内的user namespace映射特权不让Agent创建需要CAP_SYS_ADMIN权限的子命名空间。4.2 沙箱内文件持久化的需求怎么处理实验初期Agent经常需要读一些公共数据集。如果把数据放根文件系统镜像体积会膨胀到不可接受如果放tmpfs每次启动都要重新灌入。我的折中方案数据只读挂载。宿主侧维护一份共享只读目录容器启动时以绑定挂载方式只读挂入。Agent可读不可写数据也不会随容器销毁丢失。注意这个目录的宿主人目录权限要收缩否则容器内的Agent可以通过路径遍历读到宿主其他文件。4.3 幽灵进程与资源清理沙箱运行一段时间后最常出现的问题是“容器退了但容器内的子进程还在宿主上挂着”。原因通常是Agent用后台方式启动了长驻进程容器主进程退出后这些子进程被收养成了孤儿进程但没有被销毁。我的做法是在创建容器时就指定init进程让init作为1号进程接管所有子进程的回收。同时写一个定时巡检脚本把超过预定生命周期仍未退出的容器强制stop并删除。巡检脚本本身逻辑很轻50行以内就能搞定但它能挡住绝大多数资源泄漏。4.4 超时与前端卡死的边界情况Agent调外部工具时最容易出问题是“工具没有超时返回”。之前我遇到过Agent写了个脚本循环请求一个慢接口工具执行器没有设单次超时结果Agent一直等又因为多轮循环把整个任务窗口拖爆。排查后我在工具执行器里统一加了硬超时超时直接杀掉工具进程并返回固定错误码给Agent让Agent自行决定要不要重试。实测下来Agent对“工具超时”的处理要比“工具无响应”理智得多至少不会无限等下去。5. 一些真实的经验与反思如果你照着上面的方案在做有几点经验我建议直接记进自己的方法论里。沙箱的验收标准要包含“恶意Agent路径测试”。我每个月都会拿几段故意写坏的代码丢进沙箱跑一轮验证文件系统、网络、进程资源三重隔离是否都还在。这类测试看起来不起眼却是保证沙箱不过期失效的最好手段。不要把安全寄托在“Agent很守规矩”上。Agent的目标是完成任务它会想尽办法调用一切可用工具。你要做的不是教育Agent而是让环境中根本不存在危险能力。日志比配置更重要。一次任务后复盘时日志的完整度直接决定排障效率。宁可多留日志也不要吝啬磁盘。最后再分享一个我踩了两次才学乖的小技巧每次改动沙箱配置一定要在发布前跑一遍回归用例并且把回归用例的结果留存对比。沙箱配置改动看起来是纯增量调整实际上很容易因为一处小改动比如多放开一个目录的写权限埋下一个巨大的隐患而这个隐患往往等一两周后某个异常任务出现时才暴露。把回归做成常态化你就能在它变成事故之前把它当成一次正常配置变更来处理。写完这篇我还想继续去补一个更细节的方向沙箱内Agent的模型请求路径本身需不需要单独分层管理。这个我还在实验跑出结论了再回来更新。