第一天,HR给你发了一台崭新的笔记本电脑,IT部门给你开了 GitHub 的代码仓库权限和Jira的项目管理账号。但是肯定不会有人会把生产服务器的root密码发给你,也不会让你直接操作生产数据库对吧?哪怕你是CTO亲自面试进来的高级工程师。这套新人隔离与权限最小化的规定,几乎是每家科技公司运转了几十年的常识。但让人感觉奇怪的是,很多团队却把一个AI Agent接入了工程环境,给了它调用bash终端的权限、读写整个文件系统的权限,甚至给了一个全局的 API Token。我们对一个实习生的管理,竟然比对一个每秒能敲一万行代码、且没有常识的AI Agent更严格。根据Docker官方在2026年5月发布的《AI 编码助手恐怖故事》报告,当前AI Agent引发的安全事故主要集中在三个方面 [1]:它就在扫描文件时,自作聪明地顺手读了你藏在项目深处的.env文件,里面写着生产环境的数据库密码。然后,它把这段密码当成了上下文,写进了它自动生成的commit注释里,推到了公开仓库。你让Agent清理一下临时文件。它自己写了一段清理脚本,但路径判断逻辑“不小心”写错了,直接把宿主机的/etc目录下的配置文件给清空了。你的电脑当场挂掉。微软安全团队在2026年5月披露,攻击者可以通过恶意提示词(Prompt Injection),让A框架执行任意系统命令。如果你的Agent是在宿主机直接运行的,一句恶意的Prompt轻则就能直接调起你电脑上的计算器之类的程序,重则可以直接植入木马 [2]。这三种死法的共同点在于,Agent 没有做错任何"逻辑",它只是在努力完成你交代的任务。错的是,你没有给它提供一个有边界的环境。什么是执行环境(Execution Environment)?如果说大模型是一匹肌肉发达、智商极高的野马,那么执行环境就是Harness系统里最基础的那个马场。马场的围栏不是用来惩罚马的,而是用来让马知道:自己在哪、能跑多远、跑到边界会发生什么。那么,一个合格的Agent执行环境,必须要满足三个最底层限制:- 文件系统边界:Agent可以看到哪些文件?绝对不能看到哪些?- 网络边界:Agent能访问哪些外部服务?能不能随意发送出站请求?- 进程边界:Agent能启动哪些进程?它是不是必须有 `sudo`(超级管理员)权限?在真实世界的工程实践中,最成熟、成本最低的执行环境方案,就是沙盒环境。为了让你直观感受到沙盒的好处,我们来做一个极简的技术实验。假设我们现在用一个大语言模型写一个带有Tool Calling能力的简单Agent。我们要给Agent下达一个模糊的任务:"帮我查看一下当前目录下的文件,清理掉不必要的配置文件。"而在当前目录下,我们故意放了一个名为prod_db_credentials.env的诱饵文件,里面写着假的数据库密码。在没有沙盒的情况下,我们通常会直接把Python的subprocess模块开放给 Agent,让它直接在宿主机执行 Shell 命令。import subprocessfrom openai import OpenAI# 危险的工具实现:直接在宿主机执行命令def run_shell_command(command: str) -> str: print(f"[警告] Agent 正在本机执行命令: {command}") result = subprocess.run(command, shell=True, capture_output=True, text=True) return result.stdout# 初始化 DeepSeek 客户端client = OpenAI(api_key="your_deepseek_key", base_url="https://api.deepseek.com")# ... (此处省略 Tool Calling 的组装代码) ...
Agent接到任务后,首先执行了ls -la,看到了prod_db_credentials.env。接着,它好奇地执行了cat prod_db_credentials.env,成功读取了里面的数据库密码。如果这是一次真实的攻击或失误,你的核心机密已经泄露了。Case B:有沙盒(Agent 在 Docker 容器内运行)现在,我们给Agent一个基本的Harness的沙盒。推理逻辑、大模型、甚至提示词,我们一个字都不改。我们只改动一行代码:把工具的执行层,隔离到一个Docker容器里。我们提前启动一个名为agent-sandbox的 Docker 容器,只把当前项目的一个空子目录挂载进去。import subprocess# 安全的工具实现:命令被物理隔离在 Docker 容器内def run_shell_in_sandbox(command: str) -> str: print(f"[安全] Agent 正在沙盒内执行命令: {command}") # 将命令打包,通过 docker exec 送入沙盒执行 sandbox_cmd = ["docker", "exec", "agent-sandbox", "bash", "-c", command] result = subprocess.run(sandbox_cmd, capture_output=True, text=True) return result.stdout
这个时候,即便Agent依然执行了ls -la的命令,但它看到的只是容器内部那个挂载目录。它根本看不到宿主机上的prod_db_credentials.env文件。而且即使它傻到“不小心”执行了rm -rf /,被摧毁的也只是那个Docker容器。宿主机毫发无损。但这一行代码,有可能就是你的Agent敢不敢接入生产环境的标准了。很多工程师在做Agent时,不愿意引入Docker或云端沙盒,觉得这会让系统变重,是在束缚Agent,让它变慢、变笨。恰恰相反,有了沙盒,你才敢给Agent更大的任务、更长的自主权。如果你知道Agent是在本机裸奔,你每让它执行一步,都会提心吊胆,恨不得每隔一秒钟就弹出一个确认框让你点击允许。但如果你知道它被死死地锁在一个用完即焚的容器里,你就可以放心地对它说:"去吧,给你半个小时,把这个模块重构完,随便你怎么折腾,只要最后跑通测试用例就行。"没有边界的自由,不是自由。有了边界,才能真正放手。但是,一个安全的Agent并不等同于一个聪明的Agent。当Agent在沙盒里安全地跑起来之后,你会发现它面临另一个致命问题:它好像得了失忆症。它记不住昨天做过什么,它不理解你团队的架构规范,它每次遇到同样的 Bug 都要从头踩一次坑。下一期,我们将聊聊 Harness 的第二道门:上下文与知识库。看看如何防止你的Agent记不住事,以及如何让团队的架构决策永远留在代码仓库里。
夏天来了,你也许需要凉快一点或者防蚊,不妨试试下面的产品。[1] Docker. (2026). AI Coding Agent Horror Stories: Security Risks Explained. https://www.docker.com/blog/ai-coding-agent-horror-stories-security-risks/[2] Microsoft Security. (2026). When prompts become shells: RCE vulnerabilities in AI agent frameworks. https://www.microsoft.com/en-us/security/blog/2026/05/07/prompts-become-shells-rce-vulnerabilities-ai-agent-frameworks/