Azure MCP 伺服器將 AI 代理連接到 Azure 服務，代表你執行工具，並透過授權每次通話的憑證來經紀你對 Azure 資源的存取。 由於 Azure MCP 伺服器位於代理程式與雲端資源之間，您必須保護 Azure MCP 伺服器本身、授權存取的憑證，以及透過代理程式流經的工具輸入與輸出。
本文提供如何最佳保護 Azure MCP Server 部署的指引。
身份驗證與授權
Azure MCP 伺服器透過 Azure Identity 函式庫使用 Microsoft Entra ID 來驗證呼叫者。 MCP 授權規範需要 OAuth 2.1，因此請將 Azure MCP 伺服器視為 OAuth 2.1 資源伺服器。 用戶端在執行授權碼流程時必須使用 PKCE（Proof Key for Code Exchange）。 請採取以下做法：
驗證每個授權憑證。 在允許工具執行前，請確認每個進入授權令牌的發行者、受眾及到期日。 不要相信缺少必要權利或是為其他資源發出的代幣。
將授權代幣綁定給其目標受眾。 使用受眾綁定的權杖，讓為某項服務簽發的權杖無法對另一項服務進行重放。
強制執行嚴格的重新導向 URI 比對，以及針對每個用戶端的個別同意。 授權碼流程中，只允許預先註冊且精確重定向的 URI，並要求每位客戶端同意，因此攔截的授權碼無法被其他客戶端兌換。
遵循最小權限原則的 RBAC。 只授予每位呼叫者執行其任務所需的 Azure RBAC 角色。 Azure MCP 伺服器會反映你的 Azure 訂閱權限——擁有廣泛訂閱權限的呼叫者可以調用一系列廣泛的工具。 盡可能縮小角色指派的範圍。 只啟用每位來電者所需的工具，因為每個可取得的工具都會增加攻擊面。
偏好工作量身份。 在代理情境下，應使用受管理身份或工作負載身份，而非長期秘密或共享憑證。 當靜態憑證無法避免時——例如第三方服務的 API 金鑰不支援工作負載身份——就將它們存放在 Azure Key Vault，並從你的部署設定中參考。 切勿將憑證儲存在原始碼或純文字設定檔中，並定期輪替使用。
避免混淆代理人模式。 將 Azure MCP 伺服器自身的 Azure 身份與權限範圍限制在運作所需的最低限度。 不要讓伺服器成為代理人，將廣泛的權限借給權限較低的呼叫者：將伺服器的執行身份與呼叫者的授權分開，並強制每個呼叫者進行權限檢查，而非僅依賴伺服器自身的憑證。
遠端 Azure MCP 伺服器保護
當你部署 Azure MCP Server 作為遠端自架伺服器時，考慮將其置於 Azure API 管理（APIM）後方作為強制閘道：
將 Azure MCP 伺服器置於強制閘道後方。 APIM 可以在請求抵達 Azure MCP 伺服器前驗證 Entra ID 令牌，這樣就不需要應用程式代碼來檢查 Token。
應用閘道策略進行速率限制與稽核。 使用 APIM 政策限制呼叫者提出請求的頻率、限制允許的工具路徑，並記錄每個請求以供稽核。
將出入控制集中在單一瓶頸點。 閘道器提供單一的瓶頸點，用於多個下游 MCP 工具間的存取控制與可觀察性。
保護 Azure MCP 伺服器用戶端連接的端點。 替換或偽造的 URL 可以接收工具執行請求，並暴露憑證或 Azure 資源資料。 為了降低這種風險：
僅連線到可信任的 Azure MCP 伺服器端點。 只使用你配置過或團隊透過 APIM 暴露的端點。 不要從使用者提供的輸入或未經認證的發現回應中推導出 Azure MCP 伺服器的 URL。
請驗證 Azure MCP 伺服器的 TLS 憑證。 確保端點與預期主機相符。 使用 APIM 時，請將用戶端路由至 gateway，避免後端端點被靜默重定向。
發生憑證錯誤時，採取封鎖模式。 將未驗證或未識別的 Azure MCP Server 憑證視為連線失敗，而非繞過警告。
關於自架選項，請參見部署自架 Azure MCP 伺服器。
本地部署強化
在你的開發環境中運行一台本地的 Azure MCP 伺服器供開發使用。 因為它可以處理你的 Azure 身份，請在你將代理連接到 Azure 資源前，先檢視你已登入的帳號能存取什麼：
請檢視你的 Azure 權限。 檢查你開發者帳號所指派的 Azure RBAC 角色，並移除不必要的廣泛訂閱或管理群組權限。
限制本地存取。 從受信任的工作站或容器執行本地 Azure MCP 伺服器，且不要讓本地端點暴露給不受信任的網路或機器上的其他使用者。
保持本地伺服器的更新。 尤其是在針對非生產環境的 Azure 資源進行測試之前，請使用目前版本的 Azure MCP Server 套件和已修補的相依套件。
沙盒式本地執行。 在容器或沙盒中運行本地 Azure MCP 伺服器，並限制檔案系統與網路存取，並保持工具鏈修補，以減少工具產生子程序時對指令注入與路徑穿越的影響。
不要用本地的 Azure MCP 伺服器來處理生產資料或生產憑證。
工具中毒與快速注射
MCP 工具描述與回應是對您代理人情境的輸入。 如果工具中繼資料或工具輸出具有惡意，可能會影響可存取 Azure MCP Server 工具及其背後 Azure 權限的代理程式。
為了降低 Azure MCP 伺服器部署的風險：
偏好官方 Microsoft 維護的 Azure MCP 伺服器。 使用第一方的 Azure MCP 伺服器來管理 Azure 服務，而不是使用暴露類似 Azure 工具的未經驗證伺服器。 將工具架構變更視為需要審查的相依變更。
信任但要確認工具的上下文。 將工具描述與回應視為代理的不可信輸入。 在生產環境使用前，先審查工具定義，並驗證或淨化工具回應回傳至代理上下文的資料。
變更控制工具定義。 審查並固定已知可靠的工具綱要與描述，並要求在更新後的工具中繼資料生效前重新核准，以防伺服器在核准後悄悄改變行為（亦即供應鏈式的「捲款跑路」）。
在適合你架構的地方使用 Azure 安全控制。 評估 Microsoft 安全控制中的控制措施，以檢查代理情境、偵測敏感資料流及監控 Azure AI 工作負載。 在正式投入生產環境前，請先驗證每個整合路徑。
第三方 MCP 伺服器信任
許多開發環境會同時運行多台 MCP 伺服器。 對於 Azure 工作，建議使用官方 Microsoft 維護的 Azure MCP Server，而非 Azure 服務的社區替代方案。
如果你在 Azure MCP 伺服器旁邊新增第三方 MCP 伺服器：
確認出版商和更新路徑。 使用來自設有公開安全聯絡窗口之可信賴發行者的伺服器。 在允許第三方伺服器進入能存取 Azure MCP 伺服器工具的代理環境前，先審查變更日誌和套件更新。
保持憑證上下文分開。 不要讓未經驗證的伺服器分享 Azure MCP 伺服器使用的憑證、檔案系統或網路存取權限。 在隔離環境中以最低權限運行不受信任的伺服器。
檢視整個代理情境中的工具。 惡意伺服器可以利用其工具描述影響代理對同一情境下其他受信任伺服器的行為，包括 Azure MCP 伺服器。 審核你設定的每台伺服器的工具描述，而不只是 Azure 工具。
治理與監督
追蹤你環境中運行的 Azure MCP Server 實例，並監控它們的活動：
盤點已核准的伺服器。 維護一個已知良好的註冊 Azure MCP 伺服器端點基準，例如 Azure API Center，這樣你就能偵測未註冊、不在治理範圍的「影子」伺服器。
監控活動並保存證據。 在 Microsoft Sentinel 中關聯 Azure MCP 伺服器活動，並保留 Microsoft Purview 稽核日誌，以便調查可疑工具呼叫。
Microsoft 安全控制
請使用以下 Microsoft 安全服務，為 Azure MCP Server 工作負載增添深度防禦。 每個控制項對你具體部署的適用性取決於你的架構。 在你自身環境的情境中評估每一項控制措施：
使用 Prompt Shields 檢查代理程式的內容脈絡。 使用 Azure AI 內容安全 提示防護來檢查進入代理程式上下文的內容（包括工具描述和工具輸出），並偵測潛在的提示注入攻擊企圖。 使用動態載入的工具中繼資料時，請考慮在代理流程中整合 Prompt Shields。 更多資訊請參見 提示盾。
使用 Purview DLP 偵測敏感資料流。 當您的工作負載明確整合於 Microsoft Purview 時，請使用 Purview 資料遺失防護政策，協助偵測並標記與代理程式相關的資料流敏感資料。 對任意工具呼叫參數的覆蓋並非自動的，這取決於你的部署架構以及工作負載使用的 Purview 連接器。 在依賴 DLP 來處理代理工作負載之前，先評估你的整合路徑是否支援所需的控制。 如需詳細資訊，請參閱 Microsoft Purview 檔。
使用 適用於雲端的 Defender 監控 AI 工作負載。 使用 適用於雲端的 Microsoft Defender AI 威脅防護，針對 AI 工作負載進行執行時威脅偵測，包括 Azure OpenAI 及 Azure AI 模型推論服務 API 呼叫中的可疑活動警示。 覆蓋範圍不會自動延伸到任意的 MCP 工具輸出——它適用於你架構中的 Azure AI 服務層。 欲了解更多資訊，請參閱 AI 威脅防護。
Note
前面列出的控制措施是一般的 Azure 安全服務。 在啟用生產環境前，請確認每個控制項的整合路徑是否支援你特定的 Azure MCP 伺服器部署架構。