在 Build 2026 上,微軟給 Azure API Management 添加了兩項 AI 閘道能力,二者合起來勾勒出模型-與-agent 控制平面的去向。第一項,Unified Model API,現處於公開預覽,讓客戶端以 OpenAI Chat Completions 格式寫一次請求,由 APIM 透明地把它們翻譯成 Anthropic 的 Messages API、Google Vertex AI,或其他 provider 的原生 schema。實際收益是,你可以按成本、延遲或地區切換後端、添加模型或路由流量,而無需重寫客戶端程式碼,而治理,即速率限制、內容安全、token 計量,在那一個端點背後的每個 provider 上一致施加。
更鋒利的新增是面向 agentic 層的內容安全。微軟把其現有的 llm-content-safety 策略從純 LLM 文本延伸到覆蓋 Model Context Protocol 工具呼叫和 Agent-to-Agent 通信,掃描舊策略從未看到的三樣東西:MCP 工具呼叫參數、MCP 回應文本,以及 A2A agent 負載。它帶有類別過濾(仇恨、自殘、性、暴力,按 0 到 7 的嚴重度刻度)和一個標記 prompt-injection 嘗試的 shield-prompt 屬性。對於串流回應,它把事件緩衝在一個滑動窗口裡,遇到違規就直接停止轉發;非串流返回 403,而一個 window-size 旋鈕處理超過 Azure Content Safety 一萬字元上限的內容。與此並行,APIM 現在跨 OpenAI、Anthropic、Bedrock 和 Vertex 記錄推理、快取和音訊 token,發布了一個正式可用的 API Center MCP Server 用於發現已註冊的 MCP 伺服器、工具和 agent,並加入了 REST-到-MCP 轉換,使現有 API 無需重建即可作為 MCP 伺服器暴露。
時機才是故事。它落地的這一週,閘道恰恰是被主動攻擊的對象:LiteLLM 的命令注入漏洞進入 CISA 的已知被利用清單,正是因為一個擋在每個模型前面的代理握著 AI 基礎設施裡最集中的憑據堆。微軟的舉措是同一認知的另一面。如果一個組織的所有模型與 agent 流量都漏斗式地通過一個控制平面,那個平面同時是價值最高的目標,也是你能對一切施加策略的唯一地點。把內容安全延伸到 MCP 和 A2A 是值得劃線強調的部分,因為隨著 agent 呼叫工具、彼此呼叫,危險負載不再只是用戶的 prompt。它變成一個 agent 構造的工具參數,以及一個 agent 發給另一個的訊息,而閘道是看得到這一切的唯一咽喉。
它也乾淨地嵌進本週其他安全線索。NIST 那個證明,即沒有任何有限的 guardrails 集合是不可破解的,主張持續的、可更新的施行,而非一次性的牆,而一個中央閘道策略正是你持續打補丁的地方。微軟明確表示把 APIM 定位為 AI 工作負載的控制平面,並指出競爭對手,即 AWS Bedrock Guardrails、Google Apigee、Cloudflare AI Gateway,在多 provider、多協議的廣度上覆蓋更窄。給 builder 的要點不取決於具體選微軟的閘道:如果你路由不止一個模型 provider,或運行多 agent 系統,治理就在閘道處集中,無論你喜不喜歡,而內容安全現在必須意味著檢查工具呼叫和 agent 間訊息,而不只是審核聊天。