從代理寫程式到供應鏈風險
InfoQ 的 Matt Saunders 在 2026 年 10 月 16 日的報導指出，軟體供應鏈安全公司 Chainguard 在 Assemble London 活動宣布兩項 beta 產品：Chainguard Workspaces 與 Chainguard Checks。前者提供遠端開發環境，後者把持續整合帶進開發循環。這兩項產品的共同背景，是 AI 編碼代理開始大量參與寫程式之後，執行權限與環境隔離成為新的實務問題。
AI 代理要完成任務，通常得安裝套件、執行 shell 命令、修改設定檔，甚至同時跑多個任務。若這些動作都發生在開發者的筆電上，生成程式碼或第三方套件就有機會碰到公司憑證與本機服務。若把每次變更都送到傳統持續整合服務，又會遇到排隊等待，以及每次都重新下載相同依賴的浪費。Chainguard 的兩項產品就是針對這個矛盾：既要讓代理能動手做事，又不能讓它直接接觸開發者本機的敏感資源。
Workspaces 以 microVM 隔離代理工作環境
Chainguard Workspaces 的做法，是替每位開發者或每個代理配置專屬的遠端 microVM。microVM 可理解為一種輕量虛擬機，介於傳統虛擬機與容器之間，保留較強的隔離邊界，同時維持較快的啟動速度。對執行不受信任程式碼而言，這種隔離很重要，因為它能降低惡意或出錯程式碼直接影響主機的風險。
使用時，開發者可透過 chainctl develop 命令，把本機工作樹同步到遠端環境，包含尚未提交的變更。當使用者離開工作階段，系統會替 session 建立快照；之後恢復時，檔案、行程與 shell 上下文都能延續。團隊也可以為同一個儲存庫建立多個彼此隔離的 Workspaces，讓不同代理嘗試不同解法，而不會互相搶用連接埠、快取或行程狀態。
在憑證處理上，Chainguard 表示主機端代理會把短效憑證加入已核准的對外請求，而不是把長效機密放進 guest 環境。這裡的 guest 指的是 microVM 內的執行環境；把機密留在主機端，可減少代理或第三方套件直接取得長期憑證的機會。選用的 egress 規則則可阻擋並記錄連到團隊未允許端點的連線。egress 指對外流量，預設限制對外連線有助於降低資料外洩與橫向移動風險。公司也把命令、程式碼變更與網路呼叫記錄到其所稱的防竄改日誌中。Paxton 與 Phillips 表示，這些設計是為了在依賴套件遭入侵，或代理遭提示注入時限制損害範圍。提示注入是指攻擊者把惡意指令藏在代理會讀取的內容裡，誘導代理做出非預期行為。
Checks 把 CI 檢查拉進開發循環
Chainguard Checks 則是把持續整合步驟放進另一個執行環境。它使用由 Chainguard 套件建置的獨立暖 microVM 來跑檢查；暖 microVM 代表預先準備好的執行環境，可減少每次啟動與安裝依賴的時間。依賴項目會依專案的 lockfile 準備，lockfile 是鎖定套件版本的檔案，能讓不同環境取得一致依賴；當 lockfile 改變，snapshot pool 會重建，以維持檢查環境與專案狀態一致。
開發者可透過命令列、提交前掛鉤或 GitHub App 呼叫同一組檢查；代理則可透過 MCP server 或 SDK 呼叫。MCP 是 Model Context Protocol，用於讓模型或代理連接外部工具與資料來源；SDK 則是軟體開發套件，讓程式以 API 方式整合功能。Chainguard 的 Paxton 與 Phillips 將目標描述為讓開發者與代理能安全地測試、失敗與修正程式碼，而不必等待緩慢的持續整合。
當 Checks 與 Workspaces 一起使用時，Workspace 會在測試執行期間暫停。若檢查失敗，結構化日誌會回到恢復後的工作階段，代理不必重建環境就能再嘗試修改。若執行成功，系統會產生證明，把環境、結果與 commit 綁在一起。attestation 在此可理解為可驗證的簽章紀錄，用來證明某次測試確實在那個環境與版本上通過。Chainguard 的 Sam Katzen 表示，每次執行都會產生簽章證明，綁定環境、判定與 commit SHA，因此合併閘門可以驗證通過結果，而不必重跑測試套件。
限制與尚待驗證之處
這套設計有明顯前提。它依賴被證明的輸入維持不變，也依賴儲存庫信任 Chainguard 的執行與簽章系統。若輸入或執行系統的可信度出問題，證明的意義就會受限。此外，此次公告並未公布 Checks 與既有持續整合服務的效能比較數據，也未說明客戶應如何驗證日誌的防竄改能力。Workspaces 目前支援 Claude，其他代理仍在規劃中，計價方式則依實際消耗的運算資源計算。兩項產品都提供 30 天 beta 試用。
其他公告與競爭定位
Chainguard 同時宣布兩項與建置管道相關的更新。Chainguard Actions 已正式推出，包含超過 1,000 個重建且持續維護的 GitHub Actions。Chainguard Libraries for Go and .NET 進入早期存取階段；Libraries 會掃描依賴中的惡意軟體與灰色軟體，對新套件套用可配置延遲後才允許使用，並回溯移植選定的漏洞修補。灰色軟體通常指未必違法但可能帶來風險或不受歡迎的軟體。Chainguard 表示，其 beta 掃描器已對超過 5,000 個 Go 與 .NET 套件給出判定，其中超過一成在偵測時於公開來源找不到匹配。
市場上已有成熟替代方案。E2B 在 Firecracker microVM 中執行代理工作階段，控制對外流量，並在 guest 外解析憑證。StepSecurity 的 Harden Runner 監控 GitHub Actions runner 上的網路、檔案與行程活動，並可強制對外網路政策。依賴管理方面，Sonatype Repository Firewall 在建置前阻擋或隔離惡意與有漏洞套件，JFrog Curation 則在下載時套用安全、授權與套件年齡政策。Chainguard 的組合是把這些領域與簽章測試結果、重建 actions 及修補依賴放在一起。
以 microVM 執行不受信任的建置與代理工作負載，已經是既有做法。InfoQ 關於保護 AI 加速開發的指引建議，對代理生成的程式碼使用隔離 microVM 或嚴格限制的容器，並搭配短效憑證與預設拒絕的網路存取。Amazon Bedrock AgentCore 為每個使用者工作階段提供隔離的處理器、記憶體與檔案系統資源；Vercel 的 Hive 建置系統則使用 Firecracker microVM 與短效 WireGuard 通道。Chainguard 的差異在於把隔離與自家套件目錄、持續整合證明及代理循環結合，試圖形成一條從撰寫、測試到合併的供應鏈安全路徑。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。