Vercel 在 ２０２６ 年 ５ 月 ２８ 日宣布 AI Gateway 支援 team-wide provider allowlist。這個更新看起來像一個小設定，但對企業導入 AI agent 很關鍵。
原因是 agent 不只是呼叫模型。它可能會自動重試、改寫請求、切換 provider、使用 BYOK，甚至在工具鏈中替你做模型選擇。如果模型供應商限制只放在程式碼裡，企業其實很難保證所有流量都符合資安與法務核准。
Provider Allowlist 的價值，是把「哪些供應商能被使用」變成 gateway 層的硬限制。
Provider Allowlist 是什麼？
Vercel AI Gateway 本來就能讓開發者用同一個介面呼叫不同模型供應商。Provider Allowlist 則讓 team owner 設定哪些 provider 被允許服務請求。
官方說明列出的重點包括：
- 限制會在 gateway 層執行。
- 它適用於 AI SDK、OpenAI Chat Completions API、Anthropic Messages API 等格式。
- 它也適用於 BYOK traffic。
- 只有 team owners 可以修改 allowlist。
- 開啟後，新加入 AI Gateway 的 provider 預設不會自動被允許。
- 如果 request 指定未核准 provider，AI Gateway 會拒絕請求。
這代表治理不再依賴每個應用自己寫對設定。
為什麼 coding agent 特別需要這層限制？
一般應用多半由工程師明確寫死模型設定。Agent 系統不同，它可能會：
- 根據任務自動挑模型。
- 因為失敗而重試到其他 provider。
- 由 coding agent 產生或修改 providerOptions。
- 使用第三方套件包裝模型呼叫。
- 在多個專案之間共享 gateway key。
如果公司允許某些 provider，禁止另一些 provider，這件事不能只靠工程師記得。Provider Allowlist 讓模型供應商清單變成平台政策。
它解決的不是成本，而是責任邊界
很多人聽到 AI Gateway 會先想到成本、觀測和 failover。Provider Allowlist 的核心更接近責任邊界。
企業採購模型供應商時，通常會看：
| 面向 | 常見審查問題 |
|---|---|
| 資料處理 | prompt 和 output 是否保存？是否用於訓練？ |
| 區域與法規 | 是否符合公司資料所在地與監管要求？ |
| 合約 | 是否有 DPA、SLA、責任限制與稽核條款？ |
| 安全 | 是否支援 ZDR、BYOK、審計與存取控制？ |
| 成本 | 是否有預算上限、報表與異常偵測？ |
當 agent 可以自己組裝請求時，這些審查結果要被寫進基礎設施層。否則合規文件看起來完整，實際流量卻可能繞到未核准供應商。
與 request-level filtering 的差別
request-level filtering 是「這次請求想用哪些 provider」。Provider Allowlist 是「整個 team 永遠只能用哪些 provider」。
差別很大：
| 控制層 | 誰能改 | 適合用途 | 風險 |
|---|---|---|---|
| request-level filter | 應用程式或 agent | 單次任務路由、成本優化、模型 A／B test | agent 或程式碼可能改掉 |
| provider allowlist | team owner | 企業供應商政策、法務核准清單、ZDR 邊界 | 彈性較低，但治理更強 |
實務上兩者應該一起用。allowlist 定義不可越過的底線，request-level filter 再處理單一任務的偏好。
BYOK 為什麼也要管？
BYOK 常被理解成「用自己的 key，所以比較安全」。這只說對一半。
BYOK 能讓公司控管供應商帳號與合約，但如果 gateway 允許任意 provider，團隊仍可能把流量送到未核准 provider。Provider Allowlist 將 BYOK 流量也納入限制，避免出現「不是平台 key，所以不受平台政策管」的漏洞。
對 regulated teams 來說，這點很重要。金融、醫療、政府、教育或大型企業往往不是不能用 AI，而是要能證明 AI 流量只進入已核准路徑。
導入時應該怎麼設計？
建議不要一開始就把 allowlist 設成很寬。可以用四步驟：
１．列出公司已完成法務與資安審查的模型供應商。
２．將 AI Gateway allowlist 設為這份清單。
３．把 ZDR、Disallow Prompt Training、BYOK 和 usage reporting 一起納入政策。
４．要求所有 agent 專案透過 gateway 呼叫模型，而不是各自直接接 provider API。
如果開發團隊需要測新模型，也應該走新增 provider 的審核流程，而不是在專案內自行繞路。
適合哪些團隊？
Provider Allowlist 特別適合：
- 已經有多個 AI 應用或 agent 專案的公司。
- 有法務、資安或資料治理審查的團隊。
- 使用 BYOK，但仍想集中控管模型路由的組織。
- 想讓 coding agent 使用 AI Gateway，卻擔心 agent 改路由的工程團隊。
- 需要將 AI 使用記錄納入 SIEM、合規報表或內部稽核的企業。
如果只是個人專案，這個功能可能不急。但只要進入公司共用平台，它就會變成很實用的防線。
官方來源
結論
Provider Allowlist 的訊號很清楚：AI 應用的治理正在往 gateway 層移動。
未來企業不會只問「模型好不好」，而會問「所有 agent 的模型流量能不能被統一限制、觀測、稽核與證明」。Vercel 這次更新補的就是這塊。對正在建立內部 agent platform 的團隊來說，這類 gateway policy 會變成基本配備。