安全部署 AI 代理

Claude Code 和 Agent SDK 是強大的工具，可以代替您執行程式碼、存取檔案並與外部服務互動。與任何具有這些功能的工具一樣，周全地部署它們可確保您在獲得好處的同時維持適當的控制。

與遵循預定程式碼路徑的傳統軟體不同，這些工具會根據上下文和目標動態生成其操作。這種靈活性正是它們有用的原因，但這也意味著它們的行為可能受到所處理內容的影響：檔案、網頁或使用者輸入。這有時被稱為提示注入。例如，如果一個儲存庫的 README 包含不尋常的指令，Claude Code 可能會以操作者未預期的方式將這些指令納入其操作中。本指南涵蓋了降低此風險的實用方法。

好消息是，保護代理部署不需要特殊的基礎設施。適用於執行任何半信任程式碼的相同原則在此同樣適用：隔離、最小權限和縱深防禦。Claude Code 包含多項安全功能，有助於解決常見問題，本指南將逐一介紹這些功能以及為有需要者提供的額外強化選項。

並非每個部署都需要最高安全性。在筆記型電腦上執行 Claude Code 的開發人員與在多租戶環境中處理客戶資料的公司有不同的需求。本指南提供從 Claude Code 內建安全功能到強化生產架構的各種選項，讓您可以選擇適合自己情況的方案。

我們要防範什麼？

代理可能因提示注入（嵌入在其處理內容中的指令）或模型錯誤而採取非預期的操作。Claude 模型被設計為能抵抗此類攻擊，正如我們在模型卡中分析的那樣，我們相信 Claude Opus 4.6 是目前最強健的前沿模型。

不過，縱深防禦仍然是良好的實踐。例如，如果代理處理了一個惡意檔案，該檔案指示它將客戶資料發送到外部伺服器，網路控制可以完全阻止該請求。

內建安全功能

Claude Code 包含多項安全功能來解決常見問題。完整詳情請參閱安全文件。

• 權限系統：每個工具和 bash 命令都可以配置為允許、阻止或提示使用者批准。使用 glob 模式建立規則，例如「允許所有 npm 命令」或「阻止任何包含 sudo 的命令」。組織可以設定適用於所有使用者的策略。請參閱存取控制和權限。
• 靜態分析：在執行 bash 命令之前，Claude Code 會執行靜態分析以識別潛在的風險操作。修改系統檔案或存取敏感目錄的命令會被標記並需要使用者明確批准。
• 網頁搜尋摘要：搜尋結果會被摘要而非將原始內容直接傳入上下文，降低來自惡意網頁內容的提示注入風險。
• 沙箱模式：Bash 命令可以在限制檔案系統和網路存取的沙箱環境中執行。詳情請參閱沙箱文件。

安全原則

對於需要超越 Claude Code 預設值進行額外強化的部署，以下原則指導可用的選項。

安全邊界

安全邊界將具有不同信任等級的元件分隔開來。對於高安全性部署，您可以將敏感資源（如憑證）放置在包含代理的邊界之外。如果代理環境中出現問題，該邊界之外的資源仍然受到保護。

例如，與其直接給予代理 API 金鑰的存取權，您可以在代理環境之外執行一個代理伺服器，將金鑰注入請求中。代理可以進行 API 呼叫，但它永遠看不到憑證本身。這種模式對於多租戶部署或處理不受信任的內容時非常有用。

最小權限

在需要時，您可以將代理限制為僅具有其特定任務所需的功能：

縱深防禦

對於高安全性環境，分層多重控制提供額外保護。選項包括：

• 容器隔離
• 網路限制
• 檔案系統控制
• 在代理伺服器進行請求驗證

正確的組合取決於您的威脅模型和營運需求。

隔離技術

不同的隔離技術在安全強度、效能和營運複雜度之間提供不同的權衡。

沙箱執行環境

對於不需要容器的輕量級隔離，sandbox-runtime 在作業系統層級強制執行檔案系統和網路限制。

主要優勢是簡單性：不需要 Docker 配置、容器映像或網路設定。代理伺服器和檔案系統限制是內建的。您提供一個設定檔來指定允許的網域和路徑。

運作方式：

• 檔案系統：使用作業系統原語（Linux 上的 bubblewrap，macOS 上的 sandbox-exec）來限制對配置路徑的讀寫存取
• 網路：移除網路命名空間（Linux）或使用 Seatbelt 設定檔（macOS）將網路流量路由到內建代理伺服器
• 配置：基於 JSON 的網域和檔案系統路徑允許清單

設定：

npm install @anthropic-ai/sandbox-runtime

然後建立一個配置檔來指定允許的路徑和網域。

安全考量：

1. 共用主機核心：與虛擬機不同，沙箱化的程序共用主機核心。核心漏洞理論上可能允許逃逸。對於某些威脅模型這是可以接受的，但如果您需要核心層級的隔離，請使用 gVisor 或獨立的虛擬機。

2. 無 TLS 檢查：代理伺服器允許列出網域但不檢查加密流量。如果代理對允許的網域具有寬鬆的憑證，請確保無法使用該網域來觸發其他網路請求或洩漏資料。

對於許多單一開發人員和 CI/CD 使用案例，sandbox-runtime 以最少的設定顯著提高了安全門檻。以下章節涵蓋了需要更強隔離的部署的容器和虛擬機方案。

容器

容器透過 Linux 命名空間提供隔離。每個容器都有自己的檔案系統、程序樹和網路堆疊視圖，同時共用主機核心。

安全強化的容器配置可能如下所示：

docker run \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --security-opt seccomp=/path/to/seccomp-profile.json \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /home/agent:rw,noexec,nosuid,size=500m \
  --network none \
  --memory 2g \
  --cpus 2 \
  --pids-limit 100 \
  --user 1000:1000 \
  -v /path/to/code:/workspace:ro \
  -v /var/run/proxy.sock:/var/run/proxy.sock:ro \
  agent-image

以下是每個選項的作用：

Unix socket 架構：

使用 --network none 時，容器完全沒有網路介面。代理到達外部世界的唯一方式是透過掛載的 Unix socket，它連接到主機上執行的代理伺服器。此代理伺服器可以強制執行網域允許清單、注入憑證並記錄所有流量。

這與 sandbox-runtime 使用的架構相同。即使代理透過提示注入被入侵，它也無法將資料洩漏到任意伺服器——它只能透過代理伺服器通訊，而代理伺服器控制哪些網域是可達的。更多詳情請參閱 Claude Code 沙箱部落格文章。

額外強化選項：

gVisor

標準容器共用主機核心：當容器內的程式碼進行系統呼叫時，它直接到達執行主機的同一核心。這意味著核心漏洞可能允許容器逃逸。gVisor 透過在使用者空間攔截系統呼叫來解決此問題，在它們到達主機核心之前，實作自己的相容層來處理大多數系統呼叫，而不涉及真正的核心。

如果代理執行惡意程式碼（可能由於提示注入），該程式碼在容器中執行並可能嘗試核心漏洞利用。使用 gVisor，攻擊面要小得多：惡意程式碼需要先利用 gVisor 的使用者空間實作，並且對真正的核心存取有限。

要將 gVisor 與 Docker 一起使用，請安裝 runsc 執行環境並配置守護程序：

// /etc/docker/daemon.json
{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc"
    }
  }
}

然後使用以下命令執行容器：

docker run --runtime=runsc agent-image

效能考量：

對於多租戶環境或處理不受信任的內容時，額外的隔離通常值得這些開銷。

虛擬機

虛擬機透過 CPU 虛擬化擴展提供硬體層級的隔離。每個虛擬機執行自己的核心，建立強大的邊界——客體核心中的漏洞不會直接危害主機。然而，虛擬機並非自動比 gVisor 等替代方案「更安全」。虛擬機安全性在很大程度上取決於虛擬機管理程式和裝置模擬程式碼。

Firecracker 專為輕量級微型虛擬機隔離而設計——它可以在 125 毫秒內啟動虛擬機，記憶體開銷不到 5 MiB，去除不必要的裝置模擬以減少攻擊面。

使用此方法，代理虛擬機沒有外部網路介面。相反，它透過 vsock（虛擬 socket）進行通訊。所有流量透過 vsock 路由到主機上的代理伺服器，代理伺服器在轉發請求之前強制執行允許清單並注入憑證。

雲端部署

對於雲端部署，您可以將上述任何隔離技術與雲端原生網路控制結合使用：

1. 在沒有網際網路閘道的私有子網路中執行代理容器
2. 配置雲端防火牆規則（AWS Security Groups、GCP VPC 防火牆）以阻止除代理伺服器外的所有出站流量
3. 執行代理伺服器（例如帶有 credential_injector 過濾器的 Envoy）來驗證請求、強制執行網域允許清單、注入憑證並轉發到外部 API
4. 為代理的服務帳戶分配最小 IAM 權限，盡可能透過代理伺服器路由敏感存取
5. 在代理伺服器記錄所有流量以供稽核

憑證管理

代理通常需要憑證來呼叫 API、存取儲存庫或與雲端服務互動。挑戰在於提供此存取權而不暴露憑證本身。

代理伺服器模式

建議的方法是在代理的安全邊界之外執行一個代理伺服器，將憑證注入到外發請求中。代理發送不帶憑證的請求，代理伺服器添加憑證，然後將請求轉發到目的地。

此模式有幾個好處：

1. 代理永遠看不到實際的憑證
2. 代理伺服器可以強制執行允許端點的清單
3. 代理伺服器可以記錄所有請求以供稽核
4. 憑證儲存在一個安全位置，而非分發到每個代理

配置 Claude Code 使用代理伺服器

Claude Code 支援兩種方法將取樣請求路由到代理伺服器：

選項 1：ANTHROPIC_BASE_URL（簡單但僅適用於取樣 API 請求）

export ANTHROPIC_BASE_URL="http://localhost:8080"

這告訴 Claude Code 和 Agent SDK 將取樣請求發送到您的代理伺服器，而非直接發送到 Anthropic API。您的代理伺服器接收明文 HTTP 請求，可以檢查和修改它們（包括注入憑證），然後轉發到真正的 API。

選項 2：HTTP_PROXY / HTTPS_PROXY（系統範圍）

export HTTP_PROXY="http://localhost:8080"
export HTTPS_PROXY="http://localhost:8080"

Claude Code 和 Agent SDK 遵循這些標準環境變數，將所有 HTTP 流量路由到代理伺服器。對於 HTTPS，代理伺服器建立加密的 CONNECT 通道：如果不進行 TLS 攔截，它無法查看或修改請求內容。

實作代理伺服器

您可以自行建構代理伺服器或使用現有的：

• Envoy Proxy — 生產級代理伺服器，帶有用於添加認證標頭的 credential_injector 過濾器
• mitmproxy — TLS 終止代理伺服器，用於檢查和修改 HTTPS 流量
• Squid — 帶有存取控制清單的快取代理伺服器
• LiteLLM — LLM 閘道，帶有憑證注入和速率限制

其他服務的憑證

除了從 Anthropic API 取樣外，代理通常需要對其他服務的認證存取——git 儲存庫、資料庫、內部 API。有兩種主要方法：

自訂工具

透過 MCP 伺服器或自訂工具提供存取，將請求路由到在代理安全邊界之外執行的服務。代理呼叫工具，但實際的認證請求發生在外部——工具呼叫代理伺服器，代理伺服器注入憑證。

例如，git MCP 伺服器可以接受來自代理的命令，但將它們轉發到主機上執行的 git 代理伺服器，該代理伺服器在聯繫遠端儲存庫之前添加認證。代理永遠看不到憑證。

優勢：

• 無需 TLS 攔截：外部服務直接進行認證請求
• 憑證保留在外部：代理只看到工具介面，而非底層憑證

流量轉發

對於 Anthropic API 呼叫，ANTHROPIC_BASE_URL 讓您將請求路由到可以以明文檢查和修改它們的代理伺服器。但對於其他 HTTPS 服務（GitHub、npm 註冊表、內部 API），流量通常是端對端加密的——即使您透過 HTTP_PROXY 將其路由到代理伺服器，代理伺服器也只看到不透明的 TLS 通道，無法注入憑證。

要修改到任意服務的 HTTPS 流量而不使用自訂工具，您需要一個 TLS 終止代理伺服器來解密流量、檢查或修改它，然後在轉發之前重新加密。這需要：

1. 在代理容器之外執行代理伺服器
2. 在代理的信任儲存中安裝代理伺服器的 CA 憑證（使代理信任代理伺服器的憑證）
3. 配置 HTTP_PROXY/HTTPS_PROXY 將流量路由到代理伺服器

此方法無需編寫自訂工具即可處理任何基於 HTTP 的服務，但增加了憑證管理的複雜性。

請注意，並非所有程式都遵循 HTTP_PROXY/HTTPS_PROXY。大多數工具（curl、pip、npm、git）會遵循，但有些可能會繞過這些變數直接連接。例如，Node.js fetch() 預設忽略這些變數；在 Node 24+ 中，您可以設定 NODE_USE_ENV_PROXY=1 來啟用支援。為了全面覆蓋，您可以使用 proxychains 來攔截網路呼叫，或配置 iptables 將出站流量重定向到透明代理伺服器。

兩種方法仍然需要 TLS 終止代理伺服器和受信任的 CA 憑證——它們只是確保流量確實到達代理伺服器。

檔案系統配置

檔案系統控制決定代理可以讀取和寫入哪些檔案。

唯讀程式碼掛載

當代理需要分析程式碼但不需要修改時，以唯讀方式掛載目錄：

docker run -v /path/to/code:/workspace:ro agent-image

可寫位置

如果代理需要寫入檔案，根據您是否希望變更持久化，有幾個選項：

對於容器中的臨時工作區，使用僅存在於記憶體中且在容器停止時清除的 tmpfs 掛載：

docker run \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /workspace:rw,noexec,size=500m \
  agent-image

如果您想在持久化之前審查變更，overlay 檔案系統讓代理可以寫入而不修改底層檔案——變更儲存在單獨的層中，您可以檢查、套用或丟棄。對於完全持久化的輸出，掛載專用卷但將其與敏感目錄分開。

延伸閱讀

• Claude Code 安全文件
• 託管 Agent SDK
• 處理權限
• Sandbox runtime
• The Lethal Trifecta for AI Agents
• OWASP Top 10 for LLM Applications
• Docker Security Best Practices
• gVisor Documentation
• Firecracker Documentation