English Abstract: This post wraps up the three-part Docker × AI Agent series. Each article added one defensive layer for containers that run autonomous AI agents: kernel isolation with MicroVM sandboxes, network and credential isolation with an internal-only Docker network and an egress proxy, and resource circuit breaking with cgroups and ulimit. It summarizes the three layers side by side and traces how each one builds on earlier Autocruise posts on Docker proxy configuration, Docker engine ulimits, and Docker credential stores. 近期連續三篇 Docker × AI Agent 系列文，應對的是同一個課題：當容器裡執行的不再是行為固定的微服務，而是會自行產生程式碼、呼叫 Shell 的 AI Agent，「在容器就安全」這個假設要怎麼修正。三篇文章各自補上一道防線，構築成防禦縱深，本文把它們整理在一起，作為此系列的索引。 （一）在 Docker 容器中執行 AI Agent，需要哪三道防線？ 在 Docker 容器中執行 AI Agent，需要同時具備 Kernel 隔離、網路與憑證隔離、資源熔斷三道防線，分別對應 Agent 突破隔離、帶走機密與耗盡資源三種風險。 防線 處理的風險 關鍵設定 Kernel 隔離 共用宿主機 Kernel、runc 漏洞、掛載 docker.sock sbx MicroVM、K8s RuntimeClass 網路與憑證隔離 /proc/self/environ、DNS 隧道、.env 外洩 internal: true 、Egress Prox...

English Abstract: This article revisits Linux ulimit and Docker cgroups as hard resource limits for AI agent containers. It explains why per-UID nproc limits can cause cross-container outages, why --pids-limit is the container-level fork-bomb guard, and how to scope CPU-time limits to individual child processes so that a runaway script is terminated without killing the agent itself. 在先前的文章中，探討過 AI Agent 的本質其實就是 SRE 熟悉的控制迴圈（Loop Engineering）。近期的容器系列文也分別透過 MicroVM 沙盒 與 Egress Proxy，處理了核心隔離與金鑰保護的問題。要讓 AI Agent 在容器中安全運作，仍缺最後一塊拼圖： 運算資源的防呆與熔斷（Resource Circuit Breaking） 。 若 Agent 在自我修正的迴圈中寫出無窮迴圈腳本、意外觸發 Fork Bomb（無限衍生子行程），或開啟數萬個未關閉的檔案連線，單靠 Prompt 提示或應用層的 Timeout 無法攔截。此時就需要 Linux 與 Docker 中最經典的底層工具：ulimit 與 cgroups。 (1) 從「放寬限制」到「收緊牢籠」 過去撰寫 Docker 與 Linux ulimit 調校指南時，情境多半是為了應付高併發流量，例如 Nginx 或 Elasticsearch 出現 Too many open files 錯誤。當時的維運重點，是透過 --ulimit nofile=65535:65535 撐開系統限制，釋放硬體效能。 AI Agent 時代的思維則需要反過來： 傳統微服務（行為已知） ：調高 ulimit，避免系統預設值成為流量瓶頸。 AI Agent（行為未知） ：收緊 ulimit 與 cgr...

English Abstract: Putting real API keys into the environment variables of AI agent containers is unsafe. An agent that can run shell commands can read them from /proc/self/environ, leak them through DNS queries, or expose them through a .env file. This article builds a zero-trust egress layer: an internal-only Docker network with no external route, plus an egress proxy that holds the real keys and swaps a phantom token for them only on allowlisted domains. It includes a runnable Docker Compose and mitmproxy setup, and extends the design into an enterprise AI gateway for key rotation, budget circuit breaking, and audit logging. 本文重點大綱 架構觀念翻轉 ：在微服務時代，The Twelve-Factor App 提倡將設定與憑證存入環境變數（Environment Variables）；但在具備 Shell 執行權限與自主控制迴圈（Control Loop）的 AI Agent 時代，將真實 API Key 放進容器環境變數等同於將機密公開。 三大真實攻擊向量與 CVE 佐證 ：深入剖析失控或遭受間接提示詞注入（Indirect Prompt Injection）的 AI Agent，如何繞過指令黑名單，透過 Linux /proc/self/environ 跨行程繼承 、 DNS 隧道（DNS Exfiltration，以 CVE-2025-55284 為例） 與 .env 渲染漏洞 竊取憑證。 視覺化網路拓撲與時序拆解 ...

English Abstract: Running an autonomous AI agent with --dangerously-skip-permissions inside a standard docker run container is not a security sandbox. Every runc-based container shares the host Linux kernel, so a runtime flaw such as runc CVE-2025-52881, a mounted docker.sock , or API keys passed in with -e can turn one misbehaving agent loop into a host-level incident. This post contrasts standard containers with MicroVM sandboxes, walks through a Docker Sandboxes ( sbx ) setup with a separate guest kernel, deny-by-default egress policy and host-side credential proxying, shows how to verify each isolation layer, and closes with a two-phase governance model that moves agentic workloads in Kubernetes onto Kata Containers or gVisor through RuntimeClass. 傳統容器 vs. MicroVM 沙盒：在 AI Agent 時代，重新定義容器隔離與 Proxy 憑證防護 本文重點大綱 傳統 Container 與 MicroVM Sandbox 的本質差異 ：從 Linux Kernel 共用與否，切開「確定性微服務」與「非確定性 AI Agent」的執行邊界。 實務風險拆解：從 runC 漏洞（CVE-2025-52881）到環境變數外洩 ：分析為何 --dangerously-skip-p...