在Fedora Linux上使用微虛擬機器沙盒化AI程式設計代理

AI程式設計代理（如Claude Code或Codex）每月都在變得更加強大，這無疑提升了生產力。然而，批准每一個命令很快變得令人厭煩。另一方面，允許代理在工作機器上隨意執行任何命令並非明智之舉——它們非常擅長使用kubectl探索你的生產叢集，或透過SSH在生產伺服器上遠端執行命令。

幸運的是，Linux發行版提供了豐富的程序隔離選項。你可以將代理作為完全不同的使用者執行，放在容器中，或部署在虛擬機器裡。本文展示瞭如何使用微虛擬機器（microVM）來沙盒化程式設計代理。

安全擔憂

以無人值守模式執行AI代理類似於執行不可信程式碼。儘管Anthropic或Google等公司並不試圖竊取憑據，但人們不斷提出新的攻擊向量，例如Slopsquatting或幾乎無處不在的提示注入。

程式設計代理本身帶有內建緩解措施，試圖拒絕提示注入。例如，輕量級沙盒技術（如Linux上的bwrap）是另一層防禦。但這仍然存在沙盒逃逸的問題，例如CVE-2026-39861就展示了跨平臺沙盒逃逸。

容器可以將代理隔離在自己的名稱空間中，但它們仍共享宿主核心。最近的核心漏洞導致了許可權提升（從普通使用者切換到root），表明容器作為安全邊界並不足夠。

探索微虛擬機器

首先，讓我們瞭解什麼是微虛擬機器。與任何虛擬機器一樣，它們擁有自己的核心，每個微虛擬機器一個。與傳統虛擬機器相比，它們啟動時間極短（數百毫秒），但缺乏完整虛擬機器的所有功能。

本文介紹了Podman的krun執行時用法。該方法提供了與容器相同的工作流程，但將每個容器作為微虛擬機器執行。首先安裝執行時：

dnf install crun-krun

要執行微虛擬機器，只需在終端中執行帶--runtime=krun的Podman命令：

podman run --runtime=krun --rm -it fedora:44 /bin/bash

注意事項

微虛擬機器不是普通容器，因此一些行為可能不同。首先，使用krun註解分配足夠的CPU和RAM；預設值過小可能導致OOM（記憶體不足）殺死。其次，確保libkrun版本≥1.8；舊版本有阻止程式設計代理中按Enter鍵的bug。第三，微虛擬機器忽略Dockerfile中的USER指令，始終以root身份啟動。需要手動切換使用者或在入口指令碼中設定。

案例研究：為Python專案沙盒化Claude Code

本節概述了一個使用uv管理的Python專案的簡單設定。它使用podman-compose將專案掛載到微虛擬機器中。與容器相比，此podman-compose需要額外的UID/GID轉換、SELinux標籤和硬體資源註解。最終設定與容器所需的非常相似。

安裝podman-compose：

dnf install podman-compose

設定包含三部分：Dockerfile、docker-compose.yaml和entrypoint.sh。

Dockerfile：基於Fedora:44，建立與宿主UID/GID匹配的非特權使用者，安裝uv和Claude Code，複製入口指令碼。注意將USER appuser放在最後，但krun會忽略它，因此入口指令碼會處理使用者切換。

docker-compose.yaml：定義服務claude，註解選擇krun執行時並指定硬體資源，設定user: "${HOST_UID}:${HOST_GID}"和userns_mode: keep-id實現UID/GID對映。卷標籤U,z分別處理遞迴chown和SELinux重新標記。

entrypoint.sh：檢查當前使用者，若不是appuser則先執行uv sync然後切換到appuser執行命令；若是appuser則直接執行。

執行設定

構建容器：

$ HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml build

建立外部卷並互動執行：

$ podman volume create claude-config
$ HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml run --rm claude

進入微虛擬機器後，可透過uname -a檢查核心差異。

自動化指令碼

可透過簡單指令碼將上述設定封裝為sandbox命令，支援init、build和run三個子命令。

警告：微虛擬機器並非絕對安全

微虛擬機器顯著提高了門檻，但並非完美隔離。請查閱libkrun安全模型文件。對於可能危險的軟體，建議使用完整虛擬機器或雲虛擬機器。

結論

微虛擬機器似乎是執行AI代理的“甜點”。它們提供了熟悉的容器工作流，但代理執行在超管理器背後的獨立核心上。本文基於Fedora Linux原生支援的Podman和krun執行時，但其他平臺也有眾多選項（例如dockersandbox）。

注意：本文由作者親自撰寫，使用Claude（Anthropic）最佳化語法和措辭，技術內容和所有宣告均為作者本人所有並經過測試。