停止失控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賬户團隊。