Autocruise

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...

English Abstract: A classic Docker bind mount failure: the container writes to a host directory and gets Permission denied, even though the host user clearly owns that directory. The root cause is almost always a UID/GID mismatch between the host filesystem and the container process — Linux permission checks only look at numeric IDs, not usernames. This post compares three fixes: pinning the container to a specific UID with --user , the PUID/PGID entrypoint pattern popularized by LinuxServer.io images, and Rootless Docker / Podman's user namespace remapping ( userns-remap ), along with the security and portability trade-offs of each. 用 -v 把 host 目錄掛進 container，裡面的程式想寫入卻得到 Permission denied，即使在 host 上明明對這個目錄有讀寫權限，這是最常見的 bind mount 問題之一。問題幾乎都出在 host 檔案的 owner UID/GID，跟 container 內 process 實際跑的 UID/GID 對不上——Linux 的權限檢查只認數字，不認「使用者名稱」。這篇文章說明三種常見解法：用 --user 直接指定 UID、用 PUID/PGID entrypoint 動態對齊、以及 Rootless Docker／Podman 的 user namespace 重映射，並比較三者在安全性、可攜性與設定複雜度上的取捨。 （一）問題重現：host...