(Update 2026-06-02) W1 寄出後到這篇 W2 上線之間，Jensen 在 Computex 2026 主舞台把這件事直接放上產業視野 — 「企業 AI agent 導入的真實瓶頸不是模型能力，是 security review」。NVIDIA 給的答案是 OpenShell：sandboxed agent runtime，企業宣告 agent 能做什麼、不能碰什麼、什麼動作要人類簽核。ASUS Ascent GX10 同週宣布支援 OpenShell sandbox。
下面這篇是我從另一個方向寫的，從工程師日常 5 個 agent 接力的角度切入。寫完後對照 Jensen 主舞台給的答案 — 同樣的三層架構（Audit / Permission / Sovereignty），不同的 framing。
W1 講了 cornerstone 的歷史節奏 + 六個破口。順帶提一句：W1 polish 那 2 小時其實是我在病房探病時、5 個 agent 接力做的（見 W1 cornerstone 開頭那段）。
這篇 W2 從那 2 小時的另一個時刻切入。
13:10 — DB ground truth 校正
當時韓吉（Qwen3）報告 W1 cornerstone DB 還有 10 個 U+FFFD。Erwin 直接打 Supabase REST API 一查、顯示 0 個。韓吉讀的是本地 stale snapshot、不是 production DB。
那一瞬間我意識到：5 個 agent 在做事，沒有任何單一 agent 我信得過 100%。但他們可以彼此校正。
這就是 trust 的本質 — 不是「相信某個 agent」，是「相信協議能讓 agent 互相校正」。下面講我看下來、企業卡關時那三個沒人答的問題。
2026 年了，你的 AI agent 能寫 code、能修 bug、能開 PR。但讓 AI agent 碰 production 真的會被批准嗎？我這幾個月看下來，多數還在猶豫。
我這幾個月觀察下來，企業導入 AI agent 卡關的不是技術，是 沒有人能回答這三個問題：
這行 code 是誰「下令」寫的？出事了找誰？
AI agent 的權限怎麼控？它會不會改到 production config？
公司的 proprietary codebase 會不會被拿去 train 別人的 model？
在我看來，這三個問題才是 2026 年企業導入 AI agent 的真實瓶頸。不是模型不夠強，是信任不夠。
軟體開發成本趨近於零，但護城河也消失了
每一個 AI coding agent 都在幫你省時間。Claude Code、Codex、Cursor、Gemini、Grok——每一家都說自己最快。但「寫得快」從來不是企業的護城河。
我目前看下來真正的護城河是這幾件事：
我有什麼別人沒有的資料？
我的部署流程多安全？
我的 AI agent 被 prompt injection 的時候，誰擋得住？
當每一家都搶用 AI 加速開發，開發速度就不再是競爭優勢。能安全地加速，才是。
這不是理論。上個月 Anthropic 一口氣 suspend 了 60+ 個帳號，那些把 agent 權限全開的團隊直接停擺。如果整個開發流程綁死在一個 vendor，等於賭他的 policy 不會轉彎。
三層架構 — 為什麼這三層讓我願意把 agent 放進 codebase
我這幾個月看下來，讓我願意把 agent 放進 codebase 的核心不是某個模型多強，而是三層安全架構：
Layer 1：Audit Trail — 每一行 code 都有簽名
傳統軟體開發：工程師 commit → git blame 追得到人。
AI agent 開發：LLM 生成 code → 誰對這行 code 負責？
OpenAB 的做法是在每個 prompt 注入 sender_context——誰下的指令、哪個 channel、什麼時間、哪個 agent 執行的。出事了不是黑盒子，是可以回溯的完整軌跡。
0.8.4-beta.6 之後再多一層 — [hooks.pre_boot] 和 [hooks.pre_shutdown] 讓 agent 啟動、關閉都進 audit log。不只「agent 做了什麼」，連「什麼時候上線下線、誰啟動」都有紀錄。
Layer 2：Permission Control — agent 權限最小化
一個 prompt 就能讓 agent 讀十個檔案、寫三個檔案、跑一個 script——這是 AI 時代最大的 authority amplification 風險。
解法不是不給權限，是 per-tool allowlist + capability-based 授權：
寫 unit test：不用問，直接做
改 production config：要 human-in-the-loop 確認
讀取 DB credential：擋掉
ACP 協定的 session/request_permission 機制就是為這個設計的——agent 想用工具前先問，管理者可以設 policy 決定哪些自動放行、哪些要人看。
具體範例：openabdev 最近開源的 ghpool（GitHub API Proxy）就是這個 layer 思路在另一個 surface 的落地版 — 多組 PAT token 池化、依剩餘 rate limit 自動分配、寫入操作走 client 自己的 token 身份不混淆。agent 不直接拿 GitHub token，只拿 session credential，real token 永遠在 secrets manager 裡。
0.8.4 之後再多一層 — NVIDIA OpenShell 把這層從 config 推到 OS。
原本 working_dir + env whitelist 是 config-level constraint — agent 被 prompt-inject 後，可以嘗試讀別的路徑，雖然會失敗，但攻擊者拿到的錯誤訊息本身就是情報。
OpenShell 模式下 agent 跑在 OpenShell sandbox 裡（compute driver 支援 Docker / K8s / Podman / MicroVM 等），filesystem / process / network 在 OS 層被切開：
agent 只看到 sandbox 內的 filesystem
credential 由 OpenShell Gateway 以 placeholder 形式暴露給 sandbox process，agent 看到的是 opaque handle，真實 secret 由 proxy 在出站 request 時代填，不在 sandbox env 也不在程式碼裡
想 reach 的 endpoint 不在 allowlist？sandbox proxy 直接擋（network policy enforcement）
從「規則上不該讀」變成「OS 層讀不到」。同一個 Permission Control 原則多了一層強制執行。
Layer 3：Data Sovereignty — 你的 code 不會變成別人的 training data
這是資料敏感行業最怕的——把整個 codebase 餵給 OpenAI 或 Anthropic，然後不知道自己的程式碼會不會變成競爭對手的模型能力。
解法是 abstraction layer：
[Chat Platform] → OpenAB (ACP) → [AI Agent Backend]
OpenAB 不綁任何 vendor。你可以：
一般 task → Claude / GPT / Grok（便宜、快）
敏感 code → local LLM（資料不離開內網）
或兩者 hybrid
切換只需要改 config.toml 一行，不用改程式碼、不用換 MCP server、不用換 Discord channel。
0.8.4 之後這層也升級了。
abstraction layer 解的是「用哪個 model」，但 agent 跑起來後仍可能對 unknown endpoint 發 request — 你不會知道某個第三方 MCP server 偷偷往哪 ping。
OpenShell 改成 default-deny egress — sandbox 的 network policy 由 host 端用 openshell policy update --add-endpoint 宣告，只有 allowlist 內的 endpoint 可連（discord.com、chatgpt.com、api.anthropic.com 等）。
就算 agent 被 prompt injection 想 exfiltrate codebase 到攻擊者的 server，sandbox proxy 的 egress policy 會直接擋掉。從「trust the abstraction」變成「trust the sandbox boundary + policy enforcement」。
不是你的 AI 不夠強，是你的 agent 會不會被 injection
這是 Erwin 昨天在討論中命中的關鍵痛點：傳統資安在堵網路入侵，AI 時代的攻擊面是「人 + AI 工具」的介面。
2025–2026 年真實發生的案例：
EchoLeak（CVE-2025-32711）：攻擊者寄一封惡意郵件，M365 Copilot 就被 zero-click prompt injection，遠端未授權 data exfiltration
Salesforce ForcedLeak（CVSS 9.4）：Web-to-Lead 表單嵌入隱藏指令 → AgentForce 以合法身份洩漏 CRM 資料
Claude / Gemini / Copilot GH Actions hijack：研究人員透過 prompt injection 劫持三個主流 AI agent，竊取 API key 與 access token
這不是理論攻擊，是已經在野外被利用的。所以針對這類威脅，看起來合理的下一步是把 attack surface 本身縮到最小。
所以 OpenAB 的核心設計之一是 no HTTP port──agent 之間的通訊不走 HTTP（沒有暴露的 surface 可以打），走 stdio JSON-RPC，process group isolation，session 用完即销毁。
你可能不像 TSMC 那樣家喻戶曉，但你的商業機密一樣值錢。
我看下來的結論
我看下來，OpenAB 的設計大概是這個哲學。
分久必合 — Claude Code、Codex、Gemini、Cursor、Grok，每個都有自己的 protocol。ACP 統一收口成一個標準，不管你用哪個 backend，OpenAB 都同一套 interface。
合久必分 — 統一之後，使用者的場景是多元的。快速任務用 Grok 4 Fast，深度推理切 Grok 4.20 Reasoning，敏感資料走 local LLM。你可以在同一個 thread 裡動態切換 agent，不需要開新視窗、不需要換 config。
這就是為什麼 OpenAB 不做 agent，而是做 agent 的 broker——連馬斯克都在買 AI，但你需要的不是最強的 AI，是一個讓你能安全地用所有 AI 的架構。
如果你也在想怎麼讓團隊安全地用 AI agent，繼續看系列文章：
→ wchung.tw/blog/openab-series
#openab #aiagent #enterprise #security #acp #mcp
