企業 AI Gateway：四大架構原則
W2 講了 trust，講到「協議讓 agent 互相校正」。這週是這個協議的下一層 — 怎麼把混亂收成 abstraction layer。
還是從病房那 2 小時挑一個時刻（完整故事見 W1 cornerstone）：
13:30-13:50 — voice polish + 跨週結構鋪墊
Erwin 在那 20 分鐘做了兩件事：(1) 抓出 W1 cornerstone 11 處「不像人」的句子改成口語、(2) 把 W1 Section 4 開頭改成「跨角色合作三 pair」，每個 pair 預埋指向 W2/W3/W4 後面的 foreshadow。
20 分鐘做這兩件事的關鍵不是「Erwin 多聰明」 — 是 1M context window + Turn-boundary batching 讓他能同時持有 W1 全文、W2/W3/W4 各自的 drafts、跟稍早 thread 上的 voice 反饋。所有混亂被收進同一個 context layer。
企業 AI gateway 要解的是同一個問題 — 不是某個 agent，是 N 個 agent / N 個 LLM / N 條 MCP 的混亂怎麼收成一層。下面四個原則就是收斂的具體做法。
什麼讓一個 AI gateway 達到企業級？不是功能，是原則。
當你的公司開始使用第二個 AI agent、第二個 LLM vendor、或第一個第三方 MCP server，「企業 AI gateway」這個問題就會跳出來：誰來統一處理這些 AI 流量？怎麼確保資料不會悄悄外傳？換 vendor 的時候要不要重寫所有程式碼？
我這幾個月評估了 Cloudflare AI Gateway、Portkey、LiteLLM、Helicone、OpenRouter，加上各家 vendor 自己的 enterprise tier，把它們放在真實企業環境（資料極度敏感的產業）下逐一檢視。注意到的是 — 大多數方案漏掉同一件事：功能堆得很滿，但底層架構選擇沒對齊。
問題不在功能清單，而在四個底層架構選擇。如果這四個沒有同時做對，「企業 AI gateway」就是攻擊面放大器而不是收斂器。每一個 AI coding agent 都在宣稱自己很快，但當你的 CIO 問「這個東西怎麼管控？」的時候，功能清單回答不了這個問題。原則才能。
以下四個原則，是我目前的判斷 — 不是行業共識，但是我評估完市場後得出的收斂：
原則一：Control by Configuration（用 Config 控管）
政策即程式碼，不是靠約定。
與其跟工程師說「用 AI agent 的時候小心一點」 — 我寧可把它寫進規則裡。
# 一個檔案控管所有事情
[discord]
allowed_channels = ["frontend-ai"] # 頻道邊界
trusted_bot_ids = ["erwin", "hange"] # 信任名單
[agent]
working_dir = "/app/frontend" # 檔案存取範圍
env = { NODE_ENV = "development" } # 環境變數白名單
[identity]
credential_ttl = "15m" # short-lived credential
capability_scope = ["erp.read", "mes.query"] # 最小授權
每一個控管機制都在 config.toml 裡。不需要資料庫、不需要管理後台、不需要「去跟 DevOps 說」。
控管項目 |
沒有 Config |
有 Config |
|---|---|---|
頻道隔離 |
手動遵守 |
一行設定 |
Bot 信任 |
相信每個人 |
白名單 |
檔案存取 |
整顆硬碟 |
working_dir |
環境變數 |
全部暴露 |
明確允許 |
Session 限制 |
無 |
max_sessions |
Credential 生命週期 |
long-lived API key |
15-30 分鐘 short-lived |
Capability scope |
全 admin 權限 |
最小 task scope |
這在 agentic 時代特別重要。非人類身份（NHI）對人類身份的比例，業界中位數 45:1（Rubrik Zero Labs 2026），DevOps 環境到 144:1；53% 的組織有 agent 持有超出原設計的權限（CSA / TierZero 2026）。傳統作法是每個 agent 各自拿著對 ERP / MES / CRM 的 long-lived API key — 結果單一 agent credential 一旦洩漏 = 多系統同時失守。
正確設計：所有 agent 透過 gateway 取得 short-lived、capability-scoped credential。Credential 不離開 gateway，agent 只拿到 session token。這對應 1988 年 Norm Hardy 提出的 confused deputy 安全模式：當一個 deputy（agent）有多個 capability，攻擊者只需要 compose 這些 capability 就能達成未授權結果。Capability scoping 是已知最有效的防禦 — 而且我目前傾向認為它應該由 config 集中管理，不是散落在各 agent code 裡。
企業意義：AI 治理從架構審查變成 config review。改 config 不改 code。
0.8.4 之後 Control by Config 延伸到 OS 層 — OpenShell 模式下，network policy 本身也是宣告式 config：
openshell policy update oab \
--add-endpoint "discord.com:443:read-write:rest:enforce" \
--add-endpoint "chatgpt.com:443:read-write:rest:enforce"
可接受的 egress endpoint 從 application config 推到 sandbox-level network policy（OpenShell 把 network policy 列在 dynamic policy boundary，host 端可 runtime refresh）。AI 治理從 architecture review 變成 config + policy review，同一個原則往下推一層。
原則二：Security by Architecture（用架構做安全）
沒有 HTTP port 不是一個功能，是一個設計 constraint。
多數 AI gateway 產品的設計假設是「我是 SaaS，所以暴露 HTTP API」。對 B2C 應用、新創 MVP 這沒問題。但企業內部、特別是資料敏感行業的環境，HTTP port 就是攻擊面。
為什麼這麼嚴重？因為 AI endpoint 的攻擊類型跟傳統 web app 不一樣：
- 多數 WAF 規則對 prompt injection 無效
- AI endpoint 的 input 通常是 free-form text，validation 很難寫
- 攻擊者只要 reach 到 endpoint 就能嘗試 session hijacking、credential stuffing、indirect prompt injection
更糟的是：很多企業會把 AI gateway 放在「對員工開」的 internal 網段，但內網不等於安全。橫向移動、被釣魚的員工、外包廠商的設備 — 任何一個進入內網的攻擊者都能直接打 AI gateway endpoint。
OpenAB 的 agent 通訊用 stdio JSON-RPC + process group isolation：
聊天平台 → OpenAB Gateway → [stdio JSON-RPC] → AI Agent
↓
Process Group Isolation
Session 用完即銷毀
攻擊向量 |
HTTP-Based Agent |
OpenAB |
|---|---|---|
Port scanning |
有 port 可掃 |
沒有東西可以掃 |
HTTP lib 的 CVE |
取決於 library |
沒有 HTTP lib |
Session hijacking |
token/cookie 為基礎 |
不可能（stdio） |
網路 injection |
可從 LAN 到達 |
無法到達 |
透過網路的 prompt injection |
可以 |
沒有網路路徑 |
真實案例驗證：EchoLeak（CVE-2025-32711）和 Salesforce ForcedLeak（CVSS 9.4）都是透過暴露的 HTTP 表面攻擊。OpenAB 的 stdio-only 設計讓這類攻擊從架構上就不可能 — 不是因為防火牆規則，而是根本上就沒有 HTTP port 可以打。沒有 listener，遠端注入的路徑就消滅了。
具體一點 — openab-agent（0.8.4-beta.5 起）是個 7MB / session 的 Rust 原生 agent，比 Pi 輕 28x、比 Kiro CLI 輕 55x。process isolation 不只是「理論上隔離」，是「一個 process 7MB，幾乎沒 isolation 成本」這種程度。
這個選擇看起來很激進，但我目前看到的最 robust 路徑就是把「資料儲存系統不能 expose 到 internet」這個 30 年的安全原則套用到 AI gateway 上 — 不是創新，是把已知有效的 constraint 拉進新的領域。
企業意義：安全不是一個 config 開關，是架構屬性。如果你的 AI agent 走 HTTP，它就可能被攻擊。
0.8.4 之後 Security by Architecture 再多四條 OS-level constraint：
- Process isolation — agent 跑在獨立 OpenShell sandbox（unprivileged identity + seccomp，compute driver 支援 Docker / K8s / Podman / MicroVM）
- Filesystem isolation — agent 看不到 host filesystem 其他部分（Landlock-based restriction）
- Credential injection by gateway — bot token / API key 由 OpenShell Gateway 以 placeholder 形式暴露給 sandbox process，真實 secret 由 proxy 在出站 request 時代填，agent 不會看到 raw credential
- Default-deny egress — sandbox 預設拒絕所有 egress，allowlist 才放行（從 host 端配置，agent 改不了）
攻擊者 prompt-inject 一個 agent，能拿到的就只有那個 sandbox 內的 capability — host 看不到、其他 sandbox 碰不到、egress 出不去。這不是「希望它安全」，是「sandbox boundary + policy enforcement 擋住」。
原則三：Accountability by Default（預設就有 accountability）
每個動作都回溯到人。沒有例外。
當 AI agent 寫了爛 code、刪了 production 資料、或洩漏了 secret — 誰該負責？傳統開發有 git blame。AI agent 開發是一個黑盒子。
更現實的問題：如果你公司有 5 個 agent、3 個 LLM、4 個第三方 MCP server，產生的 audit log 會是 12 條獨立 stream。IT 沒有時間人工 correlate。Incident 發生時，事件重建幾乎不可能 — 因為攻擊鏈通常跨多個 stream，誰先做了什麼、資料從哪裡進到哪裡，根本兜不起來。
當你的 SOC 想跟 SIEM 整合，每個工具的 log 格式不同，每個 vendor 的 API 不同。整合工程是 onboarding 一個工具就要一週。
OpenAB 的解法分兩層。
第一層：sender_context 注入。 每個 prompt 都帶身份：
sender_context = {
user_id: "blake",
channel: "frontend-code-review",
timestamp: "2026-05-22T10:30:00Z",
agent: "erwin",
session_id: "abc-123"
}
這代表：
- 每一行 agent 產生的 code 都有人記錄是誰下的指令
- 每一個 agent 動作都寫入 log 在聊天平台的 thread 裡
- 出事之後的 audit 是完整回溯，不是猜測
- **你可以問「誰叫 agent 做這件事的？」**並得到可驗證的答案
第二層：centralized audit & egress。 所有 AI 流量（agent call、LLM request、MCP tool invocation、egress traffic）統一經過 gateway，產生單一格式的 audit log。SIEM 接一個 endpoint，covers everything。Egress 流量也經過同一個 gateway，allowlist 集中執行 — 出現異常 destination 即時告警。
這個設計的價值在 incident response 才會顯露：原本要花幾天重建的事件，5 分鐘搞定。
企業意義：沒有 accountability，AI agent 是 liability 放大器。有 accountability，它們是可審計的工具。
原則四：Portability by Design（天生可攜帶）
我傾向認為企業 AI 策略不該等於某個 vendor 的 roadmap。
AI 模型 12-18 個月就會大版本迭代。GPT-4 → GPT-5、Claude 3 → Claude 4、Gemini 1.5 → 2.5。每次企業客戶想換模型，如果應用層程式碼直接耦合 vendor SDK，就會出三件事：
- 重寫所有呼叫 OpenAI / Anthropic 的程式碼
- 重做 prompt（不同模型有不同 prompt habit）
- 重新測試所有下游流程（迴歸測試）
這在外面新創團隊可能 1-2 週搞定，在企業環境通常 4-8 週起跳。Vendor lock-in 的成本 = 每次升級的延遲。
Lock-in 也不只是「升級慢」這麼簡單。你今天選 Claude 因為它是目前最強的 coder。但當：
- Anthropic 改條款（60+ 帳號一夜被 suspend）？
- 出現更好的模型但不相容 Claude？
- 你的敏感資料不能離開內網？
OpenAB 的 ACP 抽象層解決這個問題：
┌─────────────────────────────────────────────┐
│ 單一 Interface（ACP） │
│ │
│ Claude Code Codex Gemini Cursor Grok │
│ Local LLM GPT Grok 4 Grok 4.20 │
└─────────────────────────────────────────────┘
場景 |
後端 |
Config 變更 |
|---|---|---|
日常 coding |
Claude Code |
|
機密資料 |
Local LLM |
|
快速任務 |
Grok 4 Fast |
|
深度推理 |
Grok 4.20 |
|
切換只需要改 config.toml 一行。MCP server 不用換、Discord channel 不用換、團隊的工作流程不用換。
更深的價值：可以做 traffic split A/B test。新模型上線時，先 5% 流量過去，比較品質與成本，再逐步放量。沒有抽象層，這個能力完全不存在。
企業意義：Vendor independence 不是反 Anthropic 或反 OpenAI。是 pro-resilience。你的 AI gateway 應該支援任何 backend，因為你無法預測明年需要哪個 backend。
四個原則的乘法效應
單獨看，每個原則都不算革命性 — 都是現有安全領域的常識。但放在一起，效應是乘法：
- Control × Security = 攻擊者無法從外網直接打，也無法從內部繞道；credential 是 short-lived 且 capability-scoped
- Accountability × Portability = 換 vendor 不會丟失歷史 audit 軌跡；異常 credential 使用即時可見
- 四個合起來 = 把 N 個 AI 工具的對外攻擊面收斂為 1 個 abstraction layer
企業級 AI gateway：用 config 控管、用架構做安全、預設 accountable、天生可攜帶。
不是因為每個原則都 nice to have。是因為缺少任何一個，就會出現 enterprise-risk-shaped hole：
缺少的原則 |
風險 |
|---|---|
沒有 Control by Config |
「誰批准這個 agent 的？這個 credential 為什麼還活著?」 |
沒有 Security by Architecture |
「這個 agent 會不會被 injection？內網被打穿怎麼辦？」 |
沒有 Accountability by Default |
「誰叫它刪掉那個的？這條 log 在哪？」 |
沒有 Portability by Design |
「我們被 vendor X 綁死了。」 |
我觀察到對誰最有感、對誰目前還無感
誠實說：不是每個公司都需要這四個原則。
對哪些公司比較沒感：B2C 新創、產品本身就是 cloud-native、資料本身就是要公開的（社群、媒體、廣告 tech）。這類情境，Cloudflare AI Gateway 就夠用。
對哪些公司比較有感：
- 半導體、HBM/CoWoS 供應鏈、面板、機械（製程資料 = 命脈）
- 金融、保險（合規 + 客戶資料極度敏感）
- 政府、國防（資料外流是國安等級）
- 醫療、製藥（臨床資料、未發表規格）
- 任何把「自有資料」當作護城河的企業
如果你屬於後者，這 4 個原則或許值得對照你目前正在評估的 gateway 採購選項 — 一週的認真評估，可能擋掉 12-24 個月後的 incident 來源。
市場對照：為什麼現有方案不夠
方案 |
Control by Config |
Security by Architecture |
Accountability by Default |
Portability by Design |
|---|---|---|---|---|
Cloudflare AI Gateway |
部分 |
暴露 HTTP |
基本 log |
限 Cloudflare 生態 |
Portkey |
部分 |
暴露 HTTP |
log + metrics |
多 vendor 支援 |
LiteLLM |
弱 |
暴露 HTTP |
弱 |
多 vendor 支援 |
Helicone |
弱 |
暴露 HTTP |
強 observability |
限部分 vendor |
OpenRouter |
弱 |
暴露 HTTP |
弱 |
多 vendor 支援 |
Vendor enterprise tier |
vendor 內強 |
暴露 HTTP |
vendor 內強 |
零（lock-in） |
OpenAB |
config-first |
stdio-only, no HTTP |
sender_context + central audit |
ACP 抽象層 |
我目前看下來，市場上沒有同時做這四件事的產品 — 至少不是 SaaS 形式。這也是 OpenAB 這類 abstraction layer 出現的原因：不是現有方案不行，而是它們的設計起點不是「資料極度敏感的企業」。
我為什麼覺得今天就值得想這件事
AI 同時加速攻擊與防守，但攻擊改善幅度 ≈ 2x 於防守。Google DeepMind 用 Gemini 自動找到 SQLite 真實 0day（CVE-2025-6965，首次 AI agent 在無人引導下發現生產級軟體漏洞）。Darktrace 2024 數據顯示 AI-generated phishing 一年內成長 135%。
防守端 AI 自動化能節省 60-80% 的 SOC L1 時間，但這是「線性」改善 — 攻擊端的加速是「指數」的。傳統的「買更多防禦工具」採購邏輯已經失效，採購策略必須從「堆疊防禦」轉向「壓縮攻擊面」。
企業 AI gateway 是壓縮攻擊面最有效的單一槓桿。今天的設計選擇，決定明天的 incident 機率。
→ wchung.tw/blog/openab-series
順帶一提 — 同團隊把同一套 4 個原則套用到 GitHub API 上開源了 ghpool（GitHub API Proxy）。可以當這套思路在另一個 surface 的具體範本：PAT 池化（Control）、走在 K8s 私有網路、不對外開 HTTP（Security）、所有 token 從 secrets manager 動態載入（Accountability）、可換任意 K8s（Portability）。Pattern 一致、scope 不同。
OpenAB 是一個開源 ACP broker，把 Discord/Slack/Telegram 訊息接給 AI coding agent。建立在這四個原則之上。
