没有沙箱，我不让 AI Agent 直接跑不可信代码，给你一套可落地的安全方案

阿监·前端工程化内容创作者 2026-07-14 0 阅读

没有沙箱，我不让 AI Agent 直接跑不可信代码，给你一套可落地的安全方案

导语

如果你的 AI Agent 会执行外部代码、Shell 命令、用户上传的脚本，它现在已经不是你唯一的边界了。Prompt 注入、恶意仓库文档、被污染的工具返回值，都可能让 Agent 在你不注意时执行高危命令。本文结合 2026 年的几起真实漏洞与生产方案，整理出一套可落地的安全执行策略。

正文

问题：Agent 的“手脚”太自由了

2026 年上半年最值得警惕的一课，是 CVE-2026-2256。ModelScope 的 MS-Agent 框架允许 Agent 调用 Shell 工具完成任务，但过滤逻辑采用了脆弱的拒绝列表。攻击者只需把恶意命令伪装成普通文本，就能绕过检查并在服务器上执行任意代码。这类漏洞的共性非常明显：Agent 被赋予了“执行能力”，却没有被放进一个“有限环境”。

另一个典型场景更贴近日常：你让 Agent 分析一个开源项目，它读取 README 后执行了其中一段 Python；你以为它只是在安装依赖，实际上这段代码已经在读取环境变量并把密钥上传到外部服务。

方案：先把 Agent 的“手脚”绑起来

真正可落地的做法不是相信模型会更“聪明”，而是从执行层做三层隔离。

第一层：最小权限。 Agent 运行的账号只给它完成任务必需的最小权限。需要写临时目录就给临时目录，需要访问网络就给域名白名单，不要给 root，不要给宿主机挂载卷。很多团队第一步就错了：为了省事直接复用开发账号。

第二层：运行时沙箱。 对不可信代码必须做内核级或容器级隔离。2026 年的主流选项已经比较清晰：

Firecracker / Kata Containers：内核级隔离，适合多租户和强合规场景，启动约 125ms。
gVisor：用户态内核，比普通 Docker 更稳，适合常规不可信任务。
Docker（加固配置）：最小化镜像 + 只读根文件系统 + 网络策略，成本最低，适合内部工具。
E2B / AgentSandbox / Cube Sandbox：面向 Agent 的托管沙箱，开箱即用，适合快速落地。

第三层：执行前校验。 在代码真正跑起来之前，再做一次静态规则检查。常见做法包括：禁止 rm -rf /、curl | sh、subprocess.run(shell=True) 等高危模式；对上传文件做类型与大小限制；不允许 Agent 动态安装未知系统包。

代码：一个最小可运行的沙箱执行封装

下面示例用 Docker 风格做最小隔离，只给 Agent 一个临时工作目录和有限网络，执行完自动销毁。

import os
import subprocess
import tempfile
import shutil

UNSAFE_PATTERNS = [
    "rm -rf /",
    "rm -rf /*",
    "curl |",
    "wget |",
    "subprocess.run(",
    "os.system(",
    "exec(",
    "eval(",
    "base64",
]

def guard_input(code: str) -> bool:
    lowered = code.lower()
    return any(pattern in lowered for pattern in UNSAFE_PATTERNS)

def run_in_sandbox(code: str, timeout: int = 30):
    if guard_input(code):
        return {"ok": False, "error": "命中危险模式，已拦截"}

    workdir = tempfile.mkdtemp(prefix="agent-sandbox-")
    script_path = os.path.join(workdir, "task.py")

    try:
        with open(script_path, "w", encoding="utf-8") as f:
            f.write(code)

        result = subprocess.run(
            [
                "docker", "run", "--rm",
                "--network", "none",
                "--read-only",
                "--tmpfs", "/tmp",
                "-v", f"{workdir}:/workspace",
                "python:3.12-slim",
                "python", "/workspace/task.py",
            ],
            capture_output=True,
            text=True,
            timeout=timeout,
        )
        return {
            "ok": True,
            "exit_code": result.returncode,
            "stdout": result.stdout[-4000:],
            "stderr": result.stderr[-4000:],
        }
    except subprocess.TimeoutExpired:
        return {"ok": False, "error": "执行超时"}
    finally:
        shutil.rmtree(workdir, ignore_errors=True)

这个例子不是生产级方案，但它把三层隔离都表达出来了：静态拦截、只读根文件系统、无网络、自动清理。真实生产里通常还要加资源配额和审计日志。

结论

Agent 的安全问题，本质上不是模型问题，是执行边界问题。对内部可信任务，最小权限 + 容器加固通常够用；对不可信输入、外部数据、用户上传脚本，必须走内核级沙箱 + 执行前校验。2026 年的实践已经足够明确：先想“出事时怎么止损”，再想“怎么让 Agent 更聪明”。

收尾

这周你可以落地的下一步：先盘点现有 Agent 的权限边界，再给所有“执行代码/命令”的入口加上最小权限策略。能做到这一点，就已经超过了大多数项目。

评论区

0 条评论

登录后可评论。

没有沙箱，我不让 AI Agent 直接跑不可信代码，给你一套可落地的安全方案