停止失控AI：Unity Catalog如何保護你的代理操作安全

代理AI的風險已經不再是理論上的。連線到外部工具的代理正在生產中執行破壞性、不可逆的操作：幾秒鐘內擦除整個資料庫、刪除數百萬行關鍵資料、並在任務中途刪除生產資料庫。在每起事件中，代理都是在被授權的範圍內行動，但缺乏對可呼叫工具的任何限制，也沒有任何操作記錄。

今天，我們推出了治理每個MCP工具的能力，就像治理資料一樣，包括細粒度訪問控制、策略執行和完整審計跟蹤。Unity Catalog現在允許你設定誰可以呼叫哪些MCP伺服器，管理員可以分層服務策略以限制對特定工具（例如delete_database）的訪問，或定義呼叫工具的條件（例如只有管理員可以呼叫delete_database）。Unity AI Gateway在每次呼叫時即時強制執行這些策略，並記錄每個請求的完整有效載荷。

問題：訪問是非此即彼的，工具呼叫不留痕跡

一個MCP伺服器向任何連線的代理暴露一組工具——例如，GitHub MCP可能暴露push_files、delete_file和merge_pull_request；資料庫MCP可能暴露execute_query和drop_table。預設情況下，如果代理被授權連線，所有這些工具隨時可用。無法設定“此代理可讀但不可寫”，或“只有高階工程師才能執行此操作”，或“任何人都不應在生產環境中呼叫管理工具”。

當出現問題時，沒有任何東西可以調查。工具呼叫不出現在模型日誌或應用日誌中。代理執行的確切操作、引數、代表誰，根本沒有任何記錄。

這意味著一個配置錯誤的代理、一個意外的操作，你都無法在事前阻止，也無法在事後解釋。

解決方案：Unity Catalog中的MCP治理

Unity Catalog現在治理整個GenAI資產，包括LLM和MCP。一旦註冊MCP，你將獲得之前缺失的東西：對代理允許執行的操作的控制，以及它們實際執行的操作的完整記錄。兩者都由Unity AI Gateway在每次MCP呼叫時即時強制執行。

服務策略允許你編寫規則，在每次工具呼叫到達上游MCP伺服器之前和之後進行評估。你決定哪些呼叫允許、拒絕或需要使用者同意。服務策略用SQL定義，允許管理員檢查引數，包括呼叫者屬性和其他上下文屬性。如果呼叫未透過策略，則被阻止。

有效載荷日誌記錄將每個工具呼叫作為條目捕獲到Unity Catalog管理的追蹤表中。工具名稱、引數、結果、使用者身份以及呼叫是否允許或拒絕。像任何其他表一樣用SQL查詢。

工作原理

在Unity Catalog中定義策略函式

Unity Catalog允許你註冊和治理任何外部MCP（參見我們關於此工作原理的部落格！）。服務策略是一個Unity Catalog SQL函式。它接收兩個引數：actor（誰在呼叫）和context（他們在呼叫什麼），並返回允許或拒絕以及原因。

這是一個GitHub MCP的簡單策略。它完全阻止檔案刪除，並阻止合併PR，除非呼叫者是經批准的工程師：

附加並強制執行

編寫後，將策略附加到Unity AI Gateway中的任何MCP服務。從那時起，每個透過該服務路由的工具呼叫在執行前都經過評估。代理或MCP伺服器無需更改程式碼。

記錄並驗證

每個工具呼叫自動捕獲到Unity Catalog中的Delta表中。傳送一個應被阻止的提示和一個應透過的提示。結果立即出現在日誌中，可像任何其他表一樣用SQL查詢。

開始使用

MCP的服務策略和有效載荷日誌記錄作為Gated Beta提供，將你已用於資料的相同治理概念擴充套件到每個MCP呼叫。要獲得早期訪問許可權，請聯絡你的Databricks賬戶團隊。