Skip to content

필사 모드: AI 编码智能体沙箱化:安全代码执行隔离与安全运维指南

中文
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

AI Coding Agent Sandbox Security

为什么沙箱化现在成为必需

2026 年的 AI 编码智能体已经超越了单纯的代码补全,能够自主执行文件生成、shell 命令执行、网络请求。Cursor、Claude Code、GitHub Copilot 等工具以与开发者相同的权限运行,这意味着仅凭一条恶意提示词,就有可能窃取 SSH 密钥或泄露 AWS 凭证。根据 NVIDIA AI Red Team 2026 年 1 月发布的报告,应用沙箱的智能体能将安全事故减少 90%

本文将从 macOS sandbox-exec 到容器、MicroVM,结合代码梳理四种隔离技术的原理与实战应用方法


AI 编码智能体的安全威胁模型

智能体所拥有权限的风险性

AI 编码智能体会原样继承运行它的用户的权限,这就打开了以下攻击向量。

威胁类型说明实际案例
凭证窃取访问 .aws、.ssh 目录智能体读取配置文件导致密钥泄露
代码注入篡改 .cursorrules 文件Rules File Backdoor 攻击(Pillar Security 发现)
MCP 服务器劫持恶意 MCP 初始化命令智能体启动时被注入恶意 hook
网络泄露向外部服务器发送数据代码审查过程中源代码被外传
文件系统破坏删除/修改项目外文件YOLO 模式下发生意外的文件删除

YOLO 模式的真正风险

Cursor 的 Auto-run(原 YOLO 模式)是一种智能体无需用户批准即可执行多步操作的模式。虽然有允许列表(allowlist)和拒绝列表(denylist)配置,但只要智能体能够执行任意命令,这些防御手段就可能被绕过。根据 Backslash Security 的研究(2025),存在通过链接已允许的工具从而达到被拒绝命令的间接执行攻击。


隔离技术对比:该选择哪种沙箱

四种隔离技术对比表

标准sandbox-exec (macOS)Docker 容器gVisorFirecracker MicroVM
隔离级别进程级命名空间/cgroup用户空间内核硬件虚拟化
内核共享共享主机内核共享主机内核用户空间内核独立客户机内核
启动时间即时(毫秒以下)秒级秒级125ms 以下
内存开销最小中等每个 VM 5MB
安全强度中等低-中等最高
主机 OS仅 macOSLinux/macOS/Windows仅 Linux仅 Linux
适用对象本地开发智能体开发/预发布K8s 生产环境生产环境多租户

选择指南

  • 本地 macOS 开发:sandbox-exec 或 Agent Safehouse
  • CI/CD 流水线:Docker + seccomp 配置文件
  • Kubernetes 生产环境:gVisor(配置 RuntimeClass)
  • 多租户 SaaS:Firecracker MicroVM 或 Kata Containers

实战 1:macOS sandbox-exec 与 Agent Safehouse

sandbox-exec 基本原理

macOS 的 sandbox-exec 使用 Apple 的 Seatbelt 框架,在内核层面拦截系统调用。这与 App Store 应用所使用的技术相同。配置文件使用 Scheme(LISP 系)语法编写。

编写基本的 sandbox-exec 配置文件

下面是一个为 AI 智能体设计的 deny-first 沙箱配置文件示例。

(version 1)
(deny default)

;; 允许读取基本系统库
(allow file-read*
  (subpath "/usr/lib")
  (subpath "/usr/share")
  (subpath "/System/Library")
  (subpath "/Library/Frameworks")
  (subpath "/private/var/db/dyld"))

;; 仅允许读写项目目录
(allow file-read* file-write*
  (subpath "/Users/dev/projects/my-app"))

;; 限制可执行的二进制文件
(allow process-exec
  (literal "/usr/bin/git")
  (literal "/usr/bin/python3")
  (literal "/usr/local/bin/node"))

;; 完全阻断网络
(deny network*)

;; 显式阻断敏感目录
(deny file-read* file-write*
  (subpath "/Users/dev/.ssh")
  (subpath "/Users/dev/.aws")
  (subpath "/Users/dev/.gnupg")
  (subpath "/Users/dev/.config/gcloud"))

;; 允许进程 fork(构建/测试所需)
(allow process-fork)
(allow signal (target self))

执行方法如下。

# 用 sandbox-exec 运行智能体
sandbox-exec -f /path/to/agent-sandbox.sb -- claude --dangerously-skip-permissions

# 确认配置文件已生效(拦截日志)
log stream --predicate 'subsystem == "com.apple.sandbox"' --level debug

使用 Agent Safehouse

Agent Safehouse 对上面的 sandbox-exec 进行了封装,提供了一个易用的 CLI。它完全用纯 Bash 脚本实现,因此可以直接阅读并审计全部代码。

# 安装 Agent Safehouse
git clone https://github.com/eugene1g/agent-safehouse.git
cd agent-safehouse
chmod +x safehouse

# 在项目目录中运行智能体
cd ~/projects/my-app
safehouse claude --dangerously-skip-permissions

# 使用自定义策略运行
safehouse --policy custom-policy.sb -- claude

Agent Safehouse 的默认策略遵循以下原则。

  • Deny-first:默认拦截所有访问,仅允许必要的部分
  • 限定项目范围:只能访问当前工作目录及其子目录
  • 保护敏感文件:阻断 .ssh、.aws、.gnupg 等凭证目录
  • 网络控制:仅在必要时才允许网络访问

也可以按机器添加例外策略。

;; machine-local-policy.sb - 机器专属设置
(allow file-read*
  (home-literal "/.gitignore_global")
  (home-subpath "/Library/Application Support/Claude"))

;; 允许访问特定共享卷
(allow file-read*
  (subpath "/Volumes/Shared/Engineering"))

实战 2:基于 Docker 容器的隔离

强化安全性的 Docker 配置

默认的 Docker 容器会共享主机内核,因此不足以对 AI 智能体做到完全隔离。需要按以下方式强化安全性。

# docker-compose.yml - AI 智能体隔离环境
version: '3.8'

services:
  ai-agent:
    build:
      context: .
      dockerfile: Dockerfile.agent
    security_opt:
      - no-new-privileges:true
      - seccomp:seccomp-profile.json
      - apparmor:agent-profile
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    read_only: true
    tmpfs:
      - /tmp:size=512M,noexec,nosuid
    volumes:
      - ./project:/workspace:rw
      # 禁止挂载敏感目录
    networks:
      - agent-isolated
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 4G
          pids: 256
        reservations:
          cpus: '0.5'
          memory: 512M
    environment:
      - HOME=/workspace
      # API 密钥从密钥管理器注入
    user: '1000:1000'

networks:
  agent-isolated:
    driver: bridge
    internal: true # 阻断外部网络

用 seccomp 配置文件限制系统调用

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "defaultErrnoRet": 1,
  "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_AARCH64"],
  "syscalls": [
    {
      "names": [
        "read",
        "write",
        "open",
        "close",
        "stat",
        "fstat",
        "lstat",
        "poll",
        "lseek",
        "mmap",
        "mprotect",
        "munmap",
        "brk",
        "access",
        "pipe",
        "select",
        "sched_yield",
        "clone",
        "fork",
        "vfork",
        "execve",
        "exit",
        "wait4",
        "kill",
        "uname",
        "fcntl",
        "flock",
        "fsync",
        "fdatasync",
        "truncate",
        "getdents",
        "getcwd",
        "chdir",
        "mkdir",
        "rmdir",
        "unlink",
        "readlink",
        "chmod",
        "chown",
        "getuid",
        "getgid",
        "geteuid",
        "getegid",
        "getpid",
        "getppid",
        "socket",
        "connect",
        "sendto",
        "recvfrom",
        "bind",
        "listen",
        "accept",
        "arch_prctl",
        "set_tid_address",
        "set_robust_list",
        "futex",
        "clock_gettime",
        "epoll_create",
        "epoll_ctl",
        "epoll_wait",
        "openat",
        "newfstatat",
        "readlinkat",
        "getrandom",
        "pread64",
        "pwrite64"
      ],
      "action": "SCMP_ACT_ALLOW"
    },
    {
      "names": [
        "ptrace",
        "mount",
        "umount2",
        "pivot_root",
        "swapon",
        "swapoff",
        "reboot",
        "sethostname",
        "setdomainname",
        "init_module",
        "delete_module",
        "kexec_load",
        "perf_event_open"
      ],
      "action": "SCMP_ACT_ERRNO",
      "errnoRet": 1
    }
  ]
}

实战 3:用 Firecracker MicroVM 实现硬件级隔离

Firecracker 适合 AI 智能体的原因

Firecracker 是 AWS Lambda 与 Fargate 的底层技术,以下特性使其非常适合用于 AI 智能体隔离。

  • 独立的客户机内核:与主机内核完全分离,无法通过内核漏洞逃逸
  • 125ms 以下启动:接近容器级别的启动速度
  • 每个 VM 5MB 内存:可同时运行数百个智能体
  • 最小化设备模型:将攻击面(attack surface)最小化

配置 Firecracker 智能体沙箱

#!/bin/bash
# firecracker-agent-sandbox.sh
# 用 Firecracker MicroVM 隔离运行 AI 智能体

FIRECRACKER_BIN="/usr/local/bin/firecracker"
KERNEL_PATH="/opt/firecracker/vmlinux"
ROOTFS_PATH="/opt/firecracker/agent-rootfs.ext4"
SOCKET_PATH="/tmp/firecracker-agent.socket"
API_URL="http://localhost"

# 清理已存在的 socket
rm -f "$SOCKET_PATH"

# 启动 Firecracker 进程
$FIRECRACKER_BIN --api-sock "$SOCKET_PATH" &
FC_PID=$!
sleep 0.5

# 配置内核
curl --unix-socket "$SOCKET_PATH" -X PUT "$API_URL/boot-source" \
  -H "Content-Type: application/json" \
  -d '{
    "kernel_image_path": "'"$KERNEL_PATH"'",
    "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
  }'

# 根文件系统(智能体镜像)
curl --unix-socket "$SOCKET_PATH" -X PUT "$API_URL/drives/rootfs" \
  -H "Content-Type: application/json" \
  -d '{
    "drive_id": "rootfs",
    "path_on_host": "'"$ROOTFS_PATH"'",
    "is_root_device": true,
    "is_read_only": false
  }'

# 资源限制(2 vCPU,2GB RAM)
curl --unix-socket "$SOCKET_PATH" -X PUT "$API_URL/machine-config" \
  -H "Content-Type: application/json" \
  -d '{
    "vcpu_count": 2,
    "mem_size_mib": 2048
  }'

# 网络接口(隔离网络)
curl --unix-socket "$SOCKET_PATH" -X PUT "$API_URL/network-interfaces/eth0" \
  -H "Content-Type: application/json" \
  -d '{
    "iface_id": "eth0",
    "guest_mac": "AA:FC:00:00:00:01",
    "host_dev_name": "tap-agent0"
  }'

# 配置 Rate limiter(限制网络带宽)
curl --unix-socket "$SOCKET_PATH" -X PATCH "$API_URL/network-interfaces/eth0" \
  -H "Content-Type: application/json" \
  -d '{
    "iface_id": "eth0",
    "rx_rate_limiter": {
      "bandwidth": { "size": 10485760, "refill_time": 1000 },
      "ops": { "size": 1000, "refill_time": 1000 }
    },
    "tx_rate_limiter": {
      "bandwidth": { "size": 10485760, "refill_time": 1000 },
      "ops": { "size": 1000, "refill_time": 1000 }
    }
  }'

# 启动 MicroVM
curl --unix-socket "$SOCKET_PATH" -X PUT "$API_URL/actions" \
  -H "Content-Type: application/json" \
  -d '{ "action_type": "InstanceStart" }'

echo "Firecracker MicroVM started (PID: $FC_PID)"
echo "Agent is running in isolated VM"

# 任务完成后关闭 VM
cleanup() {
  kill "$FC_PID" 2>/dev/null
  rm -f "$SOCKET_PATH"
  echo "MicroVM destroyed - host remains untouched"
}
trap cleanup EXIT

实战 4:Kubernetes + gVisor 生产环境配置

GKE Agent Sandbox 配置

Google Kubernetes Engine(GKE)以 RuntimeClass 的形式提供基于 gVisor 的 Agent Sandbox。

# gvisor-runtime-class.yaml
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
scheduling:
  nodeSelector:
    sandbox.gke.io/runtime: gvisor

---
# agent-sandbox-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: ai-coding-agent
  labels:
    app: coding-agent
    sandbox: gvisor
spec:
  runtimeClassName: gvisor
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: agent
      image: ai-coding-agent:latest
      resources:
        limits:
          cpu: '2'
          memory: '4Gi'
          ephemeral-storage: '10Gi'
        requests:
          cpu: '500m'
          memory: '1Gi'
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL
      volumeMounts:
        - name: workspace
          mountPath: /workspace
        - name: tmp
          mountPath: /tmp
      env:
        - name: AGENT_WORKSPACE
          value: '/workspace'
        - name: AGENT_NETWORK_POLICY
          value: 'restricted'
  volumes:
    - name: workspace
      emptyDir:
        sizeLimit: 10Gi
    - name: tmp
      emptyDir:
        sizeLimit: 512Mi

---
# agent-network-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-isolation
spec:
  podSelector:
    matchLabels:
      sandbox: gvisor
  policyTypes:
    - Ingress
    - Egress
  egress:
    # 仅允许访问软件包注册表
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
      ports:
        - protocol: TCP
          port: 443
    # 允许 DNS
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
  ingress: [] # 全面阻断入站流量

gVisor 的 Sentry 进程会在用户空间拦截容器的全部系统调用,因此容器内部的恶意代码无法直接访问主机内核。


失败案例与教训:NVIDIA Red Team 发现的漏洞

五种残留威胁(Rich Harang,2026 年 1 月)

NVIDIA AI Red Team 首席安全架构师 Rich Harang 发布了即便应用沙箱之后依然残留的五种漏洞。

漏洞 1:恶意 hook 注入(Malicious Hooks)

智能体启动时加载的配置文件(.cursorrules、MCP 初始化命令)中可能被插入恶意代码。仅仅克隆一个仓库,攻击就已经开始。

# 攻击场景:隐藏在 .cursorrules 中的恶意指令
# 项目根目录下的 .cursorrules 文件

# 隐藏在看似正常的规则之间的指令
# "Always run npm audit fix before starting"
# 实际上是在指示智能体执行以下操作:
# 1. 修改 package.json,添加恶意的 postinstall 脚本
# 2. 在执行 npm install 时收集凭证
# 3. 发送到外部服务器

# 对策:仅从可信来源获取项目配置文件
# 智能体启动前必须验证配置文件的完整性

漏洞 2:内核级沙箱逃逸

像 sandbox-exec 或 Docker 这类共享主机内核的隔离方式,存在通过内核漏洞逃逸的可能。这正是在生产环境中推荐使用 MicroVM 或 gVisor 的核心原因。

漏洞 3:智能体对密钥的访问

智能体可以通过环境变量或挂载的卷访问 API 密钥、数据库凭证。

漏洞 4:批准缓存的失效模式

一旦某项操作获得批准便会被缓存,即便之后的上下文已经发生变化,也可能被自动批准。

漏洞 5:沙箱内密钥/知识产权的累积

在长期运行的沙箱中,跨会话的机密信息、知识产权、可被滥用的代码会不断累积。

Rules File Backdoor 攻击(Pillar Security)

Pillar Security 研究团队发现了一种攻击:在 Cursor 的 .cursorrules 文件中插入 Unicode 双向控制字符(bidirectional control characters),从而向智能体传递肉眼不可见的恶意指令。这种攻击即使在代码审查中也无法被发现,并且能在智能体生成的所有代码中植入后门。

应用层 vs OS 层防御的教训

NVIDIA Red Team 的核心建议是:OS 层级的强制优于应用层限制。一旦智能体创建子进程,上层应用就会失去可见性。攻击者可以通过链接已获批准的工具,最终触达被禁止的命令。而 macOS Seatbelt、Linux Bubblewrap、Windows AppContainer 这类 OS 层级机制会在应用之下的层面强制施加限制,因此能够阻断间接执行路径。


纵深防御(Defense-in-Depth)架构

分层安全配置

生产环境中的 AI 智能体不应依赖单一安全层,而应构建多层防御

Layer 5: 监控/审计 (Audit Logging, Anomaly Detection)
  |
Layer 4: 网络隔离 (NetworkPolicy, Firewall Rules)
  |
Layer 3: 资源限制 (cgroups, CPU/Memory/PID limits)
  |
Layer 2: 权限范围界定 (RBAC, File Permission, Capability Drop)
  |
Layer 1: 执行隔离 (MicroVM / gVisor / sandbox-exec)
  |
Layer 0: 硬件 (TPM, Secure Boot, VT-x)

智能体权限策略配置示例

下面是一个按智能体细分权限进行管理的策略配置示例。

# agent-security-policy.yaml
# AI 编码智能体安全策略定义

policies:
  code-review-agent:
    description: '专用于代码审查的智能体'
    filesystem:
      read:
        - '/workspace/src'
        - '/workspace/tests'
        - '/workspace/package.json'
        - '/workspace/tsconfig.json'
      write: [] # 仅读取
      deny:
        - '/workspace/.env'
        - '/workspace/.env.local'
        - '/workspace/secrets'
    network:
      allow_outbound:
        - 'api.openai.com:443'
        - 'api.anthropic.com:443'
      deny_all_inbound: true
    process:
      allow_exec:
        - '/usr/bin/git'
        - '/usr/local/bin/node'
      deny_exec:
        - '/bin/sh'
        - '/bin/bash'
        - '/usr/bin/curl'
        - '/usr/bin/wget'
    resources:
      max_cpu: '1.0'
      max_memory: '2Gi'
      max_pids: 128
      max_file_size: '50Mi'

  development-agent:
    description: '开发工作智能体(受限写入)'
    filesystem:
      read:
        - '/workspace'
      write:
        - '/workspace/src'
        - '/workspace/tests'
        - '/workspace/docs'
      deny:
        - '/workspace/.env'
        - '/workspace/.git/hooks'
        - '/workspace/node_modules/.cache'
    network:
      allow_outbound:
        - 'registry.npmjs.org:443'
        - 'api.openai.com:443'
      deny_all_inbound: true
    process:
      allow_exec:
        - '/usr/bin/git'
        - '/usr/local/bin/node'
        - '/usr/local/bin/npm'
        - '/usr/bin/python3'
      deny_exec:
        - '/usr/bin/ssh'
        - '/usr/bin/scp'
    resources:
      max_cpu: '2.0'
      max_memory: '4Gi'
      max_pids: 256
      max_file_size: '100Mi'
    audit:
      log_all_file_writes: true
      log_all_network_requests: true
      alert_on_denied_access: true

Cursor 按平台实现的沙箱化

2026 年初,Cursor 全面引入了智能体沙箱化。按平台的具体实现如下。

平台隔离技术特点
macOSSeatbelt (sandbox-exec)内核级系统调用拦截
LinuxLandlock + seccomp组合内核安全模块
WindowsWSL2 内部 Linux 沙箱利用 WSL2 VM 边界

Cursor 的沙箱智能体按以下方式运行。

  1. 在沙箱内自由执行(文件读写、构建、测试)
  2. 请求越过沙箱边界时,向用户显示权限请求
  3. 互联网访问主要属于需要请求权限的对象

运维检查清单

引入沙箱化前的检查清单

  • 是否已明确定义智能体需要访问的文件/目录范围
  • 是否已阻断对 .ssh、.aws、.gnupg 等凭证目录的访问
  • 是否已定义网络访问策略(出站允许列表)
  • 是否已限制可执行的二进制文件列表
  • 是否已设置 CPU、内存、PID 数等资源上限

运维中的检查清单

  • 是否正在收集并监控沙箱拦截日志
  • 是否正在对智能体的文件写入操作进行审计(audit)日志记录
  • 是否已针对异常网络请求设置告警
  • 是否定期审查并更新沙箱策略
  • 智能体会话结束时是否会彻底删除临时数据

安全事故响应检查清单

  • 是否具备检测沙箱逃逸尝试的机制
  • 发现可疑活动时能否立即终止智能体
  • 事故发生时是否有足够的日志来掌握影响范围
  • 是否有保存 MicroVM/容器取证快照的流程
  • 是否已定义事故后的策略更新流程

结语:最小权限原则的现代应用

AI 编码智能体的沙箱化不是可选项,而是必需项。核心原则总结如下。

  1. Deny-first 策略:默认拦截所有访问,仅显式允许必要的部分
  2. OS 层级强制:应用层限制可被绕过,因此需应用内核/硬件层级的隔离
  3. 纵深防御:不依赖单一层,而是构建多层安全体系
  4. 一次性环境:会话结束时销毁环境,防止密钥累积
  5. 持续审计:监控拦截日志并定期更新策略

建议在本地开发中先从 Agent Safehouse 起步,再逐步过渡到生产环境中的 Firecracker MicroVM 或 gVisor。重要的是现在就开始


参考资料

현재 단락 (1/502)

2026 年的 AI 编码智能体已经超越了单纯的代码补全,能够自主执行**文件生成、shell 命令执行、网络请求**。Cursor、Claude Code、GitHub Copilot 等工具以与开...

작성 글자: 0원문 글자: 13,426작성 단락: 0/502