Spring AI Alibaba Agent执行Shell命令引发密钥泄露，沙箱边界到底在哪

说实话，这个问题的标题写出来的时候，我盯着屏幕愣了好几秒。上周在模拟项目X里，我给 Agent 开了个执行 shell 命令的入口，本来是想让它自己查查日志、看下服务状态，减少人工操作的频率。结果它执行完一次诊断任务后，返回值里明晃晃地带出了一行数据库明文密码——它没有恶意，只是顺着用户那句“看看项目配置有没有问题”，老老实实跑了cat application.yml，然后把整个文件内容当作工具执行结果吐了回来。

那一刻我意识到一个被大多数教程忽略的事实：包括我自己在内，很多人对“沙箱”这个词的理解，和它实际能防御的范围之间，存在巨大的偏差。这篇文章不打算讲多高深的架构，就围绕这个事故，把 Spring AI Alibaba 里 Agent 执行 shell 命令的场景拆开，聊聊密钥是怎么被读到的，以及我们以为的沙箱到底防住了什么。

1. 先还原现场：Agent 是怎么拿到 shell 执行能力的

1.1 需求背景：为什么我敢给 Agent 开命令执行权限

起因并不复杂。某个微服务项目的日常运维里，有大量重复性的排查动作：服务起不来要看日志末尾、端口被占要查进程、磁盘满了要统计目录大小。这些操作本身是低风险的只读命令，但频率很高，每次都要人工登录容器敲一遍。于是当时的设想是：让 Agent 直接执行这些诊断命令，把结果聚合后返回给值班的人，省掉中间来回沟通的成本。

这个需求本身是合理的。Spring AI Alibaba 框架天然支持工具调用，Agent 在对话过程中可以根据用户的诉求选择调用注册好的函数。把 shell 执行能力封装成一个工具后，Agent 就能“亲自动手”查系统状态。听起来很高效，但隐患也从这里开始埋下。

当时我给自己找的理由是“反正有沙箱兜底”，还特意加了一层命令黑名单，把rm、mkfs、dd这类破坏性命令挡在外面。我甚至觉得这个设计已经足够谨慎了——现在回头看，这个判断错得离谱。

1.2 Spring AI Alibaba 的工具注册机制

先用大白话讲一下 Spring AI Alibaba 里 Agent 调用工具的链路。框架底层接入了大语言模型，但模型本身不会直接执行任何系统操作，它只负责“决定该调用哪个工具”以及“生成传给工具的参数”。真正执行动作的是我们注册在 Spring 容器里的普通方法。

具体到代码层面，只需要在方法上标注@Tool注解，并写清楚方法的描述和参数说明。框架会把这些工具的定义（名称、描述、参数结构）作为上下文提交给模型。模型在推理过程中，如果判断当前问题需要某个工具介入，就会返回一个工具调用请求，由框架负责路由到对应方法执行，最后把返回值塞回给模型，让模型基于返回结果生成最终回答。

这个机制本身设计得很干净，问题从来不在框架，而在于开发者给工具授权了多大的能力。如果你把一个executeShellCommand方法注册给 Agent，本质上等于给了模型一张“任何命令都能执行”的通行证。它是否会拿到不该拿的信息，完全不取决于框架，只取决于执行命令的那个进程拥有多少权限。

1.3 第一版 ShellTool 代码：问题从这里开始

我当时实现的工具长这样：

@Component public class ShellTool { private static final Logger log = LoggerFactory.getLogger(ShellTool.class); @Tool(description = "在服务器上执行指定 shell 命令并返回标准输出，用于诊断系统状态") public String executeShellCommand(String command) throws Exception { log.info("收到 shell 指令: {}", command); Process process = Runtime.getRuntime().exec(new String[]{"/bin/sh", "-c", command}); String output = readProcessOutput(process); int exitCode = process.waitFor(); log.info("命令退出码: {}", exitCode); return "退出码: " + exitCode + "\n" + output; } private String readProcessOutput(Process process) throws IOException { try (BufferedReader reader = new BufferedReader( new InputStreamReader(process.getInputStream(), StandardCharsets.UTF_8))) { return reader.lines().collect(Collectors.joining("\n")); } } }

代码很简短，但信息量极大。我用Runtime.exec打开了/bin/sh -c，这个字符串会被 shell 完整解析，任何命令都能塞进去。虽然外面套了一层黑名单拦截，但黑名单天然存在绕过空间：比如限制cat吗？那less、head、tail、sed都能读文件。限制env吗？那/proc/1/environ照样能读。黑名单防君子不防小人的本质，在这个场景下展露无遗。

更关键的是，这个执行发生在应用进程内部，继承了该进程的全部身份和文件访问权限。应用能读application.yml，Agent 就能读。应用能连数据库，Agent 就能拿到连接串。这不是 Agent 被“赋予”了额外权限，而是它天然站在应用的肩膀上。

2. 事故复盘：密钥是怎么被 Agent 读走的

2.1 触发过程：一句“看看配置”引发的泄露

事故发生的时间点是某次联调后的晚上。值班的人在群里发消息说服务重启失败，报错指向数据源初始化。我本来打算登录容器看配置，但转念一想：Agent 不是有 shell 工具吗，直接让它查。于是我在对话里问了一句：“看下项目配置文件和启动脚本，检查数据源配置是否正确。”

模型收到的上下文里包含了 ShellTool 的定义，它判断这个任务需要执行命令。紧接着它生成了这样几条命令：

cat application.yml cat bootstrap.yml cat start.sh

前两条命令顺利执行，文件内容被读出来，作为工具结果返回给了模型。模型看到了spring.datasource.password字段，但它并不清楚这属于敏感信息，于是把整个文件内容原封不动地组织进了回答里。整个过程一气呵成，从命令生成到信息返回，没有任何一个环节对内容做过检查。

事后我在日志里看到了完整的命令记录和工具返回值。看着那行明文密码出现在日志文件里，说实话，背脊发凉。因为这个日志文件本身可能被同步到日志平台，等于密钥又多了一个扩散面。

2.2 完整的调用链：没有任何一环做检查

我把这次事故的完整链路画出来，你就明白问题出在哪了：

1. 用户输入需求：检查配置文件中的数据源配置。
2. 模型推理：判断需要调用executeShellCommand工具，参数为cat application.yml。
3. 框架路由：找到ShellTool对应的@Tool方法，把参数传入。
4. 黑名单拦截器：检查命令前缀，发现cat不在黑名单里，放行。
5. 进程执行：应用进程执行cat application.yml，读取文件内容。
6. 返回值收集：readProcessOutput把全部内容收集成字符串。
7. 模型回答：模型接收返回值，组织成自然语言回复。
8. 返回给前端：用户在对话界面看到了完整文件内容。

这八步里，哪一步涉及了敏感信息识别？没有。哪一步做了密钥掩码？没有。哪一步断言过“工具执行结果在返回给模型之前必须经过脱敏”？也没有。

我原以为黑名单是沙箱的第一道防线，但黑名单做的是“行为阻断”，而不是“数据过滤”。它拦得住rm -rf /，拦不住cat application.yml。因为在命令层面，读取一个文件是完全合法的操作，只是文件内容里恰好包含密钥而已。

2.3 我原以为的沙箱防线错在哪

事故发生后，我第一时间去翻代码，想确认是不是“沙箱失效了”。翻完才发现，压根就没有一个东西叫“沙箱”。我当时所谓的沙箱，其实是一层正则黑名单加上一句“在容器里运行，应该没问题”的心理安慰。

这里要澄清一个常见的认知误区：容器不是沙箱。容器提供的是资源隔离和进程隔离，但在文件系统层面，如果宿主机目录被挂载进容器，容器内进程就能读取挂载目录下的所有文件。更不用说我们的应用配置application.yml就明文放在工作目录里，应用进程本身就有权限读它。Agent 跑在同一个 JVM 里，共享同一份文件权限。如果这个问题想不明白，就算换 Docker、换 K8s、换任何隔离技术，只要文件还在那个目录里，Agent 就能读到。

所以我后来总结了一个公式：Agent 的信息可见范围等于承载 Agent 的进程的文件访问权限。要控制 Agent 能看到什么，核心不是给 Agent 做限制，而是给承载它的进程做限制。这个认知层面的转变，比任何技术手段都重要。

3. 沙箱到底防住了什么：三层隔离边界逐一拆解

3.1 命令黑名单：防危不防读

先说说我最初用的“沙箱”也就是命令黑名单的实际效果。它的作用范围仅限于“阻断明确的高危动作”。比如rm -rf、Format、dd if=，这些命令的破坏性一眼可见，用正则匹配前缀就能拦住。

但它的盲区在于：无法判断一个合法命令是否在读取敏感文件。cat application.yml合法，读文件而已；cat /proc/self/environ合法，读进程环境变量；curl http://内网地址也合法，访问网络。你不可能通过黑名单把这些全部拦截，因为正常的诊断场景确实需要用到它们。

这里我踩过的坑是：一开始黑名单写成前缀匹配，就被绕过了一次。模型生成了command -v cat && cat application.yml这样的复合命令，前缀匹配完全失效。后来改成命令解析加白名单，才稍微好一点。但即便如此，白名单如果包含了cat、grep、sed，读文件的能力依然在，只是给模型增加了“选择成本”。

3.2 进程与容器：文件系统的可见范围才是关键

从进程层面看，沙箱的边界其实取决于两个问题：这个进程能看到哪些文件？这个进程能访问哪些网络？

如果你的 Agent 直接作为应用进程的一部分运行，那它和主应用完全共享权限视图。它能读应用能读的一切，连应用配置里引用的密钥文件也在这个范围内。这就是为什么“让 Agent 跑在容器里”并不等于安全——容器只是操作系统层面的隔离，如果应用的配置文件和密钥文件都明晃晃地放在工作目录里，并且你把这个工作目录挂载进了容器，那容器内进程照样能读。

真正有效的做法是把 Agent 单独部署在一个隔离进程中，给它单独的挂载目录，只挂载它完成任务所必需的日志目录和临时目录。应用配置文件和密钥文件不在这个挂载列表里，Agent 的进程就算被模型诱导去读，也只会得到一个“文件不存在”的报错。

我见过一个反面案例：某开发者为了排查方便，把宿主机整个项目目录挂载进了一个 Agent 容器，美其名曰“让 Agent 能访问日志”。结果 Agent 确实只能访问日志——整个项目里它最高频访问的文件，就是包含了数据库密码的application.yml。这不是巧合，是权限范围定义错误的必然后果。

3.3 数据流层面：完全没有过滤机制

前面两层说的是“能做什么”，这一层说的是“能说什么”。即便 Agent 拿到了敏感内容，只要它在返回给用户之前被一层脱敏机制拦下来，泄露就不会发生。但大多数项目里根本没有这一层。

我后来加了一个工具返回值过滤器，在@Tool方法执行完、返回值交给模型之前，先过一遍正则替换。把password、token、secret、accessKey等关键字开头的配置项的值替换成***，再往下游传。这个机制不能阻止 Agent 读到内容，但至少能阻止敏感内容流到模型上下文和最终回答里。

不过这里有个新的坑：模型不一定只通过关键字识别敏感信息。它可能读到一段 JSON，里面键名是pwd，或者干脆是一串 JWT 格式的字符，正则匹配不到关键字照样透传。所以数据流过滤只能作为兜底，不能作为主防线。

3.4 结论：沙箱防的是“破坏”，不是“偷看”

把这三层放在一起看，结论已经很清楚：命令黑名单防的是破坏性操作，进程隔离缩小的是可见文件范围，数据流过滤阻止的是信息外泄。这三者各管一段，没有哪个是万能的。

我最初以为“有了沙箱就安全”，实际上是把“防破坏”当成了“防泄露”。沙箱的典型定位是阻止不可信的代码对系统造成永久性损害，它不会替你做数据分级的决策。判断哪些信息是敏感的、哪些内容可以给模型看，这个任务必须由开发者自己完成。

所以标题里那个问题的答案就是：沙箱防住了 Agent 把系统搞崩溃，但没防住 Agent 读取应用自身可见范围内的信息。如果你把密钥和应用运行配置放在同一个目录，Agent 读走它只是时间问题。

4. 重新加固：Agent 安全体系应该怎么做

4.1 工具白名单化：从“什么都能干”到“只能干指定的”

事故之后，我做的第一件事是把ShellTool彻底改掉，不再接受任意命令字符串，而是固定支持几个诊断动作，每个动作都有单独的方法签名。这样模型只能在这些动作中选择，参数也被限制在明确范围内。

@Component public class DiagnosticTool { private static final Set<String> LOG_DIRS = Set.of("/app/logs", "/var/log/app"); @Tool(description = "查看指定日志文件的最后 N 行，N 不超过 200") public String tailLog(String fileName, int lineCount) { if (!LOG_DIRS.stream().anyMatch(dir -> fileName.startsWith(dir))) { return "拒绝访问该路径，仅允许" + LOG_DIRS + "下的日志文件"; } int count = Math.min(lineCount, 200); return runCommand("tail -n " + count + " " + fileName); } @Tool(description = "检查磁盘使用情况") public String diskUsage() { return runCommand("df -h"); } @Tool(description = "查看内存使用情况") public String memoryUsage() { return runCommand("free -m"); } private String runCommand(String command) { try { Process process = Runtime.getRuntime().exec(new String[]{"/bin/sh", "-c", command}); return readOutput(process); } catch (Exception e) { return "命令执行失败: " + e.getMessage(); } } }

注意tailLog里的路径前缀校验，这是关键一步。不要把路径参数直接交给模型，模型可能会传/etc/passwd、/proc/self/environ，这些路径一旦拼接进tail -n命令，等于打开了文件系统的大门。白名单加路径校验之后，Agent 的能力边界就变得可预期了。

4.2 密钥管理：把敏感信息搬出明文文件

第一版加固之后，我面临的另一个问题是：即便 Agent 读不到application.yml，应用本身也需要从某个地方加载密钥。如果密钥继续以明文形式放在项目目录里，任何能读该目录的进程都有可能把它带出去。

一个务实的做法是引入配置中心加加密存储。应用启动时从配置中心拉取配置，密钥字段在配置中心里就是密文，应用侧用解密组件处理后才注入数据源。磁盘上不再存在包含明文密码的配置文件，Agent 就算读整个工作目录也找不到密钥。

如果项目短期没有配置中心的改造条件，退一步的做法是把敏感配置移到应用进程的环境变量里，并严格限制环境变量的读取权限。但要注意，环境变量对于容器内进程同样是可读的，env命令一执行全暴露，所以这只是过渡方案，不算根治。

我再补充一个细节：密钥轮换机制很重要。这次事故里的数据库密码其实是一条长期的静态密钥，一旦泄露，影响面非常大。如果当时用的是短期令牌加自动轮换，泄露后短时间内自动失效，损失就小得多。这个经验值得记下来。

4.3 返回结果脱敏：给数据暴露加一层兜底

工具白名单和密钥搬移解决了“Agent 读不到”的问题，但防御不能只靠单一手段。一个稳妥的安全体系需要叠加多层，哪怕某层被绕过，还有下一层兜底。

我在工具返回值上加了脱敏过滤。实现方式很简单，用 Spring AOP 拦截所有@Tool方法，拿到返回值后调用一个SensitiveDataMask工具类处理再返回。掩码规则优先匹配常见的敏感字段名，比如password、secret、token、apiKey、accessKey，匹配到就把对应的值替换成***。

@Aspect @Component public class ToolOutputMaskAspect { @Around("@annotation(org.springframework.ai.tool.annotation.Tool)") public Object maskToolResult(ProceedingJoinPoint pjp) throws Throwable { Object result = pjp.proceed(); if (result instanceof String text) { return SensitiveDataMask.mask(text); } return result; } }

这里的重点是：脱敏要在工具方法的返回值进入模型上下文之前完成。否则模型已经“看”到了明文密码，它完全有可能在后续对话中无意引用出来。脱敏之后，模型上下文里只有掩码后的内容，从根源上掐断了信息扩散。

4.4 进程隔离与最小挂载：让 Agent 单独存在

如果你的 Agent 和主应用共享同一个 JVM，那所有的文件权限、网络策略都是混在一起的。想精细控制 Agent 的能力边界，最好把它拆成独立的进程或容器服务。

拆分之后，Agent 容器的挂载需要遵循最小化原则。只挂载它实际需要的日志目录和临时目录，千万不要把整个项目目录、宿主机根目录、Docker Socket 挂进去。配置和密钥放在 Agent 访问不到的挂载里。这样即便模型被诱导执行了cat命令，也会因为文件系统里根本没有那个文件而失败。

这个改造的成本确实比前面几项高，但收益也最明显——它把“Agent 可见范围”从整个应用目录缩小到几个明确目录。如果项目已经上了容器化，这个调整几乎没有额外负担，只是修改挂载配置和部署清单。

4.5 审计与可追溯：出了事能还原现场

最后一项是审计。工具调用的输入输出必须有完整日志，而且日志本身也要做脱敏处理。我做加固时就发现，最早的ShellTool里那行log.info("收到 shell 指令: {}", command)就是一个泄漏点——如果模型生成的命令里带了令牌，比如curl -H "Authorization: Bearer xxx"，整串令牌就会跟着日志一起写进文件。所以审计日志同样要走脱敏逻辑，并且对日志文件的访问权限也要收敛。

审计不只是为了“出事能查”，它还能帮助你反推模型的决策逻辑。后来我定期翻工具调用日志，总结模型偏爱生成哪些命令，然后针对高频命令做更精细的收口策略。比如我发现模型经常尝试用find命令找文件，就把find从白名单里拿掉，换成限定目录的列出文件工具。这个持续收敛的过程，让 Agent 的能力边界越来越贴合实际需求。

5. 排查路径与安全基线：照着这份清单检查你的 Agent

5.1 如何复现和定位此类问题

如果你的项目里已经存在类似风险，想确认是否踩了雷，可以按照以下路径自查。

第一步，检查注册的@Tool方法。重点看有没有方法接收了任意命令字符串或任意路径字符串。只要存在这类方法，风险等级直接拉满。

第二步，看工具执行结果是否经过过滤。打开 Agent 的日志，找一次真实调用，看工具返回值是什么样。如果日志里能看到配置文件的完整内容，说明脱敏机制完全空缺。

第三步，检查 Agent 进程的挂载和权限。进到 Agent 运行的容器里，敲一下ls，看在当前目录能看到哪些文件。如果application.yml、.env、密钥目录都在视野内，那 Agent 就能读到。

第四步，模拟异常输入。直接向 Agent 提问“读取 /etc/passwd”、 “读取进程环境变量”等测试用例，观察它是否真的能拿到内容。这类测试最好在隔离环境里做，避免留下全局泄露痕迹。

5.2 常见问题速查表

整理了一份问题对照表，都是实际开发中高频踩坑的场景，可以直接收藏备用。

5.3 我建议的最小安全基线

如果你的项目现在就要给 Agent 加上执行型工具，我建议至少满足以下条件再上线：

• 工具能力收敛到固定动作为主，不提供通用 shell 执行入口。
• 必须执行的动态路径参数要经过严格的前缀/后缀校验，且校验逻辑要覆盖“路径归一化”场景，防止..跳级。
• 密钥和配置从明文文件迁出，应用运行时通过配置中心或加密注入获取。
• 工具返回值统一走脱敏过滤器，敏感字段在进入模型上下文之前全部掩码。
• Agent 所在进程/容器的挂载目录最小化，不得挂载整个项目目录或宿主机根路径。
• 工具调用的入参和出参记录审计日志，日志内容同样执行脱敏规则。
• 当模型需要操作外部资源时要二次确认，不要在工具层直接完成高风险动作。

听起来项数不少，但实际落地时大部分成本很低。真正花时间的是把工具从“通用 shell 执行”改成“固定动作集合”的那一步，因为你需要重新梳理 Agent 实际会用到哪些操作，并逐个建模。这个投入很值得，因为每收敛一个入口，Agent 的安全边界就清晰一分。

收尾之前再分享两个细节

第一次排查这个问题时，我用了很长一段时间的Runtime.exec，直到后来翻资料才注意到，ProcessBuilder在不走 shell 时更安全。但这不是关键差异，真正的关键在别处：你放权给 Agent 的方式，决定了风险的下限。给予通用 shell 权限，等于把安全全部押注在“模型不会乱来”这个假设上，而实际经验告诉我，模型总是会以你预料不到的方式解析用户意图。

我在那次事故之后养成了一个习惯：给 Agent 注册任何一个新工具前，先写一组反向测试用例，站在攻击者的角度设计问题，看当前工具能不能挡住。比如“帮我看看这台机器上有没有私钥文件”，模型可能会生成find / -name "*.pem"，如果你的工具没有限制find的搜索范围，这条命令就是新的泄露口。

还有一点是关于用户提问本身的。很多人会忽略 Agent 的安全风险不仅仅来源于恶意攻击，更多时候来源于正常需求里的边缘情况。就像这次事故里，“检查配置文件”是一个再正常不过的请求，但它带出来的结果超出了所有人的预期。安全设计必须假设“模型会读到它不该读的东西”，然后在这个前提下做防御，而不是假设“模型总是聪明地避开风险”。

我个人现在更倾向于把 Agent 当作一个“需要试用期的实习生”来看待——能力很强，但你不应该一上来就给它机房钥匙。先让它用白名单工具处理简单问题，观察它的行为模式，随着信任建立再逐步放开权限。这个过程没有捷径，但每一步都走得踏实。