用 Firecracker 微 VM 给 AI Agent 越权隔离

dev.to · AI#AI Agent#安全沙箱#云原生

Editor brief · 编辑速览

在 Krova Cloud 上用 Firecracker 微 VM 运行 LLM Agent，无公网 IP，按分钟计费，用完即销毁——容器无法提供的内核级隔离。

文章思维导图

Knowledge map

拖拽缩放

Full translation

完整中文译文

容器为何不够用

标准建议——"在 Docker 容器里跑 agent，降低权限"——在一种特定情况下会失效：容器共享内核。该主机上的每一个容器，都与邻居容器只隔一个内核 bug 的距离。这就是 Firecracker 存在的意义。AWS 建造它就是为了大规模运行别人的代码，因为 namespace 根本不是真正的边界。

所以，这个 agent 得到的是一台 microVM。自己的内核，自己的 rootfs，一切都是自己的。

初始化配置

在 Krova Cloud 上，每台 microVM 被称为一个 Cube。整个供给流程只需一条命令：

npm i -g @krovacloud/cli

krova cubes create agent-1 --cpu 2 --ram 4 --disk 40 --image ubuntu-24.04
# ✓ Cube provisioned  ·  booted in 0.9s

krova ssh agent-1
root@agent-1:~#

这里有两件事至关重要：

无公网 IP。 Cube 位于私有 NAT 网络中。没有地址可供扫描，没有暴露在互联网上的 22 端口，没有入站攻击面。在内部自行验证：

root@agent-1:~# ip -brief addr
lo               UNKNOWN        127.0.0.1/8
eth0             UP             10.0.x.x/24   # private. that's it.

root@agent-1:~# ss -tlnp
# only listeners *you* started — nothing is reachable from outside

流量只从你显式打开的端口进入，而且可以设置 IP 白名单。对于 agent 主机，我什么都不开。

可随时销毁。 启动不到一秒，按分钟计费。所以我不再把它当宠物来养：每个 agent 会话分配一个新的 Cube，会话结束时直接删除。不留残余的 cron 任务，不在长期运行的环境中留下过期凭证。

我实际使用的会话生命周期

set -euo pipefail

CUBE="agent-$(date +%s)"

# fresh box per session
krova cubes create "$CUBE" --cpu 2 --ram 4 --disk 40 --image ubuntu-24.04

# credentials injected at runtime as short-lived env vars,
# never baked into the image
krova ssh "$CUBE"

# session over? nothing to clean up
krova cubes delete "$CUBE"

当我从 CI 而非笔记本自动化执行时，用的是 v1 API——包含幂等性 key，这样重试不会导致重复供给：

curl -X POST https://krova.cloud/api/v1/spaces/$SPACE/cubes \
  -H "X-API-KEY: $KROVA_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "name": "agent-session-42",
    "image": "ubuntu-24.04",
    "resources": { "vcpu": 2, "ramGb": 4, "diskGb": 40 }
  }'

一个 20 分钟的会话，运行在 2 vCPU / 4 GB Cube 上，花费几分钱，按分钟计费。比喝运行期间的那杯咖啡还便宜。

我仍然不信任的部分（请读这一节）

隔离不等于安全。直说了吧，因为这里是人容易踩坑的地方：

microVM 阻止 agent 逃逸到你的其他工作负载。它不阻止 agent 搞坏自己的机器。它不阻止 agent 使用你交给它的凭证。AdministratorAccess AWS 密钥 + 坚不可摧的沙箱 = 一台非常安全、正在犯一个非常昂贵错误的机器。

所以那些无聊的控制手段仍然适用，在 VM 之上：

范围限定、短期有效的 token——运行时注入，绝不写入镜像
不与任何重要内容共享卷
在必要的地方限制出站流量（agent 不需要你的整个网络）

VM 是爆炸半径。凭证范围控制才是真正的安全手段。Krova 给了你边界——内部的卫生工作还是你自己的事，和任何自托管机器一样。

任何告诉你"沙箱隔离就完事了"的人，在卖的东西有问题。

总结

我以前以为 agent 安全是一个模型问题。其中很大一部分是一个基础设施问题，用 2018 年代的技术今天就能解决：

给它一个真正的边界（自己的内核，不是 namespace）给它一个不存在的地址（无公网 IP）用完就扔掉

这就是全部诀窍。

你现在是如何对 agent 进行沙箱隔离的——容器、microVM，还是"靠感觉和希望"？有没有人实际测量过自己当前 setup 的逃逸风险？希望在评论区交流经验。