终端命令执行是 MCP 中安全风险最高的能力，必须通过白名单、沙箱、确认和审计四层防护。

MCP 可以让 AI Agent 直接执行终端命令（Shell commands），这是对 Agent 能力的极大扩展——它能操作文件系统、管理进程、调用系统工具，甚至部署服务。但这也是 MCP 中风险最高的场景：一条错误命令可以删除整个项目、泄露密钥，或破坏系统环境。

一、基本定义

MCP 终端命令执行是指通过 MCP Server 将操作系统的命令行能力暴露给 AI 应用。核心设计问题：

• 哪些命令应该允许执行
• 如何防止命令注入和越权操作
• 如何在执行后捕获结果并反馈给模型
• 如何在出错时及时中止并回滚

与 MCP与数据库 类似，终端命令接入的风险远高于一般 MCP 场景。不同之处在于：数据库操作通常有事务和权限边界，而终端命令直接作用于操作系统，一旦执行往往不可逆。

二、核心操作

MCP 终端命令 Server 需要支持以下核心能力：

操作	说明	安全关注点
执行命令	将命令发送给 Shell 执行	命令白名单、参数校验
获取 stdout	读取标准输出	输出大小限制、敏感信息过滤
获取 stderr	读取标准错误	错误信息泄露
设置工作目录	指定命令执行的 cwd	目录范围限制
设置环境变量	传递 env vars	敏感变量过滤
超时控制	防止命令长时间运行	资源耗尽防护
取消执行	强制终止进程	进程清理、资源释放

三、Tool 设计

典型的终端命令 MCP Server 应提供以下 Tool：

3.1 execute_command

Tool: execute_command
参数:
  - command: string        # 要执行的命令
  - cwd: string?           # 工作目录（可选，有默认限制）
  - timeout: number?       # 超时时间（秒），默认 30
  - env: map?              # 额外环境变量（可选）
返回:
  - process_id: string     # 进程 ID，用于后续操作
  - status: "running" | "completed" | "failed"
  - stdout: string         # 标准输出（截断后）
  - stderr: string         # 标准错误（截断后）
  - exit_code: number      # 退出码

3.2 read_output

Tool: read_output
参数:
  - process_id: string     # 进程 ID
  - offset: number?        # 读取偏移量（用于增量读取）
返回:
  - stdout: string
  - stderr: string
  - status: "running" | "completed" | "failed"

3.3 kill_process

Tool: kill_process
参数:
  - process_id: string     # 进程 ID
  - signal: string?        # 信号类型，默认 SIGTERM
返回:
  - success: boolean
  - message: string

这种三 Tool 设计将命令执行、输出读取、进程控制分离，使 Agent 能分步操作长时间运行的命令，而不是被迫等待执行完毕。

四、安全设计（极其重要）

终端命令执行的安全设计是本文的核心。以下从多个维度展开。

4.1 命令白名单

必须维护一份显式允许的命令列表：

白名单示例：
✅ ls, cat, grep, find, head, tail, wc
✅ mkdir, touch, cp, mv
✅ git status, git log, git diff
✅ npm test, npm run lint
✅ python -c（受限模式）
✅ echo, pwd, which, whoami

黑名单示例（绝对禁止）：
❌ rm -rf /
❌ sudo *
❌ chmod 777 *
❌ curl | bash
❌ wget | sh
❌ eval, exec（Shell 内建）
❌ dd, mkfs, fdisk

白名单策略有两种实现方式：

• 黑名单模式（不推荐）：列出禁止的命令。容易被绕过（例如通过路径、别名、管道组合）。
• 白名单模式（推荐）：只允许明确列出的命令。更安全，但需要维护。

4.2 参数校验与命令注入防护

命令注入是终端命令执行中最危险的攻击向量：

攻击示例：
用户输入: "hello"
恶意命令: ls; rm -rf /
拼接结果: echo "hello"; rm -rf /

防御方式：
1. 参数化执行（不拼接 Shell 字符串）
2. 使用 exec 而非 system()
3. 对参数进行 Shell 转义
4. 禁止 Shell 元字符（;, |, &, $(), ``）

# 错误示范：Shell 拼接
os.system(f"grep {user_input} file.txt")

# 正确方式：参数化执行
subprocess.run(["grep", user_input, "file.txt"], shell=False)

4.3 沙箱执行

所有命令必须在沙箱中执行，可选方案见第六节。

4.4 工作目录限制

限制规则：
- cwd 必须在允许的项目目录范围内
- 禁止 cd 到系统目录（/etc, /usr, /）
- 禁止使用 .. 逃逸出允许范围
- 解析 realpath 后验证（防止符号链接绕过）

4.5 环境变量过滤

过滤规则：
- 不传递 HOST 的敏感环境变量
- 明确过滤: API_KEY, SECRET, TOKEN, PASSWORD, PRIVATE_KEY
- 只传递命令所需的最小环境变量集
- 使用白名单模式传递 env

4.6 执行时间与输出限制

限制规则：
- 默认超时: 30 秒
- 最大超时: 300 秒（需显式授权）
- stdout 最大: 10KB（超出截断）
- stderr 最大: 5KB（超出截断）
- 并发进程数限制: 3-5 个

五、风险分级

不同命令的风险等级不同，应采取不同的控制策略：

风险等级	命令类型	示例	控制策略
低风险	只读命令	ls, cat, grep, head	直接执行，记录日志
中风险	创建类命令	mkdir, touch	需要用户确认，限制位置
高风险	修改类命令	mv, cp, chmod	需要用户确认，备份原文件
极高风险	删除/系统命令	rm, sudo, kill, dd	默认禁止，特殊授权才能执行

六、用户确认机制

对于中风险及以上的命令，必须引入用户确认（Human-in-the-Loop）：

确认流程：
1. Agent 生成命令 → MCP Server 解析风险等级
2. 低风险 → 直接执行
3. 中风险 → 展示命令内容，等待用户 approve
4. 高风险 → 展示命令 + 影响分析 + 回滚方案
5. 极高风险 → 拒绝执行，除非用户显式解除限制

确认信息展示：
- 完整命令内容
- 预期效果
- 影响范围（涉及的文件/目录）
- 风险等级标识
- 是否可回滚

确认机制的实现方式：

• Client 端确认：在 MCP Client 弹出确认对话框，用户点击确认后才发送执行请求
• Server 端确认：MCP Server 内部拦截，向用户请求确认（需要额外的通信通道）
• 混合模式（推荐）：Client 端展示，Server 端校验

七、审计日志

每一次命令执行都必须记录完整的审计日志：

审计日志字段：
{
  "timestamp": "2026-07-23T10:30:00Z",
  "session_id": "abc123",
  "agent_id": "claude-agent-1",
  "command": "git status",
  "cwd": "/Users/dimoo/project",
  "risk_level": "low",
  "user_confirmed": false,
  "exit_code": 0,
  "stdout_length": 256,
  "stderr_length": 0,
  "duration_ms": 45,
  "sandbox": "docker",
  "status": "success"
}

审计日志的价值：

• 事后追溯：出问题时定位哪条命令导致了异常
• 行为分析：发现 Agent 的异常行为模式
• 合规要求：满足安全审计和合规检查
• 改进依据：根据日志调整白名单和风险策略

八、回滚策略

对于修改类操作，需要提前准备回滚方案：

回滚策略：
1. 执行前自动备份
   - cp → 备份源文件
   - mv → 记录原始路径
   - 批量操作 → 生成回滚脚本

2. 文件系统快照
   - 使用 git 管理的项目：操作前自动 commit
   - 非 git 项目：复制关键文件到临时目录

3. 回滚执行
   - 自动回滚：失败时自动恢复
   - 手动回滚：提供回滚命令供用户执行

九、沙箱方案

沙箱是终端命令执行的最后一道防线。即使白名单和参数校验被绕过，沙箱可以限制命令的实际影响范围。

9.1 Docker 容器（推荐）

优点：
- 完整的文件系统隔离
- 网络可以完全禁用
- 资源限制（CPU、内存）
- 执行完毕后可销毁，无残留

缺点：
- 启动开销（可预热镜像缓解）
- 需要 Docker 环境
- 宿主机文件挂载需要谨慎配置

9.2 VM 隔离

优点：
- 最强隔离级别
- 可以模拟完整操作系统环境

缺点：
- 资源开销最大
- 启动慢
- 维护成本高
- 适合特殊场景（安全研究、不可信代码执行）

9.3 chroot

优点：
- 轻量级，无需额外虚拟化
- 限制文件系统访问范围

缺点：
- 不是完整的安全隔离（可以逃逸）
- 需要 root 权限设置
- 不提供网络和进程隔离

9.4 受限 Shell

优点：
- 最简单的实现方式
- 限制可用命令集
- 限制文件访问路径

缺点：
- 安全性最弱
- 可以通过多种方式绕过
- 只适合作为辅助手段

实现方式：
- rbash (restricted bash)
- 自定义 Shell wrapper
- PATH 限制 + 命令白名单

沙箱方案对比

方案	隔离强度	资源开销	实现复杂度	推荐场景
Docker 容器	强	中	中	通用场景（推荐）
VM 隔离	最强	高	高	不可信代码
chroot	中	低	低	轻量限制
受限 Shell	弱	极低	极低	辅助手段

十、命令执行安全流程

十一、设计原则

1. 最小权限原则：只暴露必要的命令，默认拒绝一切
2. 纵深防御原则：白名单 + 参数校验 + 沙箱 + 审计，多层防护
3. 用户知情原则：中高风险操作必须获得用户明确确认
4. 可回滚原则：修改类操作必须有回滚方案
5. 可审计原则：每一次执行都必须有完整的日志记录
6. 失败安全原则：任何异常都应导致命令被终止，而非继续执行

十二、常见误区

误区	正确做法
认为黑名单足够安全	必须使用白名单，黑名单容易被绕过
只校验命令名，忽略参数	参数中可能包含注入攻击
依赖 PATH 查找命令	必须使用绝对路径，防止 PATH 劫持
认为本地执行不需要沙箱	本地执行同样可能破坏系统
超时设置为无限	必须设置合理的超时，防止资源耗尽
传递所有环境变量给命令	必须过滤敏感变量，只传递必要的环境变量
不记录审计日志	每次执行都必须记录，便于追溯和分析
直接拼接 Shell 字符串	必须使用参数化执行，避免 Shell 注入

十三、检查清单

• 命令是否通过白名单验证？
• 参数是否经过安全校验和转义？
• 是否使用绝对路径执行命令？
• 工作目录是否在允许范围内？
• 环境变量是否已过滤敏感信息？
• 是否设置了合理的超时时间？
• 输出是否限制了大小并截断？
• 中高风险命令是否经过用户确认？
• 是否在沙箱中执行？
• 是否记录了完整的审计日志？
• 修改类操作是否有备份和回滚方案？
• 并发进程数是否有限制？
• 是否禁止了 Shell 元字符和管道组合？
• 异常情况下进程是否能被正确终止和清理？

十四、关联笔记

• MCP基础 - MCP 协议的核心概念
• MCP Server设计 - Server 端的设计模式和最佳实践
• MCP安全边界 - MCP 整体安全框架
• MCP权限设计 - 权限控制的设计原则
• MCP与数据库 - 类似的高风险接入场景
• MCP与Obsidian - 文件系统操作的轻量级场景
• MCP与GitHub - 通过 CLI 操作 GitHub 的场景